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] [day] [month] [year] [list]

Message-ID: <Z0ZamgSUxuuae0KP@google.com>
Date: Tue, 26 Nov 2024 23:32:42 +0000
From: Carlos Llamas <cmllamas@...gle.com>
To: Suren Baghdasaryan <surenb@...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 12:05:58PM -0800, Suren Baghdasaryan wrote:
> 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.
>  */

Right, that is the message I tried to convey: (1) Each binder instance
is allowed a single mapping throughout its lifetime (no re-mapping).
(2) alloc->mapped gets cleared when this mapping is removed e.g. during
vm_ops->close(). Putting 1 and 2 together... whenever binder looks up a
vma it also checks alloc->mapped to verify its mapping is still opened
and avoid poking into some other unrelated vma.

I tried writing a concise explanation but I guess it was not enough.

Note this unusual behavior is nothing new in binder and predates this
patchset, but I agree it needs to be documented somewhere. I'll send out
a new version attempting to document this better. It's a little tricky
though, since the same vma validation pattern is in multiple places and
obviously I don't want to duplicate the paragraph everywhere.

Maybe I can inline a "binder_vma_check()" and put the explanation there.
I'll think of something.

Cheers,
Carlos Llamas