Re: [PATCH v4 1/1] exec: seal system mappings

[enh]

On Thu, Feb 6, 2025 at 8:20 AM Thomas Weißschuh
<thomas.weissschuh@xxxxxxxxxxxxx> wrote:
>
> On Fri, Jan 17, 2025 at 02:35:18PM -0500, enh wrote:
> > On Fri, Jan 17, 2025 at 1:20 PM Jeff Xu <jeffxu@xxxxxxxxxxxx> wrote:
>
> <snip>
>
> > > There are technical difficulties to seal vdso/vvar from the glibc
> > > side. The dynamic linker lacks vdso/vvar mapping size information, and
> > > architectural variations for vdso/vvar also means sealing from the
> > > kernel side is a simpler solution. Adhemerval has more details in case
> > > clarification is needed from the glibc side.
> >
> > as a maintainer of a different linux libc, i've long wanted a "tell me
> > everything there is to know about this vma" syscall rather than having
> > to parse /proc/maps...
> >
> > ...but in this special case, is the vdso/vvar size ever anything other
> > than "one page" in practice?
>
> x86 has two additional vvar pages for virtual clocks.
> (Since v6.13 even split into their own mapping)
> Loongarch has per-cpu vvar data which is larger than one page.
> The vdso mapping is however many pages the code ends up being compiled as,
> for example on my current x86_64 distro kernel it's two pages.
> In the near future, probably v6.14, vvars will be split over multiple
> pages in general [0].

/me checks the nearest arm64 phone ... yeah, vdso is still only one
page there but vvars is already more than one.

is there a TL;DR (or RTFM link) for why this is so big? a quick look
at the x86 suggests there should only be 640 bytes of various things
plus a handful of bytes for the rng, and while arm64 looks very
different, that looks like it's explicitly asking for a page (with the
vdso_data_store stuff)? (i've never had any reason to look at vvars
before, only vdso.)

> Figuring out the start and size from /proc/maps, or the new
> PROCMAP_QUERY ioctl, is not trivial, due to architectural variations.

(obviously it's unsatisfying as a general interface, but in practice
the VMAs i see asked about about directly -- rather than just rounded
up in a diagnostic dump -- are either stacks ["what are the bounds of
this stack, and does it have guard pages already?"] or code ["what
file was the code at this pc mapped in from?"]. so while the vdso
would come up, we'd never notice if vvars didn't work. if your sp/pc
point there, we were already just going to bail anyway :-) )

> Trying to construct the size from the ELF header is also problematic as
> that only contains information about the vdso code.
> The vvars are mapped before the code in memory independently.
>
> A dedicated interface like a prctl() would be actually reliable.
> Or theoretically a function from the vdso itself.
>
> <snip>
>
> [0] https://lore.kernel.org/lkml/20250204-vdso-store-rng-v3-0-13a4669dfc8c@xxxxxxxxxxxxx/