Editing Nopl
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
[[Category:Research]] {{DISPLAYTITLE:nopl}} | [[Category:Research]] {{DISPLAYTITLE:nopl}} | ||
During research for my [[ | During research for my [[Geode Repair]] projects, I found an amazing saga based around a CPU instruction. Nobody else has written this up from what I can see, so here's my take. | ||
== Background == | == Background == | ||
Line 32: | Line 32: | ||
In 1998 Christian Ludloff documented in his [https://web.archive.org/web/19981205142152/http://sandpile.org:80/80x86/opcodes2.shtml updated map of 2 byte x86 opcodes] that the 0F 18 through 0F 1F range of opcodes were hinting NOPs. The first being the 0F 18 opcode which maps to PREFETCHh instructions. I believe this information was documented first in the [https://www.cs.cmu.edu/afs/cs/academic/class/15213-s01/docs/intel-opt.pdf Intel Architecture Optimization Reference Manual]. | In 1998 Christian Ludloff documented in his [https://web.archive.org/web/19981205142152/http://sandpile.org:80/80x86/opcodes2.shtml updated map of 2 byte x86 opcodes] that the 0F 18 through 0F 1F range of opcodes were hinting NOPs. The first being the 0F 18 opcode which maps to PREFETCHh instructions. I believe this information was documented first in the [https://www.cs.cmu.edu/afs/cs/academic/class/15213-s01/docs/intel-opt.pdf Intel Architecture Optimization Reference Manual]. | ||
Later in 2003 Christian Ludloff clarified in an email thread [ | Later in 2003 Christian Ludloff clarified in an email thread [http://www.sandpile.org/post/msgs/20004129.htm Undocumented opcodes (HINT_NOP)] that these hinting NOPs were declared by Intel in their 1995 patent [https://patents.google.com/patent/US5701442A/en US5701442]. The idea behind this patent from my reading is that you can encode a program written in another ISA as a series of opcodes that are run as NOPs on older machines and the new ISA on a newer machine. | ||
I'm not sure why, but third party x86 CPUs aside from AMD didn't implement these NOPs. Perhaps Intel kept this patent close to their heart? Or maybe it's just not worth spending silicon and research on NOPs that nobody used? | I'm not sure why, but third party x86 CPUs aside from AMD didn't implement these NOPs. Perhaps Intel kept this patent close to their heart? Or maybe it's just not worth spending silicon and research on NOPs that nobody used? | ||
Line 178: | Line 178: | ||
In 2020 [https://github.com/sarah-walker-pcem/pcem/commit/b973755ca376dbb47c3a8c85a53f4058f0ccc54d Add hintable NOPs for Pentium Pro and II.] was committed to PCem. | In 2020 [https://github.com/sarah-walker-pcem/pcem/commit/b973755ca376dbb47c3a8c85a53f4058f0ccc54d Add hintable NOPs for Pentium Pro and II.] was committed to PCem. | ||
As for 2022 no DOSBox variant supports these hinting NOPs. | |||
== Intel CET == | == Intel CET == | ||
In 2016 Intel announced [https://web.archive.org/web/20160614162220/http://blogs.intel.com/evangelists/2016/06/09/intel-release-new-technology-specifications-protect-rop-attacks/ Control-flow Enforcement Technology] and released the [https://web.archive.org/web/20170320213641/https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf Intel CET specification]. These CPU extensions run not just in 64-bit mode but in 32-bit mode. While management for the shadow stack uses new instructions, the ENDBRANCH instruction intended to be compiled in to user space code re-uses the hinting NOP 0F 1E. | In 2016 Intel announced [https://web.archive.org/web/20160614162220/http://blogs.intel.com/evangelists/2016/06/09/intel-release-new-technology-specifications-protect-rop-attacks/ Control-flow Enforcement Technology] and released the [https://web.archive.org/web/20170320213641/https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf Intel CET specification]. These CPU extensions run not just in 64-bit mode but in 32-bit mode. While management for the shadow stack uses new instructions, the ENDBRANCH instruction intended to be compiled in to user space code re-uses the hinting NOP 0F 1E. | ||
In 2017 [https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=603555e563725616246912711419637add54c961 Add support for Intel CET instructions] was committed to the GNU Assembler. | In 2017 [https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=603555e563725616246912711419637add54c961 Add support for Intel CET instructions] was committed to the GNU Assembler. | ||
Line 189: | Line 187: | ||
Later in 2017 [https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2a25448c490b16eea276521d818640bcaca75e35 Update x86 backend to enable Intel CET.] was committed to GNU GCC. | Later in 2017 [https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2a25448c490b16eea276521d818640bcaca75e35 Update x86 backend to enable Intel CET.] was committed to GNU GCC. | ||
Even later in 2017 [https://github.com/llvm/llvm-project/commit/fec21ec0c6257eb24290c483b03b4fd9e6a9d0d1 LLVM r318995] added support for CET | Even later in 2017 [https://github.com/llvm/llvm-project/commit/fec21ec0c6257eb24290c483b03b4fd9e6a9d0d1 LLVM r318995] added support for CET. | ||
In 2021 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667 gcc generates endbr32 invalid opcode on -march=i486] was reported to GCC. The next day [https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=77d372abec0fbf2cfe922e3140ee3410248f979e x86: Error on -fcf-protection with incompatible target] was committed to GNU GCC. This patch limits CET to architectures with CMOV. That's a safe bet, but seems like it would break on the Geode LX800 and other i686-compatibles that lack multi-byte NOPs. | In 2021 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667 gcc generates endbr32 invalid opcode on -march=i486] was reported to GCC. The next day [https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=77d372abec0fbf2cfe922e3140ee3410248f979e x86: Error on -fcf-protection with incompatible target] was committed to GNU GCC. This patch limits CET to architectures with CMOV. That's a safe bet, but seems like it would break on the Geode LX800 and other i686-compatibles that lack multi-byte NOPs. | ||
Line 195: | Line 193: | ||
In 2022 [https://github.com/rust-lang/rust/issues/93059 i586-unknown-linux-gnu target generates binaries containing Intel CET opcodes which are illegal on i586 processors] was reported to the Rust bug tracker. A day or so later Gentoo committed [https://github.com/gentoo/gentoo/commit/bff66eedb4ae530ef21187d617daeba5472320a1 dev-lang/rust: pass -fcf-protection=none on i586] despite Rust not being available on i586 yet. It's unclear how much things will break if someone gets an actual i686 build of Rust going. | In 2022 [https://github.com/rust-lang/rust/issues/93059 i586-unknown-linux-gnu target generates binaries containing Intel CET opcodes which are illegal on i586 processors] was reported to the Rust bug tracker. A day or so later Gentoo committed [https://github.com/gentoo/gentoo/commit/bff66eedb4ae530ef21187d617daeba5472320a1 dev-lang/rust: pass -fcf-protection=none on i586] despite Rust not being available on i586 yet. It's unclear how much things will break if someone gets an actual i686 build of Rust going. | ||
TODO: isCFProtectionSupported IndirectBranchTracking | |||
As of early 2022 Intel CET support is not in the kernel yet. | As of early 2022 Intel CET support is not in the kernel yet. | ||