linux-kernel - Re: [PATCH v6 0/2] tools/nolibc: fix up size inflat regression

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]

Date:   Sun, 13 Aug 2023 21:56:59 +0800
From:   Zhangjin Wu <falcon@...ylab.org>
To:     w@....eu
Cc:     arnd@...db.de, david.laight@...lab.com, falcon@...ylab.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        tanyuan@...ylab.org, thomas@...ch.de
Subject: Re: [PATCH v6 0/2] tools/nolibc: fix up size inflat regression

Hi, Willy

> On Sat, Aug 12, 2023 at 05:49:36AM +0800, Zhangjin Wu wrote:
> > After these two patches, will send the proposed my_syscall() patchset
> > tomorrow, it can even further reduce more type conversions and therefore
> > reduce more binary bytes, here is a preview of the testing result:
> > 
> >    // with the coming my_syscall() patchset, sys_* from functionsn to macros
> >      i386: 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning 19250
> >    x86_64: 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning 21733
> (...)
> > It can also shrink the whole sys.h from 1171 lines to around 738 lines.
> 
> Please, Zhangjin, please. Let's stop constantly speaking about potential
> future improvements when the present is broken. It needlessly adds a lot
> of noise in the discussion and tends to encourage you to explore areas
> that are incompatible with what is required to fix the breakage, and
> very likely steers your approach to fixes in a direction that you think
> is compatible with such future paths. But as long as existing code is
> broken you cannot speculate on how better the next iteration will be,
> because it's built on a broken basis. And I would like to remind that
> the *only* reason for the current breakage is this attempt to save even
> more code lines, that was not a requirement at all in the first place!
> Sure it can be fine to remove code when possible, but not at the cost of
> trying to force squares to enter round holes like this. The reality is
> that *some* syscalls are different and *some* archs are different, and
> these differences have to be taken into account, and if we keep exceptions
> it's fine.
>

Agree very much, that's why I didn't send the new patchset but only send
these two ones about size inflate regression, I don't want to discuss
more than one issue at a time either (and you also have shared this idea
several times) ;-)

The progress and preview data here is only because the patch 1/2 [1] is
an important preparation of the new patchset, the data here is more or
less providing a selling point why we need patch 1/2, I have explained
it in this reply [2]. Of course, we can roll them back directly, and If
we do need sys_brk/mmap return 'long', we can revert the rolling-back
and apply patch 1/2.

    [PATCH v6 1/2] tools/nolibc: let sys_brk, sys_mmap and sys_mmap2 return long

> So let's only speak about this later once the issue is completely solved.
>

Ok, it is the right direction.

Best regards,
Zhangjin
---
[1]: https://lore.kernel.org/lkml/82b584cbda5cee8d5318986644a2a64ba749a098.1691788036.git.falcon@tinylab.org/
[2]: https://lore.kernel.org/lkml/20230813132620.19411-1-falcon@tinylab.org/

> Thanks,
> Willy