[Ksummit-discuss] [CORE TOPIC] Reviewing new API/ABI
Johannes Berg
johannes at sipsolutions.net
Tue May 6 19:48:05 UTC 2014
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
More information about the Ksummit-discuss
mailing list