linux-kernel - Re: [PATCH 2/4] tools/nolibc: Fix strlcat() return code and size usage

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: Tue, 13 Feb 2024 06:27:52 +0100
From: Rodrigo Campos <rodrigo@...g.com.ar>
To: Willy Tarreau <w@....eu>
Cc: Thomas Weißschuh <linux@...ssschuh.net>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] tools/nolibc: Fix strlcat() return code and size
 usage

On 2/13/24 00:16, Rodrigo Campos wrote:
> On 2/11/24 11:48, Willy Tarreau wrote:
>> The test inside the loop is going to make this not very efficient. Same
>> for the fact that we're measuring the length of src twice (once via
>> strlen, a second time through the loop). I've just had a look and it
>> compiles to 77 bytes at -Os. A simpler variant would consist in trying

What code are you compiling that uses strlcat?

I've tried dropping almost all the flags to leave only:
	-Os -nostdlib -lgcc

And I still don't see the 77 bytes.

> $ nm --size -t x test.o
>      0000000000000004 V errno
>      0000000000000006 t strlcat.constprop.0
>      0000000000000008 V _auxv
>      0000000000000008 V environ
>      000000000000000e W strlen
>      000000000000000f W _start
>      0000000000000018 W raise
>      000000000000001b W abort
>      000000000000004c T main
>      000000000000005a t u64toa_r.isra.0
>      0000000000000095 W _start_c
>      00000000000002a8 t printf
> 
> How are you measuring it there?

btw, sorry for the late reply. I was on a flight that was rebooked, it 
took me some days to arrive. But I finally arrived and have internet now :)

The constprop seems to be some gcc optimization to simplify things.

I see what happens. The example I was compiling was left with size=0 (a 
leftover from when I was testing the code). That is very easy for gcc to 
optimize it all out. That is why it can make it so small.

If I compile the example from my original email, though, I still don't 
see the 77 bytes you mention. I see 31 in the nm output, that in decimal 
is 49 bytes.

Maybe tomorrow with some sleep after the long flight, I see what else is 
happening :)

Best,
Rodrigo