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
