Bug 1988402

I still see this with the updated current toolchain in testing:

Hardened: ./usr/lib64/libltdl.so.7.3.1: FAIL: stack-prot test because stack protection deliberately disabled (function: lt_strlcat) 
Hardened: ./usr/lib64/libltdl.so.7.3.1: FAIL: stack-prot test because stack protection deliberately disabled (function: dlopen_LTX_get_vtable) 

I'm investigating, but downloads from Stream Koji are *slow*.

First of all, I strongly recommend to call “make -O V=1”. Whith that, we see this:

/bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.  -DLT_CONFIG_H='<config.h>' -DLTDL -I. -I. -Ilibltdl -I./libltdl -Ilibltdl/libltdl -I./libltdl/libltdl   -O2  -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -c -o libltdl/lt__strl.lo libltdl/lt__strl.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -Ilibltdl/libltdl -I./libltdl/libltdl -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -c libltdl/lt__strl.c  -fPIC -DPIC -o libltdl/.libs/lt__strl.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -Ilibltdl/libltdl -I./libltdl/libltdl -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -c libltdl/lt__strl.c -o libltdl/lt__strl.o >/dev/null 2>&1

So -fstack-protector-strong has gone missing.

This is related to:

# See the rhbz#1289759 and rhbz#1214506.  We disable hardening namely because
# that bakes the CFLAGS/LDFLAGS into installed /bin/libtool and ltmain.sh files.
# At the same time we want to have libltdl.so hardened.  Downstream-only patch.
%undefine _hardened_build
Patch3: libtool-2.4.6-hardening.patch

That patch enables:

make %{?_smp_mflags} -O V=1 \
    CUSTOM_LTDL_CFLAGS="%_hardening_cflags" \
    CUSTOM_LTDL_LDFLAGS="%_hardening_ldflags"

But these build flags are no longer the complete story. They are not part of the documented interface: https://src.fedoraproject.org/rpms/redhat-rpm-config//blob/rawhide/f/buildflags.md

I'm testing a patch.

My efforts have not been successful. The issue is that lt__strl etc. are built from LTLIBOBJ, so libltdl_libltdl_la_CPPFLAGS does not apply to them.

I tried

libltdl_libltdl_la_CPPFLAGS += $(CUSTOM_LTDL_CFLAGS)
libltdl_libltdl_la_LDFLAGS  += $(CUSTOM_LTDL_LDFLAGS)
$(LTLIBOBJS): CPPFLAGS += $(CUSTOM_LTDL_CFLAGS)

with a rule-local variable change, but that did not work for some reason.

But /usr/bin/libtool contains this today:

LTCFLAGS="-O2  -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC"

This is what bug 1289759 and bug 1214506 tried to prevent, and no one has complained, so it does not look like a problem anymore. Maybe it is time to drop %undefine _hardened_build and libtool-2.4.6-hardening.patch.

In any case, this is exclusively a libtool bug (that actually demonstrates the value of annobin checking), although it looks a lot like the annobin bugs we dealt with recently.

After adding -fstack-protector-strong to CFLAGS the test passed. Florian, can you describe the reasons, why the hardening patch should be removed ? If we remove it, another test fails:

Hardened: /usr/lib64/libltdl.so.7.3.1: FAIL: bind-now test because not linked with -Wl,-z,now

Although, with adding -Wl,-z,now to CFLAGS, the test passes. I do not say removing the patch is bad, but is there any reason for it?

Thank you.

I think the main goal of the hardening patch was to avoid hard-coding downstream-specific build flags in the installed /usr/bin/libtool. But I think this hasn't worked as expected for a long time because there are many downstream-specific flags there.

> I think the main goal of the hardening patch was to avoid hard-coding downstream-specific build flags in the installed /usr/bin/libtool.

Not really, that's why `%_configure_libtool_hardening_hack` is set to 0.  The patch
was added to harden the libltdl.so file.

Pavel, Florian, thanks for your thoughts. I prefer adding fstack-protector-strong to CFLAGS and not touching other patches, as it can lead to multiple problems with other packages during build phase. Althought, it seems libltdl.so stays hardened also with adding -Wl,-z,now to CFLAGS, we do not particulary know, if some other flags are not missing.

MR:

https://gitlab.com/redhat/centos-stream/rpms/libtool/-/merge_requests/2

Annocheck tests have passed. No regression spotted, moving this forward. Adding annocheck test output.

Created attachment 1816710 [details]
log-annocheck.txt

It seems we are handling the flags one-by-one depending on what we notice is missing.

Wouldn't it be possible to run make first with the non-standard flags (to avoid them leaking to the tool) and then do another make run specifically for the libltdl.so so that it gets everything that rpm macros define?