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

["Thomas Weißschuh" <thomas.weissschuh@linutronix.de>]

On Fri, Jan 17, 2025 at 02:35:18PM -0500, enh wrote:
> On Fri, Jan 17, 2025 at 1:20 PM Jeff Xu <jeffxu@chromium.org> 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].

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

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@linutronix.de/