linux-kernel - Re: [PATCH v3 3/3] vdso: Reject absolute relocations during build

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] [day] [month] [year] [list]

Message-ID: <20250623080736-6f8f2389-4575-4508-8214-faeb10b4b241@linutronix.de>
Date: Mon, 23 Jun 2025 09:25:49 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Alexandre Ghiti <alex@...ti.fr>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, 
	Albert Ou <aou@...s.berkeley.edu>, Nathan Chancellor <nathan@...nel.org>, 
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>, Bill Wendling <morbo@...gle.com>, 
	Justin Stitt <justinstitt@...gle.com>, Andy Lutomirski <luto@...nel.org>, 
	Vincenzo Frascino <vincenzo.frascino@....com>, linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	llvm@...ts.linux.dev
Subject: Re: [PATCH v3 3/3] vdso: Reject absolute relocations during build

On Sat, Jun 21, 2025 at 05:42:20PM +0200, Thomas Gleixner wrote:
> On Thu, Jun 12 2025 at 16:21, Thomas Weißschuh wrote:
> > On Thu, Jun 12, 2025 at 10:31:20AM +0200, Alexandre Ghiti wrote:
> > We could introduce per-architecture configuration. Essentially reverting parts
> > of commit aff69273af61 ("vdso: Improve cmd_vdso_check to check all dynamic relocations").
> > The final logic for the intermediary objects still needs to be more complicated
> > than for the final .so as those contain relocations in the debug information.
> >
> > Or we could add a C hostprog for validation.
> > That would be much more flexible than the inline shell command.
> > It would then also be easier to use an allow-list than the brittle deny-list.
> >
> > Or we don't do anything, relying on the selftests to detect miscompilations.
> 
> That's a bad idea :)

Fully agreed :-)

> > I'll run this by tglx. If somebody else has any opinions, I'm all ears.
> 
> This is all a mess because the relocation type numbers and their R_*
> names are not uniform accross architectures. Neither are the valid
> relocation types which are suitable for VDSO.

Ack.

> I don't think you can reasonably cover all of it with readelf and
> grep. I did some unrelated relocation analysis some time ago and I just
> modified the python script (yes, I hate to use libelf) to show case how
> insane this gets. This is just as much as I needed to analyse files
> compiled with some random cross gcc I had handy. But you surely get the
> idea.

Yes I get the idea. This is more or less exactly what I meant above with:
"Or we could add a C hostprog for validation."
More specifically my plan then is to write a C application that uses
<linux/elf.h> to do what your Python script does.
There should be no need to mess with libelf.

<snip>


Thomas