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/
