As someone who just makes Crud apps can someone please ELI5 this. Why is this a big deal and why are people freaking out about intel chips becoming obsolete overnight ?
A CPU executes the machine instructions of your program (you might think of this as "assembly" programs, like "put a zero in register 12" or "jump to address 0xFF3392"). There have been architectures where instructions map directly onto transistors, but since System/360 (*) there's an extra level: the CPU has it's own, lower-level programming language that's used to execute the machine instructions. Finding out how a CPU actually works is interesting per se, and very valuable for competitors, but this work might also expose vulnerabilities and/or backdoors, built into the chip itself. It seems to be around 100kB of code, so there's a whole lot of opportunity...
As someone still at the "piecing things together" stage, here's my understanding:
There are a bunch of privilege levels in Intel CPUs (https://en.wikipedia.org/wiki/Protection_ring, relatively boring), used for memory protection and user/kernel mode separation (IIUC, I think I'm correct). They can be controlled by whatever code boots the CPU ("gets there first"), because the CPU boots in the most trusting state.
Over time the set of available levels proved insufficient for security and new levels were added with negative numbers so as not to disrupt the existing status quo. Ring -1 is used for virtualization and can also be controlled by whatever boots first (ie, outer code can create VMs and enter them, but the CPU faults if inner code attempts to access the virtualization instruction set), but Ring -2 and Ring -3 are used by the CPU itself.
Essentially, in the same way whatever the bootloader loads gets control over a bunch of interesting functionality because that code got there first, Ring -2 and -3 are controlled by code running directly on the CPU that gained control of the system before the bootloader and in some cases even UEFI was started. The significant elements are that a) this code can theoretically be altered by system (microcode) updates; b) these components run *completely* independently of the operating system - IIRC, the Management Engine is based on Minix running on a tiny 486-class core somewhere on the CPU die; and c) this invisible functionality has the ability to read and write all of system RAM. What's that? A glitch? A couple of bytes of RAM just got modified? That made the running Linux kernel suddenly think a process's effective UID is 0? Must have been the butterfly effect!
A bit of Googling found this overview of Ring -1 to -3 which I'd say is really good, definitely worth clearing your cookies to read if Medium is yelling at you about subscribing:
Microcode isn't persistent - on reboot you'll be running whatever version was in the CPU at manufacturing time. That means there's a path to booting to a known-good environment and updating the firmware, which will then load patched microcode before any attacker-controlled code can run.
As I understand it, you would need to have an existing RCE to exploit the microcode patching process.
h0t_max’s research means that future attacks — once your local machine has been infiltrated by some other means — can do a lot more damage than simply encrypting your filesystem or sending spam. They can rewrite the way your CPU works.
When your OS gets attacked by malware it is attacking the layer above the bare metal on which your OS runs. The base hardware remains untouched. You can at least clean things up by installing a new OS on the bare metal.
If malware attacks the bare metal itself, then you are stuck out of luck.
If there exists a backdoor, its unlikely to be remotely accessible. But privesc for any OS running a vulnerable CPU, absolutely. This would probably look like some hidden instruction to load and execute an arbitrary ELF at the XuCode level, not a magic packet.
Your OS loads a microcode update in to the CPU very early in the boot process, it's not a static firmware. Unless the microcode malware is sophisticated enough to block e.g. windows update, debian mirrors, then updating the system and rebooting to load a patched microcode would be sufficient to flush this out.
It isn't. There is unnecessary hysteria. Encrypting microcode is just usual competitive play. Doesn't mean anything nefarious. If issues are found in the said microcode, that would be a different story.
Microcode does spill the secrets of the hardware, so definitely don’t want competitors looking through.
Old ones though are open book (of a sort).
The 6502 for the apple II was obviously hand generated so it microcode is weird, but the 68k for the original Mac was pretty normal microcode as we would think of it today.
The 6502 is not microcoded, or at least not in the way we presently conceive of microcode. Its operations are driven by an on-board PLA which controls decoding and sequencing with its gates, which also explains its high performance per clock. It would be hard to call those gate connections micro-opcodes since they're not really used in that sense.
The 6502 uses "horizontal microcode", which, as you said, are the individual control lines. x86 uses "vertical microcode" which is a sort-of internal RISC architecture.
I'd like to talk about how we patch this pervading cynicism and
replace it with a model that's actually useful.
It isn't true on face value. Consider the course of the Cov19
pandemic. Two things spread. One was a virus. The other was an idea,
news about a virus. The latter spread much faster than the former. It
spread because people love "doom". Any story about the impending "end
of everything" is lapped up, relished and shared by the public.
There are well understood stages to information propagation. After "Is
this real?" and "Am I affected?" comes the question of "what to do?"
I think this is where your assertion about "care" comes in. Some
events will blow-up and burn out fast. People run around like headless
chickens enjoying the drama about something remote to their lives, but
ultimately nobody can do anything, so focus recedes. Wars and
famines are like that. Curtis calls this "Oh Dearism".
Alternatively, if there is any residual effect, new events connected
to the initial story, it feeds and grows. The initial "All the chips
are broken!" story that would die after a 24 hour news cycle becomes
an ongoing "situation". Then people care, because it's cool to care.
It gets a catchy handle "Evil-Inside" and a news slogan "The chips are
down". And then it won't go back in the bottle.
To reformulate your "Nobody cares" - as a question - "Do people have
sensible cares that are proportionate to the threat?" No. But if the
media tells them to care because cars are running off the road and
there's a massive uptick in cybercrime, which nobody can ignore and is
directly attributable to a single cause, then the "care" (hysteria)
can get worse than the problem (which may have happened with Cov19 to
some degree).
Finally, they may care, but about completely the wrong thing. One
suspects, if it turns out there is indeed some serious drama in Intel
chips, then Intel and the US government will try to paint the security
researchers as irresponsible hackers who unleashed this upon the
world.