linux-kernel - Re: [PATCH] tools/nolibc: pass argc, argv and envp to constructors

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: <dc079808-ef49-42b6-9147-b043b97dcc86@t-8ch.de>
Date: Sat, 3 Aug 2024 20:23:39 +0200 (GMT+02:00)
From: Thomas Weißschuh  <thomas@...ch.de>
To: Willy Tarreau <w@....eu>
Cc: Thomas Weißschuh <linux@...ssschuh.net>,
	Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org
Subject: Re: [PATCH] tools/nolibc: pass argc, argv and envp to constructors

Aug 3, 2024 12:03:27 Willy Tarreau <w@....eu>:

> On Sun, Jul 28, 2024 at 10:34:11PM +0200, Thomas Weißschuh wrote:
>> Mirror glibc behavior for compatibility.
>
> Generally speaking I think you should make a bit longer sentences in
> your commit messages, Thomas. One first reason is to think that during
> reviews the reviewer has to scroll up to find the subject for the context
> this sentence applies to. And doing so quickly encourages to give a little
> bit more background to justify a change. I have a simple principle that
> works reasonably fine for this, which is that a commit subject should
> normally be unique in a project (modulo rare cases, reverts or accidents)
> and that commit message bodies should really always be unique. Here we
> see that it doesn't work ;-)

Complete Ack :-)
I tend to become lazy when I feel to get away with it.
Thanks for calling me out on it.

> An example could be something like this:
>
>   Glibc has been passing argc/argv/envp to constructors since version XXX.
>   This is particularly convenient, and missing it can significantly
>   complicate some ports to nolibc. Let's do the same since it's an easy
>   change that comes at no cost.
>
> Anyway I agree with the change, I wasn't aware of this support from glibc,
> so thank you for enlighting me on this one ;-)

It's meticulously undocumented,
and a very fringe usecase.

I'll use your proposal,  fill it with more background and apply it.


Thomas