linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-api@vger.kernel.org,
	"Santosh Shilimkar" <santosh.shilimkar@ti.com>,
	"John Stultz" <john.stultz@linaro.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Rebecca Schultz Zavin" <rebecca@android.com>,
	"Christoffer Dall" <christoffer.dall@linaro.org>,
	"Anup Patel" <anup.patel@linaro.org>
Subject: Re: [PATCH] staging: android: binder: move to the "real" part of the kernel
Date: Mon, 20 Oct 2014 19:06:47 +0200	[thread overview]
Message-ID: <2166528.FFdzTaR0kp@wuerfel> (raw)
In-Reply-To: <20141016124741.GA3832@kroah.com>

On Thursday 16 October 2014 14:47:41 Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> The Android binder code has been "stable" for many years now.  No matter
> what comes in the future, we are going to have to support this API, so
> might as well move it to the "real" part of the kernel as there's no
> real work that needs to be done to the existing code.
> 
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> 
> This was discussed in the Android miniconf at the Plumbers conference.
> If anyone has any objections to this, please let me know, otherwise I'm
> queueing this up for 3.19-rc1

I'm worried about the user interface: since graduating binder out of
staging with the existing ioctl interface has never been discussed
as a real option and (I assume) everybody expected the way forward
would be to have a replacement, I don't think it ever received the
attention it should have. Specific concerns are:

- I don't think there has been an audit of which subset of the API
  is actually required. IIRC, it was said initially that actual
  applications don't use all the features, and that we should have
  a smaller attack surface.

- Using kernel pointers in user space interfaces is an information
  leak that can be used to construct an exploit. (I don't know if
  this is still used that way, I think it was doing it last
  time I checked).

- The driver supports two versions of the user interface (v7 and
  v8), but only one of them can be selected at compile-time, and
  an 'allmodconfig' kernel will only include the deprecated one
  on 32-bit machines.

- The implementation is not namespace-aware and will cause
  information to be shared across containers in a potentially
  harmful way.
  If we graduate the driver from staging, it should IMHO at least
  be useful in containers to run Android user space safely.

	Arnd

      parent reply	other threads:[~2014-10-20 17:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-16 12:47 [PATCH] staging: android: binder: move to the "real" part of the kernel Greg Kroah-Hartman
2014-10-16 14:18 ` Michael Kerrisk (man-pages)
2014-10-16 23:14   ` Greg Kroah-Hartman
2014-10-20 12:45     ` Dan Carpenter
2014-10-21 10:01     ` Pavel Machek
2014-10-16 17:09 ` John Stultz
2014-10-16 23:12   ` Greg Kroah-Hartman
2014-10-17  3:25     ` John Stultz
2014-10-17  8:01       ` Greg Kroah-Hartman
2014-10-18 21:36     ` One Thousand Gnomes
2014-10-19 22:01       ` Greg Kroah-Hartman
2014-10-21 10:36     ` Pavel Machek
2014-10-21 14:12       ` Arnd Bergmann
2014-10-21 20:05         ` Pavel Machek
2014-10-17  9:26 ` Dan Carpenter
2014-10-19 22:05   ` Greg Kroah-Hartman
2014-10-20  9:20     ` Dan Carpenter
2014-10-20 23:32       ` Arve Hjønnevåg
2014-10-22  3:10         ` Rom Lemarchand
2014-10-22  3:16           ` Joe Perches
2014-10-24  5:00           ` Dan Carpenter
2014-10-17  9:43 ` Christoph Hellwig
2014-10-19 22:04   ` Greg Kroah-Hartman
2014-10-21 10:46     ` Christoph Hellwig
2014-10-20 17:06 ` Arnd Bergmann [this message]

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=2166528.FFdzTaR0kp@wuerfel \
    --to=arnd@arndb.de \
    --cc=anup.patel@linaro.org \
    --cc=arve@android.com \
    --cc=christoffer.dall@linaro.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rebecca@android.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=sumit.semwal@linaro.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;
as well as URLs for NNTP newsgroup(s).