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: <Zrpksrnrbykx+IML@1wt.eu>
Date: Mon, 12 Aug 2024 21:38:26 +0200
From: Willy Tarreau <w@....eu>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: Ammar Faizi <ammarfaizi2@...weeb.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] tools/nolibc: x86_64: wrap asm functions in functions

Hi Thomas,

On Mon, Aug 12, 2024 at 07:01:26PM +0200, Thomas Weißschuh wrote:
> > > The memcpy / memmove combination could be split up into one real
> > > function and one C inline wrapper and then the same pattern would apply.
> > > 
> > > But to be honest I'd be fine with not supporting -flto on GCC.
> > 
> > That could also be a reasonable solution. The primary goal of nolibc
> > is to make it easy for developers to develop tests, and for those who
> > want to create pre-boot code to do so. By nature this code is prone to
> > bugs. If it becomes totally unreadable for very unlikely cases, it will
> > cause issues that are hard to debug by the users themselves. It's sure
> > that supporting a variety of compilers and setups is great, but we should
> > keep in mind the maintainability goal when thinking about this. I think
> > that LTO will mostly be used for testing, and in this case I think it's
> > totally reasonable to restrict the choice of compatible compilers.
> 
> IMO LTO is useful for nolibc to reduce the size of the generated binaries.
> For example the custom function sections that then can be combined with
> --gc-sections to get rid of unused functions is all implicit in LTO.
> And on top of that it can perform other size optimizations.

Well, probably, but my experience of it till now has been quite negative,
between stuff that doesn't build and stuff that takes ages to link on a
single core, for most of the time tiny to no gain at all :-/  But I admit
that in our case here at least we shouldn't witness long link times.

> But the complications for GCC are not worth it.
> And there seem general with LTO on GCC anyways as evidenced by the
> constructor and duplicate-asm bugs.

Yes, and the trouble it will cause will result in a lot of head-scratching
for those affected.

> After this discussion I think we should also change the __nolibc_naked
> attribute back to __nolibc_entrypoint as it was before.
> It is indeed not a replacement for a proper "naked".

Indeed, it sort of emulates it but does not have the exact same properties
as we've seen.

> What do you think about me rewriting the existing commits on nolibc-next
> to fix this up?

I'm obviously fine with this :-)

Thank you!
Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ