Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return
Hi!
I've now filed #1114518 against glibc to request enabling CET in
permissive mode. I'll also prepare a change for the release notes,
which incorrectly state we have full CET support in trixie. :/
On Wed, 2025-09-03 at 18:14:05 +0200, Marcos Del Sol Vives wrote:
> El 03/09/2025 a las 17:47, Guillem Jover escribió:
> > 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
> > 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.
>
> Seems based on a random GitHub Gist that enabling (at least for testing)
> IBT in user-land is fairly straightforward on a Linux kernel:
> https://gist.github.com/sroettger/fe66f7eb0cb10a8ebd1454875a7131ea
>
> So I assume considering the little effort required to enable it, that it'll
> eventually also land in user-space. I would try enabling it on my machine
> out of curiosity with Trixie or Sid, but unfortunately my AMD 8745H does
> only support shadow stacks.
I think what complicates support is or has been how to expose that, and
with what ABI. From the multiple iterations of patches on Linux, the link
you post and from for example:
https://groups.google.com/g/x86-64-abi/c/iQWEW-iW8DQ
It's not really clear to me what needs to be done, or what are the current
blockers.
> > So given the above, I'm inclined to mark this wontfix and close, and
> > then "someone" needs to driver the transition to its conclusion.
>
> That's an option, yes.
>
> I opened this issue because I was asked to, and because I would personally
> wait until there are IBT-enabled kernels to enable one such flag to perform
> proper testing so binaries don't become larger prematurely.
>
> However I see your point enabling it now so all packages don't need to be
> recompiled further down with CET could be benefitial for a quicker rollout.
Yes, in theory, with just support from the Linux kernel and glibc,
we'd automatically get IBT support (if all shared objects are already
correctly marked). Someone would need to check which shared objects
are still not marked, in a similar way as what Emanuele Rocca has been
doing for arm64 (with its PAC and BTI counterparts).
But, if the current IBT approach seems undesirable, I'd still be open to
switch to -fcf-protection=return for now, and revisit how to handle IBT
later. CCing Florian for potentially more context and opinion.
Thanks,
Guillem
Reply to: