Venturing into the x86’s System Management Mode An introduction to concepts needed for writing and testing an interrupt-handler for SMIs

The x86 operating ‘modes’ Real mode Protected mode IA-32e mode Virtual 8086 mode System Management mode 64-bit mode Compatibility mode Power on

Some purposes of SMM Provide a ‘transparent’ mechanism for the hardware to perform various maintenance functions related to conservation of power or regulation of component temperatures Allow ‘emulation’ of hardware behaviors when actual hardware is not installed or not functioning (e.g., keyboard-input via the network if a real keyboard is absent)

SMM ‘transparency’ To function without any operating system software being aware, the x86 processor enters System Management Mode when an external signal is delivered: x86 processor NMI INTR INIT SMI

Using IPI messages It is also possible to trigger an SMI using an Inter-Processor Interrupt (IPI) sent by one of the Local-APICs, by writing to its Interrupt Command Register vector01000 short hand destination 010 Delivery Mode = SMI 0xFEEE0310 0xFEEE0300 ICR (upper 32-bits)ICR (lower 32-bits)

A ‘private’ address-space In response to an SMI signal, the CPU will switch to a otherwise inaccessible memory address-space, where it saves its current register-values and from which it fetches its subsequent machine-instructions The usual protection-mechanisms, such as privilege-restrictions and limit-checks, are disabled (operates as in ‘real mode’)

The CS and IP registers Upon entry to SMM, the CS register gets modified (both its visible and hidden parts) and the IP register gets set to 0x Initially, after a system-reset, the value of the SMBASE will be 0x , but the SMI interrupt-handler can setup another value for any subsequent SMM entries – an essential step in multiple-CPU systems

Initialization IVT RBDA BOOT_LOCN Initial SMM segment 0x x x x07C00 EBDA This arena must be relocated to private memory-space that doesn’t overlap any other processor’s SMM memory area

4 GB physical memory Classroom’s machines \ System Management memory CPU 0 CPU 1 CPU 2 CPU 3 0xDFFF0000 0xDFFE0000 0xDFFD0000 0xDFFC0000 0xDFF00000 one megabyte of the 4G physical memory is carved out for use only while a CPU is executing in System Management Mode and is not accessible during normal use The ROM-BIOS decides where to ‘relocate’ each processor’s SMRAM on a particular platform (not a ‘standard’, and not generally ‘documented’) We wrote our own ‘smlayout.cpp’ application to learn where the BIOS has placed these arenas in classroom’s machines

‘smram.c’ We wrote this Linux device-driver module to provide our application-programs with a way to access the normally ‘inaccessible’ System Management Memory (details on this are from Intel’s MCH Data Sheet) Some machines use a BIOS that ‘locks’ access to System Management Memory (such as the DELL machines in CS Labs)

Using ‘fileview’ Once you have compiled and installed our ‘smram.c’ device-driver, you can use the familiar ‘fileview’ utility to view the current contents of System Management Memory You can also use ‘fileview’ to look at the graphics controller’s frame-buffer memory once you have compiled and installed our ‘vram.c’ device-driver

System overview physical memory device driver module Linux operating system kernel file subsystem application program standard runtime libraries user space kernel space

The code-structure for ‘smram.c’ #include … char modname[ ] = “smram”; int my_major = 87; … MODULE_LICENSE(“GPL”); smram.c module_init() module_exit() my_write() some header-files some global data this module’s ‘payload’ (its ‘method’ functions and its ‘file_operations’ structure) required module administration functions my_llseek() my_fops my_read() …

‘smidemo.s’ We wrote our own ‘interrupt-handler’ code for any System Management Interrupts We wanted it to do something simple that we would be able to perceive -- such as displaying a message on the screen We encountered a number of obstacles, requiring an understanding of the MCH, the CRTC, the VRAM, and x86’s SMM

Text-mode console We normally use Linux’s graphical desktop environment – but a drawing message for the graphics display is quite complicated So we can use Linux’s text-mode console But Linux uses ‘hardware scrolling’ and the MCH blocks accesses to the usual VRAM in System Management Mode So we had to overcome these obstacles

The ATI frame-buffer ASCII code color attribute byte The manufacturer’s of video display controllers do not always follow the same design-scheme for the arrangement of character-cells in text mode Our classroom machines have ATI (Advanced Technology, Incorporated) graphics hardware, where each character-cell is specified by a quadword (i.e., 8 bytes) from the frame-buffer memory. Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 These are the two bytes we normally see in the legacy VRAM space These bytes are not normally ‘mapped’ to the legacy memory-addresses 0xB8000-0xBFFFF but are used for storing the text-font bitmaps which the ASCII-codes reference in text-mode

‘hardware scrolling’ Linux normally disregards the ROM-BIOS way of dividing text-mode display-memory into ‘pages’ which each correspond to one full text-mode screen-image – instead the Linux scheme moves a ‘window’ over the continuous segment of video memory 32-killobytes of text-mode video memory currently ‘visible’ screen current CRTC Start-Address (varies)

Where to draw? If we want to draw a message that will be visible on the current text-mode console, we need to use the current CRTC window and we need to draw each character (and color-attribute byte) to the first 2-bytes of quadword-sized frame-buffer locations HELLO

Source-code ‘labels’ Another obstacle we face is that assembly language labels are assigned their values based on the assumption that our code is residing at offset zero in the CS-segment, but in fact our SMI code will reside at the offset 0x8000 from the CS segment-base So we either have to write a new ‘linker- script’ or else adjust all offsets at runtime

Avoid long jumps/calls/interrupts If the BIOS has relocated the memory for System Management Mode to an address above the 1MB boundary, then we can’t freely allow instructions that modify the CS segment-register, since that will alter the ‘base-address’ field within the hidden part of the CS segment-register in a way that can’t be recovered using ‘real-mode’ style segment-register loads (20-bit addresses)

Nevertheless… We’ve overcome the numerous obstacles to a classroom demonstration of System Management Mode from within Linux: –Switch to a text console (CTRL-ALT-Fn) –Execute the Linux ‘setfont’ command –Install our ‘smram.ko’ kernel-module –Load our ‘smidemo.b’ (using ‘smiload’) –Execute our ‘issuesmi’ application

In-class exercise The Intel ‘SM Save State’ data-structure is described in Intel’s programmer manuals Among the register-values automatically saved on entering System Management Mode is Control Register CR3 (used by the CPU to find the Level4 Page-Table) It is saved at offset 0xfff0 from SMBASE Can you display its (64-bit) value?

Important! DON’T FORGET TO DO A ‘COLD RESTART’ BEFORE YOU GO HOME TONIGHT