Bug#1113774: Disabling -fcf-protection in sudo for bookworm
Marcos, Marc,
thanks for the prompt feedback. The TC was meeting this morning and
the gist of the discussion was "the definition of what i686 exactly is
is blurry, and independently from whether we think the CPU in question
is conforming to the specs, the problematic part of -fcf-protection is
a no-op on i386 and reverting that in sudo on that architecture seems
low risk and easy, so we'll recommend that". A formal write-up of that
will follow.
Minutes: https://meetbot.debian.net/debian-ctte/2025/debian-ctte.2025-09-25-08.00.html
Re: Marcos Del Sol
> So, according to Intel's own manual, these instructions must not be used
> on 2010 32-bit processors - and certainly not on 1995 Pentium III (i686)
> processors that Bookworm targets. If anything, I'd say Vortex86 processor
> is actually here in the right for raising UD# on a instruction that the
> manual states is reserved and invalid!
Yeah there's the Intel manual, and there's Intel processors which
might behave a bit differently, and some security fix was placed right
into that gap... But anyway, see above.
> > * reject the request; bookworm is already oldstable (if it's reaching us
> > only now, it's not that important)
>
> Just a tiny note: the first time this was reported was back in 2023-10-17
> by Justin on the debian-devel list (which you've linked) - four months
> Bookworm was declared stable.
>
> The amount of affected people certainly isn't going to be high (these are
> not super popular processors after all), but I bet many affected would
> have found that bug report (I did) and assumed it was not to be fixed, so
> there'll certainly be underreporting.
Ack, that is true.
Re: Marc Haber
> > Around the time of the discussion, upstream sudo included a change that limits
> > -fcf-protection to x86_64: https://github.com/sudo-project/sudo/pull/468
>
> The problem that I have with this change is that it was suggested by the
> same individual who wants us to do this change in Debian. Only sudo upstream
> didn't push back as hard as I did.
I guess that's kind of in line with the underreporting - for everyone
else, it's enough if one person stepped up to have it changed.
> I reaffirm that. Should the TC decline to give formal advice (which I would
> be fine with), I would go ahead to disable -fcf-protection for i386 builds
Marcos, since -fcf-protection has two parts "branch" and "return", and
only one of then is the problem, would you be willing to offer an
additional patch next to https://salsa.debian.org/sudo-team/sudo/-/merge_requests/24/diffs
which only enables the good one on i386 (I believe that's
-fcf-protection=return but I might well have lost track) in
sudo/bookworm?
Our idea was to have both variants on the table for Marc to choose from:
1) https://salsa.debian.org/sudo-team/sudo/-/merge_requests/24/diffs
is the minimal source change and disables the flag completely on i386.
2) -fcf-protection=return would be the minimal binary change in that
it only removes one part of the protection (however effective they
might be).
> (and verify that the amd64 and arm64 binary stay identical) and build
> packages for trixie and bookworm, submit both of them for the next point
> release.
Marc, do you have all tools to do that verification?
> Given that upstream went ahead with that change, I don't plan doing extra
> work for sid and forky, that'll happen in due time when I package the next
> upstream release.
Makes sense.
> Sadly, it will be at least mid october until I will have time to do that. So
> the TC can take the time to decide whether to go forward or not.
Ack.
> I really appreciate the work you did on this.
Thank you for being careful with this important package!
Christoph
Reply to: