linux-kernel - 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250206135150-6c770e7d-9af8-4924-b760-82cff5092586@linutronix.de>
Date: Thu, 6 Feb 2025 14:20:22 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: enh <enh@...gle.com>
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 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].

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/