Hi James,
On Fri, Dec 05, 2025 at 12:38:59PM +0000, James Addison wrote:
> My reading of the thread is that fcf-protection=return can be
> security-effective on 32-bit x86 processors, has no effect on binary
> size, and does not introduce the compatibility issues that
> fcf-protection=branch does.
In order for -fcf-protection=return to provide any benefit, a shadow
stack is required. That support has not trickled down yet. It is only
since trixie that 64bit enables CONFIG_X86_USER_SHADOW_STACK, so no
Debian i386 kernel ever enabled that. I also doubt that 32bit hardware
supports this in any way.
> I think this is what Helmut was pointing out -- the two halves of the
> flag's behaviour.
My clarification was that we're disabling both features, but doing so is
ok, because neither has any practical benefit on i386.
Helmut
Thank you, Helmut - that completely resolves my question.
And indeed, as I should have checked myself before emailing, the GCC Instrumentation Options documentation[1] confirms that enabling either the branch or return instrumentation via fcf-protection will cause a __CET__ macro to be emitted -- and it also mentions that hardware-level CET is *compatible* ('works') with i686 onwards (I think the subtext there is that the instructions are no-ops on i686 -- but as you mention, effective only on suitable x86-64 processors -- since those are the only processor models that handle the instruction other than as a no-o).
Regards,
James
Sorry, one more question came to mind after all: I realise that the advice in this thread only relates to the sudo:i386 package; however I believe it is the case that an x86-64 system can install and run i386 binaries alongside amd64 ones.
It seems unlikely to me that such a system would have both sudo:amd64 and sudo:i386 installed -- and hopefully even less likely that only sudo:i386 is installed (or preferred, e.g. by PATH).
Even so: does this mean that we should be careful about disabling fcf-protection=branch on a broader/default basis?