linux-kernel - Re: [PATCH] staging: android: binder: move to the "real" part of the kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 20 Oct 2014 19:06:47 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
	linux-api@...r.kernel.org,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	John Stultz <john.stultz@...aro.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Sumit Semwal <sumit.semwal@...aro.org>,
	Rebecca Schultz Zavin <rebecca@...roid.com>,
	Christoffer Dall <christoffer.dall@...aro.org>,
	Anup Patel <anup.patel@...aro.org>
Subject: Re: [PATCH] staging: android: binder: move to the "real" part of the kernel

On Thursday 16 October 2014 14:47:41 Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman <gregkh@...uxfoundation.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@...uxfoundation.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/