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= <<a href=3D"mailto:[email protected]">[email protected]</a>> 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> > My reading of the thread is that fcf-protection=3Dreturn can be<br> > security-effective on 32-bit x86 processors, has no effect on binary<b= r> > size, and does not introduce the compatibility issues that<br> > 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> > I think this is what Helmut was pointing out -- the two halves of the<= br> > flag's behaviour.<br> <br> My clarification was that we'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* ('works') 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--