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

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: <CAJgzZoq4UOYXaOh=mdUxsNUug9uYWzPX56AtUDL0RgKOx_VnQA@mail.gmail.com>
Date: Thu, 6 Feb 2025 09:38:59 -0500
From: enh <enh@...gle.com>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Jeff Xu <jeffxu@...omium.org>, Pedro Falcato <pedro.falcato@...il.com>, 
	Benjamin Berg <benjamin@...solutions.net>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 
	Kees Cook <kees@...nel.org>, akpm@...ux-foundation.org, jannh@...gle.com, 
	torvalds@...ux-foundation.org, adhemerval.zanella@...aro.org, oleg@...hat.com, 
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org, 
	linux-mm@...ck.org, jorgelo@...omium.org, sroettger@...gle.com, 
	ojeda@...nel.org, adobriyan@...il.com, anna-maria@...utronix.de, 
	mark.rutland@....com, linus.walleij@...aro.org, Jason@...c4.com, 
	deller@....de, rdunlap@...radead.org, davem@...emloft.net, hch@....de, 
	peterx@...hat.com, hca@...ux.ibm.com, f.fainelli@...il.com, gerg@...nel.org, 
	dave.hansen@...ux.intel.com, mingo@...nel.org, ardb@...nel.org, 
	Liam.Howlett@...cle.com, mhocko@...e.com, 42.hyeyoo@...il.com, 
	peterz@...radead.org, ardb@...gle.com, rientjes@...gle.com, 
	groeck@...omium.org, mpe@...erman.id.au, Vlastimil Babka <vbabka@...e.cz>, 
	Andrei Vagin <avagin@...il.com>, Dmitry Safonov <0x7f454c46@...il.com>, 
	Mike Rapoport <mike.rapoport@...il.com>, 
	Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings

On Thu, Feb 6, 2025 at 8:20 AM Thomas Weißschuh
<thomas.weissschuh@...utronix.de> 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@...omium.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].

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