On Tue, Jun 20, 2023 at 09:39:46PM +0700, Alviro Iskandar Setiawan wrote:
> Hello Stefan,
> 
> On Tue, Jun 20, 2023 at 8:32 PM Stefan Hajnoczi wrote:
> > This is caused by the stack protector compiler options, which depend on
> > the libc __stack_chk_fail_local symbol.
> 
> liburing itself explicitly disables the stack protector, even when
> compiled with libc. You customize the build and use something that
> needs libc (stack protector). So I would say liburing upstream has
> taken care of this problem in the normal build.

Do you mean this:

src/Makefile:CFLAGS ?= -g -O3 -Wall -Wextra -fno-stack-protector

?

CFLAGS is set in the rpmbuild environment and therefore the ?= operator
has no effect. Here is the build log:
https://kojipkgs.fedoraproject.org//packages/liburing/2.4/2.fc38/data/logs/i686/build.log

If -fno-stack-protector is required, then the build system should fail
and let the user know that an unsupported flag was detected instead of
silently allowing an unsupported flag.

> 
> > The compile_prog check in ./configure should use the final
> > CFLAGS/LDFLAGS (including -ffreestanding) that liburing is compiled with
> > to avoid false positives. That way it can detect that nolibc won't work
> > with these compiler options and fall back to using libc.
> >
> > In general, I'm concerned that nolibc is fragile because the toolchain
> > and libc sometimes have dependencies that are activated by certain
> > compiler options. Some users will want libc and others will not. Maybe
> > make it an explicit option instead of probing?
> 
> I'm not sure it's worth using libc in liburing (x86(-64) and aarch64)
> just to activate the stack protector. Do you have other convincing use
> cases where libc is strictly needed on architectures that support
> liburing nolibc?

libc isn't strictly needed for stack protector. liburing could go
further down the path of duplicating libc symbols and implement
__stack_chk_fail_local itself.

However, I don't understand the reason for nolibc in the first place. Is
it because liburing is used by non-C languages where libc conflicts with
their runtime environment/library? I'm surprised by that since
FFI-friendly languages should be used to the presence of libc. Also, I'm
not sure why liburing.so should be nolibc for this use case, since there
is liburing-ffi.so specifically for FFI users.

> I think using stack protector for liburing is just too overkill, but I
> may be wrong, please tell me a good reason for using it in liburing.

I think that should be left up to packagers. Some distributions may want
to compile with a standard set of hardening options. I'm not sure what
the justification for making an exception for liburing should be?
Security folks won't be happy :).

> I admit that nolibc brings problems. For example, the memset() issue
> on aarch64 recently (it's fixed). If you have similar problems, please
> tell. We probably should consider bringing back the "--nolibc" option
> in the "./configure" file?

I don't have a strong opinion on the solution here, just that liburing
should compile successfully.

Thanks,
Stefan