Bug#1113774: Disabling -fcf-protection in sudo for bookworm

James Addison <[email protected]> Fri, 5 Dec 2025 14:30:43 +0000
Newsgroups gmane.linux.debian.devel.ctte
Message-ID <CALDQ5NzeM7PFy23Q-KiWyuM=gU_9BhbZH5M8JM=8jNfk1XxbCw__24576.5998888359$1764945086$gmane$org@mail.gmail.com>
--00000000000002f9cf0645354906
Content-Type: text/plain; charset="UTF-8"

On Fri, Dec 5, 2025, 14:05 Helmut Grohne <[email protected]> wrote:

> 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

[1] - https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

>

--00000000000002f9cf0645354906
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote gmail_quote_container"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 5, 2025, 14:05 Helmut Grohne=
 &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi James,<br>
<br>
On Fri, Dec 05, 2025 at 12:38:59PM +0000, James Addison wrote:<br>
&gt; My reading of the thread is that fcf-protection=3Dreturn can be<br>
&gt; security-effective on 32-bit x86 processors, has no effect on binary<b=
r>
&gt; size, and does not introduce the compatibility issues that<br>
&gt; fcf-protection=3Dbranch does.<br>
<br>
In order for -fcf-protection=3Dreturn to provide any benefit, a shadow <br>
stack is required. That support has not trickled down yet. It is only <br>
since trixie that 64bit enables CONFIG_X86_USER_SHADOW_STACK, so no <br>
Debian i386 kernel ever enabled that. I also doubt that 32bit hardware <br>
supports this in any way.<br>
<br>
&gt; I think this is what Helmut was pointing out -- the two halves of the<=
br>
&gt; flag&#39;s behaviour.<br>
<br>
My clarification was that we&#39;re disabling both features, but doing so i=
s <br>
ok, because neither has any practical benefit on i386.<br>
<br>
Helmut<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"=
auto">Thank you, Helmut - that completely resolves my question.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">And indeed, as I should have checke=
d 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* (&#39;works&#39;) with i686 onward=
s (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).</div><div dir=3D"auto"><br></div><div dir=3D"auto">Regards,</di=
v><div dir=3D"auto">James</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">[1] - <a href=3D"https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Optio=
ns.html">https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html</a=
></div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div></div><=
/div>

--00000000000002f9cf0645354906--