Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting
From: Ingo Molnar
Date: Wed Aug 26 2015 - 00:50:32 EST
* Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
> On Tue, 2015-08-25 at 12:07 +0200, Ingo Molnar wrote:
> > Having a separate syscall has two (big!) appeals:
> > - we wouldn't have to touch existing system calls at all.
> > - extended error reporting would be available for any system call that opts to
> > use it. (The current scheme as submitted is only available to system calls
> > using the perf-style flexible attribute ABI.)
> Yeah, I agree this is nice. However, more generally, I think we need to
> actually think more about the module problem then since while syscalls
> can't be implemented in modules (I think) they can still end up calling
> into modules.
> Of course a first iteration could be exactly like what Alexander
> The other issue with this is namespacing - can all syscalls, and
> everything that eventually gets called, really use a single error code
> namespace with its 3k limit? [...]
No, the current MAX_ERRNO is probably not big enough if this scheme is successful,
and I don't see any reason why it wouldn't be successful: I think this feature
would be the biggest usability feature added to Linux system calls and to Linux
system tooling in the last 10 years or so.
> [...] On the one hand I'm thinking "3k strings are so big ... we don't want
> more", but on the other hand all kinds of drivers etc. might start getting
We could extend it with some arch work. The per arch work involves making sure
there's no valid kernel address at [-MAX_ERRNO...-1].
So I wouldn't worry about it too much, let's agree on a good ABI and let's just
start using it, and if we grow out of -4K we can extend things step by step.
> > Ok. So assuming we can make a 1:1 mapping between the 'extended error code'
> > integer space and the message:owner strings, it would be enough for netlink to
> > pass along the integer code itself, not the full strings?
> Considering that this would likely have to be opt-in at the netlink level (e.g.
> through a flag in the request message), perhaps. I'd say it'd still be easier
> for the message to carry the intended error code (e.g. -EINVAL) and the actual
> message in the ACK message [where requested]. That way, applications that
> actually behave depending on the error code can far more easily be extended.
Ok. I think we should include the extended error code as well, in case an app
wants to pass it to some more generic library.
> > That would simplify things and make the scheme more robust from a security POV
> > I suspect.
> You could also argue the other way around, in that being able to look up (from
> userspace) arbitrary extended error IDs, even those that haven't ever been used,
> could be an information leak of sorts.
The fact is that kernel<->tooling error reporting sucks big time here and today,
in large part due to errno limitations, and arguing that it's somehow helping
security is the Stockholm Syndrome at its best.
> > So my hope would be that we can represent this all with a single 'large' error
> > code integer space. That integer would be constant and translateable (as long
> > as the module is loaded).
> Ok, I wasn't really what I was assuming. As I said above, on the one
> hand I agree, but on the other I'm looking at the reality of a few
> hundred (!) -EINVAL callsites in net/wireless/nl80211.c alone, so
> having an overall 3k limit seems somewhat low.
Agreed - but it's not a hard limit really.
> > That way the error passing mechanism wouldn't have to be specifically
> > module-aware - during build we generate the integer space, with all possible
> > modules considered.
> That would be no improvement for me as I work heavily with (upstream) modules
> that are compiled out-of-tree, so I'm not all inclined to spend much time on it
> if that ends up being the solution ;)
Perhaps, as long as the number allocation is dynamic and non-ABI there's no reason
why this couldn't be added later on.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/