* Johannes Berg <johan...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
