From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 1942782A for ; Tue, 6 May 2014 19:44:10 +0000 (UTC) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86FEC1FD46 for ; Tue, 6 May 2014 19:44:09 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id sa20so4878978veb.23 for ; Tue, 06 May 2014 12:44:08 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1399404095.4218.51.camel@jlt4.sipsolutions.net> References: <20140506175842.GF20776@cloud> <1399404095.4218.51.camel@jlt4.sipsolutions.net> From: Andy Lutomirski Date: Tue, 6 May 2014 12:43:48 -0700 Message-ID: To: Johannes Berg Content-Type: text/plain; charset=UTF-8 Cc: "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [CORE TOPIC] Reviewing new API/ABI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, May 6, 2014 at 12:21 PM, Johannes Berg 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