The quest for ring zero

Federico Biancuzzi sits down with French researcher Loïc Duflot and speaks about the System Management Mode attack, how to mitigate it, what hardware is vulnerable, and why we should be concerned with recent X Server bugs.

A feature called System Management Mode, included in modern x86 cpus, opens the way to the land of kernel space and the quest for ring zero.

Could you introduce yourself?

I am a security engineer and researcher for the scientific division of the French National Security Agency, namely the Central Directorate for Information Systems Security in Paris. I am also a second year Phd student in Paris XI University. My research work is mostly focused on the security aspects of interactions between hardware components and software.

What is SMM?

SMM stands for System Management Mode. System Management Mode is one of the four modes of operation of most x86 processors (Intel Xeon, Intel Pentium, or AMD Athlon, for instance). Modern operating systems (such as Linux, BSD, or Windows) run in so-called protected mode. In protected mode, four different processor privilege levels (also called rings) are available, ring zero being the most privileged one and ring three the least privileged. Kernels of operating systems run in ring zero, whereas userspace code runs in ring three. The set of operations available to ring three code is restricted by hardware-enforced security mechanisms such as segmentation, paging, and I/O privilege restrictions. A few security-critical assembly language instructions are also restricted to ring zero operation. Most software security techniques (PaX on Linux, W^X on OpenBSD, and so on) heavily rely upon protected mode enforced mechanisms. On the contrary, System Management Mode is a 16-bit mode of operation dedicated to system maintenance. Code running in System Management Mode is running with full privileges on the system (free access to physical memory and to peripheral devices). Protected mode security mechanisms (paging, segmentation, rings, ...) are not enforced while in System Management Mode.

How did you have the intuition to take advantage of this feature?

The PhD thesis I started one and a half years ago deals with the security issues related to interactions between hardware components and software. I chose to read x86 processor-related documentation to get a better picture of what x86 processors were capable of. I read about the SMM functionality and I shortly noticed that it could be a threat to the global security policy of a system. I chose to look a little closer on the matter.

Is SMM used to do good things as well?

As a matter of fact, SMM is routinely used. Operating systems run in protected mode. But operating systems are not meant to be able to handle very specific hardware events (real time clock-related issues, thermal sensor signals or other external events, the list is really endless). In case such an event occurs, the chipset of the system generates a physical interrupt on the motherboard called an SMI (System Management Interrupt). Upon reception of the SMI, the processor will store its entire context and switch to SMM to run the code - which I'll call the SMI handler from now on.

By context, I mean most processor registers including control registers, task registers, instruction and stack pointers. It runs the code that has been written by the BIOS or motherboard manufacturer to handle the SMI, that is to handle the hardware-specific event that caused the SMI to be generated in the first place. When the handler runs the assembly language instruction "RSM", the processor will restore its entire context and switch back to protected mode.

So, as far as the operating system is concerned, nothing happened. The operating system did not notice the CPU switching to SMM and back to protected mode. Code execution in SMM is transparent from the operating system point of view.

During normal operation of a PC, SMIs are routinely generated, but neither the operating system nor the end user are aware they exist and that the CPU is handling them. I think it is pretty obvious that if such a mode can be misused, consequences on system security can be disastrous. As a matter of fact, the security of SMM comes from the fact that the SMI handler is loaded in memory at boot time by the POST sequence of the BIOS in a memory block called SMRAM located in main system memory.

On systems that are not equipped with a chipset that provides an 8-bit configuration register called the "SMRAM control register" (accessible via PIO accesses), protection of the SMRAM in protected-mode is only enforced by segmentation and paging.

On systems equipped with such a chipset however, the security model is essentially that only code running in SMM should be able to modify the content of the SMRAM. In other words, only the SMI handler should be able to modify itself.

What is the link between SMM and SMRAM control registers?

I said the security model was that only the SMI handler was able to modify itself. That is only a simplified picture. What the "SMRAM control register" does is first it enables the relocation of the SMRAM base address at physical address 0xA0000. This way, the SMRAM address range is in conflict with the legacy video RAM range. So what happens is that if the CPU is running in protected mode, all accesses to the SMRAM range are forwarded by the chipset to the display adapter. And if the CPU is running in SMM, the accesses are redirected by the chipset to the SMRAM in main system memory.

So far, the model seems consistent. The trouble is that there also is a bit called D_OPEN in the chipset. If this bit is set, the chipset forwards all accesses to the SMRAM range to the actual SMRAM. If this bit is set, SMRAM can be accessed whichever the mode of operation of the processor is. It should also be noted that there is in the SMRAM control register a bit called D_LCK. If this bit is set, the SMRAM control becomes read only, and only a hard reset can clear the D_LCK bit. If this bit was set after the D_OPEN bit has been cleared, then it would be impossible to modify the default trusted SMI handler while in protected mode. The trouble is that on all the desktops I tested the D_LCK bit was cleared.