On Wed, Nov 13, 2024 at 4:44 PM Lorenzo Stoakes
<lorenzo.stoakes@xxxxxxxxxx> wrote:
> On Tue, Nov 12, 2024 at 10:15:44AM -0500, Liam R. Howlett wrote:
> > * Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> [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().
