Hi! On Wed, 2025-09-03 at 16:24:50 +0200, Marcos Del Sol Vives wrote: > Package: dpkg-dev > Version: 1.22.21 > Priority: wishlist > X-Debbugs-Cc: debian-devel@lists.debian.org
> Currently, on amd64 and i386 as of Trixie, packages are being built by > default with -fcf-protection=full. This results in shadow stacks and IBT > (branch tracking) being enabled on binaries. dpkg-buildflags only emits «-fcf-protection» on amd64. > The issue is that, right now, user-mode applications running in the Linux > kernel in 64-bit mode only support shadow stacks. IBT protection is only > supported in the kernel, thus compiling user-mode applications with IBT > enabled results simply in an increased code size (due to generated ENDBR > landing instructions), all while offering no security improvements. Ah, for some reason I either read about it at the time and forgot, or this didn't register. So, (I think) part of the missing support is userland support for IBT in Linux, and then enabling CET in glibc with either --enable-cet or --enable-cet=permissive. This then should also be controllable at run-time through the glibc tunables with something like «GLIBC_TUNABLES=glibc.cpu.x86_ibt=permissive some-program». But AFAICT, this requires for all dlopen'ed objects to have been built with CET support, otherwise the dynamic linker might refuse to load them (depending on the CET mode above). And also AFAIUI for some objects built from assembler they need to be marked explicitly as supporting CET. So, disabling the full CET would regress the current support and make enabling it fully in the future harder. But it's not clear to me what's the status of submission for userland IBT in Linux. > 32-bit applications (either in native 32-bit mode or running under a 64-bit > kernel) do not support neither shadow stacks nor IBT. These are not getting the flags. > I have provided in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113774#96 > a very simple program alongside compilation instructions that proves this > being the case. > > By changing the default from -fcf-protection=full to -fcf-protection=return > (which only enables shadow stacks), the users would still experience the > exact same protection as they have right now, while generating smaller > binaries. So given the above, I'm inclined to mark this wontfix and close, and then "someone" needs to driver the transition to its conclusion. Thanks, Guillem
