linux-kernel - Re: [PATCH v3 0/7] binder: eliminate use of vmalloc space for binder buffers

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]

Message-ID: <CAHRSSExpDnm+630y_8z8h91CEQ5sviqOdDazq=XwG-creZ+DxQ@mail.gmail.com>
Date:   Mon, 11 Feb 2019 09:08:40 -0800
From:   Todd Kjos <tkjos@...gle.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Todd Kjos <tkjos@...roid.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arve Hjønnevåg <arve@...roid.com>,
        "open list:ANDROID DRIVERS" <devel@...verdev.osuosl.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Martijn Coenen <maco@...gle.com>, joel@...lfernandes.org,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH v3 0/7] binder: eliminate use of vmalloc space for binder buffers

On Mon, Feb 11, 2019 at 8:57 AM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Fri, Feb 08, 2019 at 10:35:13AM -0800, Todd Kjos wrote:
> > Binder buffers have always been mapped into kernel space
> > via map_kernel_range_noflush() to allow the binder driver
> > to modify the buffer before posting to userspace for
> > processing.
> >
> > In recent Android releases, the number of long-running
> > binder processes has increased to the point that for
> > 32-bit systems, there is a risk of running out of
> > vmalloc space.
> >
> > This patch set removes the persistent mapping of the
> > binder buffers into kernel space. Instead, the binder
> > driver creates temporary mappings with kmap() or
> > kmap_atomic() to copy to or from the buffer only when
> > necessary.
>
> Is there any good reason to actually map the user memory to kernel
> space instead of just using copy_{to,from}_user?

Yes, the mappings are needed for cases where we are accessing binder
buffers of the target while in sender context. For example, we copy
the message from the sender to the target with 1 copy while in the
sender's context. For this we use copy_from_user(), but use these
temporary mappings for the destination (target process).

-Todd