Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

[Ingo Molnar <mingo@kernel.org>]

* Johannes Berg <johannes@sipsolutions.net> 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.

Thanks,

	Ingo