linux-kernel - Re: [RFC PATCH v1 0/8] nolibc signal handling support

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: <00eee75f-59fa-83b2-c7e1-f0da347b2dde@gnuweeb.org>
Date:   Tue, 27 Dec 2022 20:32:57 +0700
From:   Ammar Faizi <ammarfaizi2@...weeb.org>
To:     Willy Tarreau <w@....eu>
Cc:     Shuah Khan <shuah@...nel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Gilang Fachrezy <gilang4321@...il.com>,
        VNLX Kernel Department <kernel@...x.org>,
        Alviro Iskandar Setiawan <alviro.iskandar@...weeb.org>,
        Kanna Scarlet <knscarlet@...weeb.org>,
        Muhammad Rizki <kiizuha@...weeb.org>,
        GNU/Weeb Mailing List <gwml@...r.gnuweeb.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Kselftest Mailing List 
        <linux-kselftest@...r.kernel.org>
Subject: Re: [RFC PATCH v1 0/8] nolibc signal handling support

On 12/27/22 1:26 PM, Willy Tarreau wrote:
> Yes, and quite frankly I prefer to make that the least complicated.
> Doing just a simple loop in the _start code is trivial. The main
> concern was to store the data. Till now we had an optional .bss
> section, we didn't save environ and errno was optional. But let's
> be honest, while it does allow for writing the smallest programs,
> most programs will have at least one global variable and will get
> this section anyway, so we don't save anything in practice. This
> concern used to be valid when I was making tiny executables when
> running on floppies where each byte mattered, but now that's pointless.
> 
> Thus what I'm proposing is to switch to weak symbol definitions for
> errno, environ, and auxv. I did a quick test to make sure that the same
> symbol was properly used when accessed from two units and that's OK, I'm
> seeing the same instance for all of them (which is better than the current
> situation where errno is static, hence per-unit).

Looks good to me.

> Thus now my focus will be on storing these variables where relevant
> for all archs, so that your getauxval() implementation works on top
> of it. It will be much cleaner and will also improve programs' ease
> of implementation and reliability.

Are you going to wire up a patchset for it?

If so, I'll wait for it. When it's already committed, I'll base this
series on top it.

Or I take your series locally then submit your patches and mine in a
single series.

What do you prefer?

-- 
Ammar Faizi