8

Concept of Rings

x86 ringsRings were introduced in the forerunner of UNIX, Multics, and had 8 rings for reading, writing, executing and calling (I don't quite understand why it needed 8 rings to do this, if anybody does consider that a bonus question!). The x86 architecture by Intel incorporated the idea of rings into hardware, with 4 rings corresponding to ring 0 being for the kernel, 1 and 2 for device drivers, and 3 for applications.

Situation in 2019

Ring 0 and 3 are typically the only ones used in modern x86 operating systems for most users, with ring 0 being reserved for kernel-level operations and ring 3 for user-level, although there are some exceptions; for example, VirtualBox uses ring 1 to allow the use of virtual hosts. Generally, code in ring 3 can't access memory or operations in ring 0, although that was at the root of issues from Spectre and Meltdown disclosed in January 2018.

'Ring -1' has also been introduced for hypervisors - Intel VT-X and AMD-V add 9 machine code instructions, introducing the concept of ring -1. Ring -2 is typically called SMM (system management mode) and is used for very low level operations such as power management and used only by system firmware. It has been used with multiple exploits for rootkits to reside in without the operating system being able to interefere.

'Ring -3' was coined for levels operating below that after an attack was demonstrated by Invisible Things on the Intel Q35 chipset (fixed in Q45 and later). This worked by remapping the first 16 MB of RAM reserved for the Intel Management Engine and operated even with a device in an S3 state.

ARM processors seem to use only 3 rings, ordered the other way around; PL0 being user, PL1 being operating system, PL2 being hypervisor. See Figure 3.20 and this page from ARM.

Summary and question

There have been several exploits over the years demonstrating exploits on rings outside those originally described by the x86 architecture. What would an even lower-level ring look like (ring -4 in Intel, PL3 in ARM, or ring -3 in AMD) and has there has been any work regarding exploits in this area. Additionally, I've tried to follow the guide on good suggestive questions so that explanations on the 'how' and 'why' are applicable.

  • 1
    Note that the negative rings are not real rings. They were just given that nickname. A real ring is a value of CPL (Current Privilege Level), which cannot be negative. There's CPL0, CPL1, CPL2, and CPL3, and nothing else. – forest Sep 5 '19 at 7:14
  • I think ring 2 was also used for OS/2 drivers. – forest Sep 5 '19 at 7:48
4

Negative rings are false rings. They are not actual privilege levels of the CPU. The way rings work is simple. Some instructions have privilege checks where they verify that the current privilege level, or CPL, is sufficient and if it is not, the instruction fails with a general protection fault. CPL0 is ring 0, CPL1 is ring 1, etc. Some instructions will require a certain privilege level depending on the value of its operands (for example, mov may return a GPF if the CPL is insufficient and the memory address given to it requires ring 0 to access, or if a register given to it is privileged). Others always require a higher privilege level.

An example is the RDTSC instruction. It will throw a general protection fault unless either the TSD bit in CR4 (the fourth control register) is unset, or the current privilege level is zero, or the system is in real mode (determined by checking if the PE bit in CR0 is unset). This instruction is internally defined as:

if(CR4.TSD == 0 || CPL == 0 || CR0.PE == 0) EDX:EAX = TimeStampCounter;
else Exception(GP(0));

I wrote a bit more about rings and their uses in this answer.

There is no such thing as a negative privilege level. They don't exist. Ring -1 is a nickname for hypervisor functionality (VT-x on Intel). Ring -2 is a nickname for System Management Mode context, or SMM, which executes isolated code when a special interrupt called an SMI occurs. Ring -3 is a nickname for the code that runs on the CSME, an i486/i586 hybrid co-processor inside modern Intel chipsets that, indirectly, has access to system memory (I say indirectly because it's not designed for full memory access, but it does expose a virtual PCIe device, and it turns out that it can also interfere with DMAR, used by the IOMMU).


What would an even lower-level ring look like

The only thing that could be thought of as lower than any of these is called probe mode (which is, again, not a real ring). It is initiated by JTAG and provides an extreme amount of control over the entire CPU. Probe mode is not nearly as powerful as it used to be, but presumably there are ways to unlock a much more complete version of probe mode with access to special Intel hardware and credentials.

has there has been any work regarding exploits in this area

Not really. JTAG requires physical access and, for Intel, a password specific to the CPU's serial number.

  • The JTAG password requirement is optional/vendor specific, none of the chips I have used required a JTAG password. – markus-nm Sep 5 '19 at 8:48
  • @markus-nm Non-development Intel boards typically require a JTAG password. – forest Sep 5 '19 at 8:56
  • But JTAG is not limited to Intel chips. Virtually all ARM cortex chips are using JTAG and/or SWD. Most of them can be password protected, but none of them require that. – markus-nm Sep 5 '19 at 8:57
  • 2
    Agreed. Negative rings are an analogy at best. Or a metaphor. – Gaius Sep 5 '19 at 9:18
  • 1
    @LTPCGO The VT-x extensions don't make a true ring (see security.stackexchange.com/a/175826/165253). It just enables vmexit and the like. A task will still be CPL0 through CPL3, VM or not. It's just that for a guest, a privileged instruction will trigger a vmexit so the hypervisor can deal with it before resuming the VM. In fact, from the perspective of individual instructions, there's no difference between being in a guest or host! – forest Sep 5 '19 at 10:19
1
+50

I will stay with the intel/x86 architecture for my answer, but it can probably be applied to other vendors/ring-designs.

Ring -3 is 'the computer that runs your computer', the management engine on the mainboard. So the next logical step would be to look for a chip on the motherboard that could exercise total control over the system. The only thing I can think of would be the RAM.

Now you might say that RAM doesnt really control anything as it's just a stupid buffer, and the RAM is directly controlled by the management engine. However, atleast one company has been marketing their RAM with embedded microcontroller(s). It is supposedly used to off-load repetitive in-memory tasks to the controller embedded into the memory die.

If you can control the actual RAM, you can control anything in the system, possibly except the management engine if it has it's own memory. The microcontrollers on these devices must have full access to the RAM to do their work.

As for work done regarding exploits: these devices are far from being standardized, so using their special features will be done from kernel or usermode drivers. So you need vendor-specific exploits, as they will have vendor-specific drivers, to access the microcontroller on the RAM chips.

  • Could the same be said regarding memory controllers on CPUs? IIRC that's how the ITL attack took place, by poisoning the CPU cache – LTPCGO Sep 4 '19 at 20:20
  • This isn't entirely correct. There are multiple designs for protecting data from RAM, with the simplest being encryption or even register-only code execution. It's not hard to remove RAM from the TCB. – forest Sep 5 '19 at 7:28
  • It's not hard to remove any other thing from the TCB either. You can run your computer without hypervisor, kernel or anything. It's just a lot more work and orders of magnitude more complex to do so. So this isnt really an argument, as RAM encryption/protection is not a common scenario. – markus-nm Sep 5 '19 at 8:40
  • RAM encryption is getting to be common with TSME (Intel) and SME (AMD). – forest Sep 5 '19 at 8:48
  • 1
    @LTPCGO Then sensitive computations could be done in registers only, or CAR mode could be enabled and sensitive data kept in cache. Both of those would remove RAM from the TCB but would still be vulnerable to "ring -2" exploits. – forest Sep 9 '19 at 2:18
0

I do not agree that negative rings are false rings. They are quite real. Let's take -1 for example: having control of it almost guarantees having control over anything starting with 0 (with very few exceptions). Nothing unreal about it.

Here's how I see it today:

  • Ring 3 - user-level

  • Ring 2 - driver level (actual drivers)

  • Ring 1 - driver emulation level (like for audio and IRQ software layering since Vista)

  • Ring 0 - kernel level

  • Ring -1 - VM level (hypervisors)

  • Ring -2 - HW management systems (like iDRACs)

  • Ring -3 - IME & similar HW

A ring -4 could exist if one could find a way to manipulate electrical signals to achieve a specific purpose like affecting a hardware component in such a manner that part of it's basic functions are disabled, jammed or altered. This is in theory entirely possible, but was never demonstrated in public as far as I know. It would also require specially-designed hardware.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.