So you already have to be in ring 0. Pretty click baity title.
That said, I'm not particularly convinced that (unvirtualized) ring 0 to SMM is really a violation of a security policy... it's not like SMM really tries to confine what ring 0 can do, it just wants things like interrupt priority.
Also later ring 0 code can't get rid of code installed into SMM earlier (that may still trigger through events or timers).
it reminds me of the unlimited data plans that are limited after 5Gb.
Not sure what happened to language :)
"universal if you are root/can insmod/etc."
.. only needs to be true once, and from that point on the hardware no longer belongs to the owner.
So, if you could for example get your secretNSA$hit installed on the Linux box that is used to test hardware at the PC assembly/manufacturing plant, before its sent off to be 'securely configured' by the sysadmin/ops as supposedly fresh equipment.
Lots of ways that can happen, of course its theatrical to consider it, but little in security these days is without drama it seems.
Truly, not being able to trust the microcode in my CPU is a worry, but it always has been. There are no guarantees that there aren't already CPU embeds that are configured to ship data to some quantum-bearing government spy satellite, and thus we're all fools for thinking we have any kind of security on this theatrical stage at all ..
Multics supported 8+ rings, OpenVMS 3 rings, OS/2 3 rings, Windows NT and Unix only 2 rings. Some hypervisor like XEN use afaik ring 1 (Intel VT-x "Vanderpool").
We need better ring support in modern operating systems and hypervisors (VM hosts).
"The x86-processors have four different modes divided into four different rings. Programs that run in Ring 0 can do anything with the system, and code that runs in Ring 3 should be able to fail at any time without impact to the rest of the computer system. Ring 1 and Ring 2 are rarely used, but could be configured with different levels of access."
I found little resource about the project, but there is a discussion on Reddit:
And we had the discussion on HN too: https://news.ycombinator.com/item?id=7605687
Nevertheless an interesting topic, that doesn't deserve a downvote of my parent.
It's more that a ring 0 can manipulate an alternate context, but only for contexts that it can create. So guests can themselves be hypervisors for contexts that they themselves create. There's nothing stopping a guest from executing virtualization instructions.
That being said there is a sort of ring -1 called SMM mode.
 And this is why you shouldn't rely on wiki. Particularly since it looks like the deletionists are winning their war. It's source is informationweek in this case...
 Well, that's not totally true. When setting up the context for a guest you can signal that you as the hypervisor want to get trapped on lots of different types of privileged operations. ie. you can optionally, explicitly disallow the guest to use virtualization extensions. But it's opt in, not policy set by AMD/Intel.
Yes, but the article implies that you can e.g. do bad things in a bootloader and then have the OS run while the exploit stays resident and undetected by the OS.
This definitely has previously undocumented exploit potential if you can force the target to e.g. boot from a malicious USB device.
If you can control the boot media, aren't you already past the point where you need further exploits to control the machine?
We did get a few hypervisor crashes and the Intel architecture has all sorts of subtle behaviour that is often not modelled properly. It would be good to see someone build on my work.
Maybe this is something about controlled change of flow of execution in SMM mode?
Microcode seems about right - that was introduced in the P6. But, it's also signed (at least Intel ucode is - not sure about AMD) according to previous research... either way, this is going to be interesting.
Edit: public key. There might be a test mode which bypasses this or something.
That seems to fit with the idea of microcode, but it's pretty vague. What else would be running on every system from the P6?
After a reboot all went fine, though.
Basically this vulnerability affects multi-tennant systems where if you have a VM, you can then expoint this vulnerability to take control of a VM of somebody else.
This type of vulnerability, however rare, could be an argument why you should run systems with different security classifications on different physical hardware (different physical virtualisation clusters).
Yes. Always, always yes. Even if it's unfixable, ignorance of there even being a problem is not better.
> Is there anything analogous here for hardware?
Yes, actually. BIOS updates can include microcode updates and workarounds for hardware issues. Similarly if it takes a specific pattern to happen (which this almost certainly does as that's how these things work), that's going to be trivial for everyone's antivirus scanners to catch.
Also after disclosure what is the right course of action? We certainly can't require the replacement of all vulnerable hardware.
Who gains the most?
"Ring 0" is a historical abstraction from the 80286 protected mode model. There was a two bit field associated with segment and gate descriptors that enforced privilege separation, so you couldn't load segment registers with data at a higher priviledge level, and were disallowed from making traps into higher levels except as specifically allowed (we call those "syscalls" today).
None of this stuff is used anymore. We have the kernel in ring zero and we have everything else.
A hypervisor is absracting the whole CPU, so the guests have their own rings, etc... SMM is likewise outside the ring model.
And of course we have all sorts of other priviledge abstractions in modern hardware: iommu's exist for this purpose of course (though with a different threat model), as does memory mapping handled by microcontrollers on the fabric of modern SoCs. The NX bit doesn't fit into "rings" but is clearly related technology, etc...
Basically we need to stop talking about 286 protected mode except when that's really what we mean. Frankly I have no idea what this attack means by "ring 0", but I'm guessing like everyone else this is an exploit in SMM code.
To be clear, the only thing I'm disagreeing with here is your last paragraph.
Not using two of the four rings does not really mean nothing is used anymore. The reason only two are commonly used is probably to a large extend due to portability to processors with only two rings and maybe also architectural simplicity.
If you're programming a 286, then you can go whole hog with 4 rings.
Probably architecturally cleanest solution involves having only two modes with privileged operations in one affect hardware directly and in the other all such operations trap in a way that can be emulated. Interesting variation on this concept is having only simple trap and interrupt dispatcher running in the privileged mode with OS kernel being run in user mode as seen by hardware (Alpha does essentially this, but the privileged code depends both on hardware and operating system, so you don't get the benefits of easy virtualization).