linux-kernel - Re: [PATCH] selftests/nolibc: only run constructor tests on nolibc

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: <8dde4be5-0b37-4e45-bea3-8cdadeb23e7a@t-8ch.de>
Date: Sun, 2 Mar 2025 22:56:01 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Willy Tarreau <w@....eu>
Cc: Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selftests/nolibc: only run constructor tests on nolibc

Hi Willy!

On 2025-03-01 12:07:35+0100, Willy Tarreau wrote:
> [..]

> OK so I've tested the patch below which does what we want, except that
> it reveals that the order is still not granted. Actually I haven't found
> what dictates it. On one machine (gcc-9.5, ld-2.26) I'm getting:
> 
>   $ ./nolibc-test|grep cst
>   17 linkage_cst = 0                                              [FAIL]
>   18 linkage_cst_ord = 0                                          [FAIL]

Apparently no constructors are executed at all.
Can you show the default linkerscript used?

gcc -static -o /dev/null /dev/null -Wl,--verbose

> On this same machine, using another toolchain relying on ld-2.27 gives me
> this:
> 
>   $ ./nolibc-test|grep cst
>   17 linkage_cst = 1                                                [OK]
>   18 linkage_cst_ord = 33                                          [FAIL]
> 
> And I'm getting this as well on another machine with various toolchains
> such as gcc-9.5+ld-2.34. The nolibc toolchains fail similarly on gcc-5.5
> (ld-2.27) and gcc-6.5 (ld-2.32), but work for gcc-7.5 with ld-2.32, while
> other combinations do work:
> 
>   $ ./nolibc-test|grep -i cst
>   17 linkage_cst = 1                                                [OK]
>   18 linkage_cst_ord = 18                                           [OK]
> 
> All of this is a bit confusing.
> 
> I continue not to understand what could guarantee an implicit execution
> order since for me it solely depends on how things are linked, so the
> purpose of the test remains uncertain to me and I think we'd rather not
> try to enforce any ordering that might work only by pure luck.

I don't think anything guarantees the order. 
It is just what happened to work in my tests so far.

> What do you think ?

Let's get rid of the validation.


Thomas