"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.
Rings are an extremely convenient abstraction when it comes to talking about operations that trap (so, basically, the whole foundation that security is built on). It's perfectly reasonable to keep talking about it even if the origins are no longer used (or usable at all, in long mode). It even makes sense with the NX bit, thanks to the control register that lets ring 0 bypass write protection.
To be clear, the only thing I'm disagreeing with here is your last paragraph.
None of this stuff is used anymore. We have the kernel in ring zero and we have everything else.
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.
Even x86 barely supports rings 1 and 2. The modern (386+) paging system only recognizes two privilege levels, and the fast privilege change instructions (SYSCALL, SYSRET, etc) are only useful when switching between rings (really "CPL") 0 and 3.
If you're programming a 286, then you can go whole hog with 4 rings.
In essence, the original concept of fixed number of rings that not only can, but have to, be distinguished by code runing in them is why there have to be hackish more-than-ring-0 modes like SMM.
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).
Sure. My point was more that the overwhelming majority of the privilege separation implemented in modern SoC's has absolutely nothing to do with a 33 year old "ring" model and we should stop using that term. It hurts more than helps.
