[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Hi Christoph,

> The submitter claims the CPU is conformant,
> citing https://psc.informatik.uni-jena.de/hw/p-pro-3.pdf page 417 as saying
> ENDBR32 was "reserved". (The URL doesn't load for me now so I can't validate.)

Unfortunately Intel does not seem have archived versions of their manuals
available for download from their website. However I found an even newer
version from 2010 here (Core Nehalem era), which contains opcode maps:
https://ee209-2019-spring.github.io/references/253667.pdf

Page 661 states: "All blanks in opcode maps are reserved and must not be
used. Do not depend on the operation of undefined or blank opcodes."

ENDBR32 is F3 0F 1E FB, where:
 - F3 is the REP prefix
 - 0F 1E is the opcode
 - FB the ModR/M.

Looking at page 673 where 0F XX opcodes are, NOPL (0F 1F) and
PREFETCH (0F 18) both appear, but the space that would belong to 0F 1E
is empty, hence "reserved".

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!

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

Greetings,
Marcos


Reply to: