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
> posted.
> 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
> annotations?

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
Please read the FAQ at