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-next>] [day] [month] [year] [list]
Message-ID: <20240126142411.22972-1-rodrigo@sdfg.com.ar>
Date: Fri, 26 Jan 2024 15:24:10 +0100
From: Rodrigo Campos <rodrigo@...g.com.ar>
To: Willy Tarreau <w@....eu>,
	Thomas Weißschuh <linux@...ssschuh.net>
Cc: linux-kernel@...r.kernel.org,
	Rodrigo Campos <rodrigo@...g.com.ar>
Subject: [PATCH 0/1] tools/nolibc/string: export strlen()

Hi, while using nolibc on debian testing, I found that compilation fails when using strlcat().

The compilation fails with:

            cc -fno-asynchronous-unwind-tables -fno-ident -s -Os -nostdlib -lgcc  -static -o test test.c
            /usr/bin/ld: /tmp/cccIasKL.o: in function `main':
            test.c:(.text.startup+0x1e): undefined reference to `strlen'
            collect2: error: ld returned 1 exit status

This is using debian testing, with gcc 13.2.0.

A small repro case that fails with this error on debian is:

	int main(void) {
		char dst[6] = "12";
		char *src = "abc";
		strlcat(dst, src, 6);
	
		printf("dst is: %s\n", dst);
	
		return 0;
	}

Please note that this code is not using strlen() and strlcat() doesn't seems to use it either.

First I noted that removing the attribute unused in strlen(), the compilation worked fine. And then
I noticied that other functions had the attribute weak, a custom section and export the function.

In particular, what happens here seems to be the same as in commit "tools/nolibc/string: export memset() and
memmove()" (8d304a374023), as removing the -Os or adding the -ffreestanding seem to fix the issue.
So, I did the same as that commit, for strlen().

However, I'm not 100% confident on how to check that this is done by the compiler to later replace
it and provide a builtin. I'm not sure how that was verified for commit 8d304a374023, but if you let
me know, I can verify it too.

What do you think?


As a side note, it seems strlcat()/strlcpy() fail to set the terminating null byte on some cases,
and the return code is not always the same as when using libbsd. It seems to be only on "error"
cases, and not sure if it's worth fixing all/some of those cases.

Let me know if you think it is worth adding some _simple_ patches (I don't think it is worth fixing
all the cases, the code is to fix all of the cases is probably not nice and not worth it).


Best,
Rodrigo

---


Rodrigo Campos (1):
  tools/nolibc/string: export strlen()

 tools/include/nolibc/string.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.43.0


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ