From: Andy Lutomirski <luto@amacapital.net>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Reviewing new API/ABI
Date: Tue, 6 May 2014 12:43:48 -0700 [thread overview]
Message-ID: <CALCETrVwW4werwNieVuqUKcUP-HRkBM2+kS5jor56NoGG1+4Hw@mail.gmail.com> (raw)
In-Reply-To: <1399404095.4218.51.camel@jlt4.sipsolutions.net>
On Tue, May 6, 2014 at 12:21 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2014-05-06 at 10:58 -0700, josh@joshtriplett.org wrote:
>
>> We need to have better processes for vetting new syscalls and ABIs far
>> more carefully than we currently do.
>
> 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.
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.
--Andy
next prev parent reply other threads:[~2014-05-06 19:44 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 17:45 Andy Lutomirski
2014-05-06 17:58 ` josh
2014-05-06 19:12 ` Shuah Khan
2014-05-06 19:16 ` Andy Lutomirski
2014-05-06 19:37 ` Shuah Khan
2014-05-06 19:21 ` Johannes Berg
2014-05-06 19:43 ` Andy Lutomirski [this message]
2014-05-06 19:48 ` Johannes Berg
2014-05-06 19:51 ` Andy Lutomirski
2014-05-06 19:45 ` josh
2014-05-06 20:10 ` Daniel Vetter
2014-05-06 20:13 ` Andy Lutomirski
2014-05-07 10:12 ` Laurent Pinchart
2014-05-07 12:36 ` Daniel Vetter
2014-05-07 13:30 ` Laurent Pinchart
2014-05-07 13:50 ` Hans Verkuil
2014-05-12 14:15 ` Wolfram Sang
2014-05-07 17:48 ` Michael Kerrisk (man-pages)
2014-05-06 19:00 ` Greg KH
2014-05-06 20:07 ` Steven Rostedt
2014-05-06 20:34 ` Josh Triplett
2014-05-06 20:42 ` Steven Rostedt
2014-05-06 21:00 ` josh
2014-05-07 11:48 ` Jiri Kosina
2014-05-08 6:35 ` Li Zefan
2014-05-12 6:37 ` Jiri Kosina
2014-05-07 6:27 ` Michael Kerrisk (man-pages)
2014-05-06 19:57 ` Dan Carpenter
2014-05-08 18:15 ` Randy Dunlap
2014-05-09 11:33 ` Jeff Layton
2014-05-09 11:50 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrVwW4werwNieVuqUKcUP-HRkBM2+kS5jor56NoGG1+4Hw@mail.gmail.com \
--to=luto@amacapital.net \
--cc=johannes@sipsolutions.net \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox