[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170830092904.b43bmlveo5g4c6rd@mwanda>
Date: Wed, 30 Aug 2017 12:29:05 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Sherry Yang <sherryy@...roid.com>,
Arve Hjønnevåg <arve@...roid.com>
Cc: linux-kernel@...r.kernel.org,
"open list:ANDROID DRIVERS" <devel@...verdev.osuosl.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Riley Andrews <riandrews@...roid.com>, maco@...gle.com,
tkjos@...gle.com
Subject: Re: [PATCH v3 3/6] android: binder: Move buffer out of area shared
with user space
On Tue, Aug 29, 2017 at 05:46:59PM -0700, Sherry Yang wrote:
> Binder driver allocates buffer meta data in a region that is mapped
> in user space. These meta data contain pointers in the kernel.
>
> This patch allocates buffer meta data on the kernel heap that is
> not mapped in user space, and uses a pointer to refer to the data mapped.
>
> Also move alloc->buffers initialization from mmap to init since it's
> now used even when mmap failed or was not called.
>
> Signed-off-by: Sherry Yang <sherryy@...roid.com>
> ---
The difference between v2 and v3 is that we've shifted some
initialization around to fix the crashing bug that kbuild found. You
should not that difference here under the --- cut off.
> drivers/android/binder_alloc.c | 146 +++++++++++++++++++-------------
> drivers/android/binder_alloc.h | 2 +-
> drivers/android/binder_alloc_selftest.c | 11 ++-
> 3 files changed, 91 insertions(+), 68 deletions(-)
But really we still need to have some answers or discussion about the
questions that Greg and I raised. Greg asked if the other Android devs
had Acked this. Please ping Arve to Ack this.
I was curious about the security impact or why we were writing this
patch 3/6. It seems we are fixing an information disclosure bug. Or is
it something worse than that? Or have I misunderstood entirely.
We probably original put the buffers in userspace for accounting reasons
so we could kill programs that used too much RAM. This patch doesn't
create a problem with that hopefully? We're just moving the metadata to
kernel space?
regards,
dan carpenter
Powered by blists - more mailing lists