Re: [Ksummit-discuss] [CORE TOPIC] Reviewing new API/ABI

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2014-05-06 at 12:43 -0700, Andy Lutomirski wrote:

> > How far would you want to take this? New syscalls is one thing, but
> > there are frequently additions to "subsystem APIs", e.g. in networking,
> > that aren't really syscalls but part of netlink etc. Trying to vet all
> > of that might very well end up just overwhelming the process, but on the
> > other hand it's still something that probably should be done in some
> > form.
> 
> The snarky answer is: CVE-2014-0181.  I don't like netlink for
> anything other than broadcasts from kernel space to user space.

That's also an entirely useless statement - netlink is neither going
away nor getting used less or being restricted. :)

> A possibly better answer is that I think there are things that are
> worthy of more care and things that are worthy of less care.  I also
> think that it's more a question of the scope of the API than the
> mechanism.  A debugfs thing, a sysfs entry for a particular device or
> obscure configuration setting, or an ioctl on a device node are
> possibly of less broad applicability.  Something like AF_ALG really is
> a global API, though.  I would tend to classify many things that use
> netlink in more-review category, since I don't think that the fact
> that a new API uses netlink should exempt it from the same kind of
> review it would need if it used a different mechanism.

Sure - still I'd think that the review process might be overwhelmed.
Particularly for domain-specific APIs (e.g. networking, or for me in
particular wireless) are not always entirely clear without that
domain-specific knowledge, nor am I convinced that it makes sense to try
to explain it in "laymen's terms", so to speak.

johannes