linux-kernel - Re: [PATCH v2] docs/mm: add VMA locks documentation

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: <CAG48ez3Ap0XWr+3UmQeW6O82PU_Fh85pCuwOpC9n6J+kxtPVRA@mail.gmail.com>
Date: Wed, 13 Nov 2024 18:43:57 +0100
From: Jann Horn <jannh@...gle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Jonathan Corbet <corbet@....net>, Vlastimil Babka <vbabka@...e.cz>, Alice Ryhl <aliceryhl@...gle.com>, 
	Boqun Feng <boqun.feng@...il.com>, Matthew Wilcox <willy@...radead.org>, 
	Mike Rapoport <rppt@...nel.org>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	linux-doc@...r.kernel.org, Suren Baghdasaryan <surenb@...gle.com>, 
	Hillf Danton <hdanton@...a.com>, Qi Zheng <zhengqi.arch@...edance.com>, 
	SeongJae Park <sj@...nel.org>, Bagas Sanjaya <bagasdotme@...il.com>
Subject: Re: [PATCH v2] docs/mm: add VMA locks documentation

On Wed, Nov 13, 2024 at 4:44 PM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
> On Tue, Nov 12, 2024 at 10:15:44AM -0500, Liam R. Howlett wrote:
> > * Lorenzo Stoakes <lorenzo.stoakes@...cle.com> [241108 08:57]:
> [snip]
> > > +Each mm object contains a maple tree data structure which describes all VMAs
> > > +within the virtual address space.
> > > +
> > > +.. note:: An exception to this is the 'gate' VMA which is provided by
> > > +          architectures which use :c:struct:`!vsyscall` and is a global static
> > > +          object which does not belong to any specific mm.
> >
> > vvars too?
>
> I'm not sure if that's the case? For instance for x86-64 we have:
>
> /*
>  * A pseudo VMA to allow ptrace access for the vsyscall page.  This only
>  * covers the 64bit vsyscall page now. 32bit has a real VMA now and does
>  * not need special handling anymore:
>  */
> static const char *gate_vma_name(struct vm_area_struct *vma)
> {
>         return "[vsyscall]";
> }
>
> With no reference to vvar. Also vsyscall exists in a kernel range, and vvar
> in a userland mapping (along with the vdso).

Yeah, there are different gate VMA types depending on architecture
(arm has "vectors page", x86 has "vsyscall", ...), but vvar and vdso
are just normal VMAs set up at some point in execve().