linux-kernel - Re: [PATCH v5 9/9] binder: use per-vma lock in page reclaiming

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: <CAJuCfpFZ3L-OvZEdhCipx17=A9yMFNWfuaWVN-BDrbXjce=v-w@mail.gmail.com>
Date: Tue, 26 Nov 2024 12:05:58 -0800
From: Suren Baghdasaryan <surenb@...gle.com>
To: Carlos Llamas <cmllamas@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Arve Hjønnevåg <arve@...roid.com>, 
	Todd Kjos <tkjos@...roid.com>, Martijn Coenen <maco@...roid.com>, 
	Joel Fernandes <joel@...lfernandes.org>, Christian Brauner <brauner@...nel.org>, 
	linux-kernel@...r.kernel.org, kernel-team@...roid.com, 
	"Liam R. Howlett" <Liam.Howlett@...cle.com>
Subject: Re: [PATCH v5 9/9] binder: use per-vma lock in page reclaiming

On Tue, Nov 26, 2024 at 11:11 AM Carlos Llamas <cmllamas@...gle.com> wrote:
>
> On Tue, Nov 26, 2024 at 10:46:03AM -0800, Suren Baghdasaryan wrote:
> > On Tue, Nov 26, 2024 at 10:45 AM Suren Baghdasaryan <surenb@...gle.com> wrote:
> > >
> > > You did add a clarifying comment I asked for in
> > > https://lore.kernel.org/all/CAJuCfpESdY4L_sSwiCYVCX+5y1WOuAjLNPw35pEGzTSyoHFYPA@mail.gmail.com/
> >
> > s/did/did not
>
> Oh, I added the comment to patch 5/9 since it fits better there (sorry
> that I forgot to mention this). Now the kerneldoc section reads:
>
> + * @mapped:             whether the vm area is mapped, each binder instance is
> + *                      allowed a single mapping throughout its lifetime
>
> ... and the vma check now has the following comment:
>
> +       /* ensure the vma corresponds to the binder mapping */

I think the above comment does not explain the race we are trying to avoid here.
Something like this perhaps:
/*
 * binder does not allow mapping of the same buffer more than once, therefore
 * alloc->vm_start could not have changed since the buffer can't be remapped.
 * Checking binder_alloc_is_mapped() ensures that the vma is mapped and still
 * covers the same area.
 */

> +       if (vma && !binder_alloc_is_mapped(alloc))
>                 goto err_invalid_vma;
>
> This was the feedback right?