Bug#1113774: Disabling -fcf-protection in sudo for bookworm
James Addison <[email protected]> Fri, 5 Dec 2025 14:43:02 +0000
| Newsgroups | gmane.linux.debian.devel.ctte |
|---|---|
| Message-ID | <CALDQ5NyRZeeuiT+Xk4o03mhn37ojWv1VCLjg+KLswvDXS7MBig__25115.2826867596$1764945838$gmane$org@mail.gmail.com> |
--000000000000fbc4be0645357440 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 5, 2025, 14:31 Paul Tagliamonte <[email protected]> wrote: > 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. > > [snip] > > >So to reformulate that as a question: why is the advice to remove the > >flag completely, instead of reducing it to fcf-protection=return? > > This requires kernel support to be effective - and Bookworm does not > have a kernel with that flag turned on. I understand there to be no > difference between disabling fcf-protection entirely vs return in i386 > for Bookworm. > [ ... snip ... ] Thanks, Paul. I briefly wondered about people who could be running custom kernels (e.g. with support enabled) in combination with the Debian sudo (and potentially other) binaries, or that Debian might choose to enable it at the kernel config level in futute -- but, given my understanding is that the patch will only affect i386 packages, and that the CET instructions are no-ops on that platform, I think that that consideration is moot. > --000000000000fbc4be0645357440 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:31 Paul Tagliamo= nte <<a href=3D"mailto:[email protected]">[email protected]</a>> wr= ote:<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">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<br= > >size, and does not introduce the compatibility issues that<br> >fcf-protection=3Dbranch does.<br> <br> [snip]<br> <br> >So to reformulate that as a question: why is the advice to remove the<b= r> >flag completely, instead of reducing it to fcf-protection=3Dreturn?<br> <br> This requires kernel support to be effective - and Bookworm does not <br> have a kernel with that flag turned on. I understand there to be no <br> difference between disabling fcf-protection entirely vs return in i386 <br> for Bookworm.<br></blockquote></div></div><div dir=3D"auto"><br></div><div = dir=3D"auto">[ ... snip ... ]</div><div dir=3D"auto"><br></div><div dir=3D"= auto">Thanks, Paul.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I br= iefly wondered about people who could be running custom kernels (e.g. with = support enabled) in combination with the Debian sudo (and potentially other= ) binaries, or that Debian might choose to enable it at the kernel config l= evel in futute -- but, given my understanding is that the patch will only a= ffect i386 packages, and that the CET instructions are no-ops on that platf= orm, I think that that consideration is moot.</div><div dir=3D"auto"><div c= lass=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote= " style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= padding-left:1ex"> </blockquote></div></div></div> --000000000000fbc4be0645357440--