linux-kernel - Re: [PATCH 1/1] tools/nolibc: Add workarounds for centos-7

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: <741b7bed-919b-41c3-bd57-85e1cdfd6e48@sdfg.com.ar>
Date:   Wed, 27 Sep 2023 21:41:26 +0200
From:   Rodrigo Campos <rodrigo@...g.com.ar>
To:     Thomas Weißschuh <linux@...ssschuh.net>
Cc:     Willy Tarreau <w@....eu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] tools/nolibc: Add workarounds for centos-7

On 9/27/23 20:23, Thomas Weißschuh wrote:
> On 2023-09-27 15:06:03+0200, Rodrigo Campos wrote:
>> On 9/27/23 01:30, Thomas Weißschuh wrote:
>>> On 2023-09-26 15:36:47+0200, Rodrigo Campos wrote:
>> We can definitely remove that struct statx bits in our vendoring. It will
>> simplify updating if we don't have to patch it, so if we can't include a fix
>> in nolibc, I think we will continue doing the hack ourselves and that is
>> all. It is not too bad :)
> 
> How often are you planning on updating your vendoring?
> In the timeframe before you are dropping centos-7 support?

We will probably update if other MIPS variants are added, or other 
arches supported by golang. Other than that, I don't see that happening.

> The "nice" thing about the breakage is that it will break loudly during
> compilation so it will be easy to notice and fix it up.
> 
>> I don't think it is worth for nolibc, at least for this use case, to
>> reintroduce compatibility for stat() without statx().
> 
> It wouldn't even be full compatibility. The code would compile but be
> unusuable for stat()/statx(). And I don't think any application expects
> stat() to return -ENOSYS.

Right, it would not be fully compatible but it will be possible to 
compile and use the rest of the syscalls, just not stat().

It's really up to you to decide if that is worth or not. That happens to 
be what we need :)

> It's a bit ugly code to support a kernel that has been EOL upstream for
> six years for a fairly specific usecase.
> But who knows, maybe Willy has a soft spot for the 3.10 kernel :-)
> Let's wait for his input.

I can't agree more, that is why I was unsure supporting centos-7 was 
something we want to do in the first place.

Let's wait for Willy, but I will be slow to answer in the coming weeks, 
I'll be with limited internet connectivity.



Best,
Rodrigo