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

--000000000000c46b610645361164
Content-Type: text/plain; charset="UTF-8"

On Fri, Dec 5, 2025, 14:30 James Addison <[email protected]> wrote:

> 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
>

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?

>

--000000000000c46b610645361164
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:30 James Addison=
 &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.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"au=
to"><div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Fri, Dec 5, 2025, 14:05 Helmut Grohne &lt;<a href=3D"mailto:helmut@subdiv=
i.de" target=3D"_blank" rel=3D"noreferrer">[email protected]</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;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" target=3D"_blank" rel=3D"noreferrer">https://gcc.gnu.org/onlinedoc=
s/gcc/Instrumentation-Options.html</a></div></div></blockquote></div></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">Sorry, one more question came=
 to mind after all: I realise that the advice in this thread only relates t=
o the sudo:i386 package; however I believe it is the case that an x86-64 sy=
stem can install and run i386 binaries alongside amd64 ones.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">It seems unlikely to me that such a s=
ystem would have both sudo:amd64 and sudo:i386 installed -- and hopefully e=
ven less likely that only sudo:i386 is installed (or preferred, e.g. by PAT=
H).</div><div dir=3D"auto"><br></div><div dir=3D"auto">Even so: does this m=
ean that we should be careful about disabling fcf-protection=3Dbranch on a =
broader/default basis?</div><div dir=3D"auto"><div class=3D"gmail_quote gma=
il_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"auto"><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"></blockquote></div></div></div>
</blockquote></div></div></div>

--000000000000c46b610645361164--