From: guillem@debian.org 
  
 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 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)