Bug#1005863: gcc: should reject combination of i686 architecture and fcf-protection feature
On Fri, 24 Mar 2023 10:55:27 +0000 James Addison <jay@jp-hosting.net> wrote:
> Followup-For: Bug #1005863
> Control: reassign -1 gcc-11 11.2.0-16
> Control: retitle -1 gcc: should reject combination of i686 architecture and fcf-protection feature
> Control: affects -1 sudo
> Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713
>
> After taking more time to learn about the initially-reported issue here, I'm
> resetting many of the bug's fields to match that, and adjusting the title to
> correspond with the upstream bug.
>
> The 'sudo' package is configured to use 'fcf-protection' (Intel Control-flow
> Enforcement Technology), and that feature uses an instruction 'endbr32' on
> 32-bit architectures that is a repurposed long-NOP, not supported by all i686
> processors.
>
> The request in the upstream bug report is that GCC should reject the
> combination of i686 and fcf-protection because it emits code that does not
> function on all processors within that architecture class.
>
> We documented that Geode LX support is retained[1] in Debian stretch, and to my
> knowledge have not indicated otherwise since then.
>
> I'll continue to focus on finding other packages and toolchain elements where
> the NOPL opcode is generated and to find places where it's possible to safely
> improve on that.
>
> [1] - https://www.debian.org/releases/stretch/i386/release-notes/ch-whats-new.en.html#idm120
>
> [2] - https://www.debian.org/releases/buster/i386/release-notes/ch-whats-new.en.html#idm120
>
> [3] - https://www.debian.org/releases/bullseye/i386/release-notes/ch-whats-new.en.html#idm120
>
> [4] - https://www.debian.org/releases/bookworm/i386/release-notes/ch-whats-new.en.html#idm120
Bookworm also retains Geode LX support, for the most part (Go and Rust
packages, and sudo being the only notable exceptions).
The key problem is with sudo. Without it, the only way for a
non-privileged user to perform any action is via 'su' which opens a
social trust issue since it requires knowing the root password. With
'sudo' the user only needs to confirm their own password and be
authorized to use the desired command via /etc/sudoers.
Martin-Éric
Reply to: