Microcode Alternatives

Microcode reviews and mentions

• The legend of “x86 CPUs decode instructions into RISC form internally”
  6 projects | news.ycombinator.com | 18 Jun 2023

  Related:

  https://news.ycombinator.com/item?id=27334855

  https://www.google.com/search?q=%22christopher+domas%22+x86+...

  https://en.wikipedia.org/wiki/Alternate_Instruction_Set

  >"In 2018 Christopher Domas discovered that some Samuel 2 processors came with the Alternate Instruction Set enabled by default and that by executing AIS instructions from user space, it was possible to gain privilege escalation from Ring 3 to Ring 0.[5] Domas had partially reverse engineered the AIS instruction set using automated fuzzing against a cluster of seven thin clients.[12] Domas used the terms "deeply embedded core" (DEC) plus "deeply embedded instruction set" (DEIS) for the RISC instruction set, "launch instruction" for JMPAI, "bridge instruction" for the x86 prefix wrapper, "global configuration register" for the Feature Control Register (FCR), and documented the privilege escalation with the name "Rosenbridge".[5]"

  Also -- I should point out that the debate of if x86 (CISC) CPU's contain RISC cores -- is largely academic.

  Both RISC and CISC CPU's contain ALU's -- so our only debate, really, if we have one, is how exactly data that the ALU is going to process -- is going to wind up at the ALU...

  It is well known in the x86 community that the x86 instructions are an abstraction, a level of abstraction which runs on top of lower-level of abstraction, the x86 microcode layer...

  Historically, intentionally or unintentionally, most x86 vendors have done everything they can to hide, obfuscate, and obscure this layer... There (to the best of my knowledge, at this point in time) is no official documentation of this layer, how it works (etc., etc.) from any any major x86 vendor.

  x86 microcode update blobs -- are binary "black boxes" and encrypted.

  Most of our (limited) knowledge in this area comes from various others who have attempted to understand the internal workings of x86 microcode:

  https://www.google.com/search?q=%22reverse+engineering+x86+p...

  https://github.com/RUB-SysSec/Microcode

  https://twitter.com/_markel___/status/1262697756805795841

  https://www.youtube.com/watch?v=lY5kucyhKFc

  It should be pointed out that even if a complete understanding of x86 microcode were to be had for one generation of CPU -- there would always be successive generations where that implementation might change -- leaving anyone who would wish to fully understand it, back at square one...

• On “I don't trust microcode”
  4 projects | news.ycombinator.com | 30 Jan 2023

  For the Intel stuff you're talking about, there's three classes keys in play, two of which have been leaked, but not the one that allows you to impersonate Intel. What we have are the keys shipped on every actual system (that has been cracked, I think that's just for Goldmont), the symmetric encrypt/decrypt key (AES IIRC), and the public signing key to verify that it came from Intel. Intel's private keys behind the signature haven't been leaked.

  Interestingly though, it turns out that AMD K10 microcode updates weren't signed and had only the laziest form of encryption, allowing some security researchers to make custom ucode updates using this toolchain they posted on github: https://github.com/RUB-SysSec/Microcode

• Simulating the IBM 360/50 mainframe from its microcode
  2 projects | news.ycombinator.com | 25 Jan 2022

  From what little we know of recent designs (the best public documentation being the fantastic work to reverse engineer AMD K8 and K10 microcode here https://github.com/RUB-SysSec/Microcode ), I'd describe x86 microcode as particularly wide vertical microcode of 64 bit ops.

  The bit width is more a heuristic. With horizontal microcode you can look at each group of bits and it's clear 'these three bits are the selection input to this mux', 'this bit is an enable for the buffer linking these two buses', etc. Vertical microcode in contrast is further decoded with bit fields having different meanings based on opcode style fields.

  Pretty universally, OoO superscalar cores will use vertical microcode (or vertical microcode looking micro-ops in cores without microcode) because that's the right abstraction you want at the most expensive part of the design: the tracking of in flight and undispatched operations in the reorder buffer, and how the results route in the bypass network. Any additional wodtch there really starts to hit your power budget, and it's the wrong level for horizontal microcode because the execution units will make different choices on even how many control signals they want.

• Looking for a processor with no backdoors but has VT-x and VT-d (or equivalent). Thoughts?
  1 project | /r/TOR | 22 Jan 2021

  any chip that you can't physically inspect might have backdoors. and if a CPU has updatable microcode, it's possible to implement a backdoor in microcode. there's no way to make a verifiably safe CPU with the features you want.

• A note from our sponsor - InfluxDB
  www.influxdata.com | 4 May 2024

  Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →