Your message dated Sun, 7 Jun 2026 13:48:53 +0200
with message-id <[email protected]>
and subject line Re: Bug#1113864: Replace -fcf-protection=full with
-fcf-protection=return
has caused the Debian Bug report #1113864,
regarding Replace -fcf-protection=full with -fcf-protection=return
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1113864: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113864
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.22.21
Priority: wishlist
X-Debbugs-Cc: [email protected]
Hello everyone.
I have been instructed by Helmut Grohne from the technical commitee
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113774#126)
to open a bug here to ask for a change in the current hardening defaults
of Debian for sid and future stable releases.
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.
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.
This is stated in the kernel documentation
(https://docs.kernel.org/next/x86/shstk.html):
> Today in the 64-bit kernel, only userspace shadow stack and kernel IBT
> are supported.
32-bit applications (either in native 32-bit mode or running under a 64-bit
kernel) do not support neither shadow stacks nor IBT.
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.
--- End Message ---
--- Begin Message ---
Hi!
On Wed, 2025-09-17 at 00:08:12 +0200, Guillem Jover wrote:
> On Tue, 2025-09-16 at 10:20:43 -0700, H.J. Lu wrote:
> > On Tue, Sep 16, 2025 at 9:26 AM Edgecombe, Rick P wrote:
> > > On Tue, 2025-09-16 at 09:50 +0200, Guillem Jover wrote:
> > > > > I'm not aware of any current public activities to enable userspace
> > > > > IBT. I haven't see any recent attempt to define a userspace/kernel
> > > > > ABI,
> > > > > or to test (and port where necessary) userspace.
> > > >
> > > > Thanks. So, do any of you (Florian, Rick, Yu-cheng, H.J., or perhaps
> > > > other people who have been working on this elsewhere) think we should
> > > > switch to -fcf-protection=return (from -fcf-protection)? Or are there
> > > > plans to add the userland IBT support in Linux in the near future?
> > > > Otherwise it indeed seems like a bit of a waste for now?
> > >
> > > I'd still like to do it, but it's fair to say it's not imminent. This
> > > seems
> > > like a reasonable course of action.
>
> Ah, thanks! It was really not clear whether these efforts had died off,
> or were just on pause. But if there's intention to implement it, even
> if it might take a couple of years, then I think leaving the
> -fct-protection option as is might be fine, as long as the current ABI
> is not going to change (see below).
>
> > With ENDBR64 in place, dynamic user space binaries will get IBT enhancement
> > automatically via a glibc update when user space IBT is enabled in Linux
> > kernel.
>
> Right, that was my initial thinking as well [M], but that would depend
> on whether the implementation will still rely on endbr64 being in all
> function prologues or whether it might end up with something like what
> Florian proposed in <https://groups.google.com/g/x86-64-abi/c/iQWEW-iW8DQ>.
> Because at that point we'd need to rebuild everything anyway.
>
> [M] <https://lists.debian.org/debian-devel/2025/09/msg00109.html>
So as mentioned on that debian-devel thread, it seems there is still
interest from upstream, and having the instruction in place means we
could just gain full support for it whenever a Linux and glibc grow
support for it. Either completely getting rid of it, or changing the
ABI (as has been proposed in the past), would both require a mass rebuild
at which point I think it makes more sense to leave things as-is for
now and reconsider what to do in the future.
The code in dpkg now also contains a note to that effect to not forget
about this. And meanwhile we fixed the release-notes to avoid stating
incorrect information about the current support.
So with all the above, I'm just going to close this now.
Thanks,
Guillem
--- End Message ---
