Venturing into the x86

1
Venturing into the x86s System Management Mode

• An introduction to concepts needed for writing
  and testing an interrupt-handler for SMIs

2
The x86 operating modes
Virtual 8086 mode
IA-32e mode
64-bit mode
Real mode
Power on
Protected mode
Compatibility mode
System Management mode
3
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)

4
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
SMI
INTR
INIT
5
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

ICR (upper 32-bits)
ICR (lower 32-bits)
vector
01000
short hand
destination
010
0xFEEE0310
0xFEEE0300
Delivery Mode SMI
6
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)

7
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 0x00008000
• Initially, after a system-reset, the value of the
  SMBASE will be 0x00030000, but the SMI
  interrupt-handler can setup another value for any
  subsequent SMM entries an essential step in
  multiple-CPU systems

8
Initialization
EBDA
This arena must be relocated to private
memory-space that doesnt overlap any other
processors SMM memory area
Initial SMM segment
0x30000
BOOT_LOCN
0x07C00
RBDA
0x00400
IVT
0x00000
9
Classrooms machines
4 GB physical memory
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
\ System Management memory
CPU 0
0xDFFF0000
CPU 1
0xDFFE0000
CPU 2
0xDFFD0000
CPU 3
0xDFFC0000
0xDFF00000
We wrote our own smlayout.cpp
application to learn where the BIOS has
placed these arenas in classrooms machines
The ROM-BIOS decides where to relocate each
processors SMRAM on a particular
platform (not a standard, and not generally
documented)
10
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
  Intels MCH Data Sheet)
• Some machines use a BIOS that locks access to
  System Management Memory (such as the DELL
  machines in CS Labs)

11
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 controllers frame-buffer memory once
  you have compiled and installed our vram.c
  device-driver

12
System overview
user space kernel
space
Linux operating system kernel
standard runtime libraries
file subsystem
device driver module
application program
physical memory
13
The code-structure for smram.c
smram.c
include ltlinux/module.hgt include
ltlinux/highmem.hgt char modname
smram int my_major 87 MO
DULE_LICENSE(GPL)
some header-files
some global data
this modules payload (its method
functions and its file_operations
structure)
my_read()
my_write()
my_llseek()

my_fops
module_init()
required module administration
functions
module_exit()
14
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 x86s SMM

15
Text-mode console

• We normally use Linuxs graphical desktop
  environment but a drawing message for the
  graphics display is quite complicated
• So we can use Linuxs 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

16
The ATI frame-buffer
The manufacturers 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
ASCII code
color attribute byte
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
These are the two bytes we normally see in
the legacy VRAM space
17
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)
18
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

0 8
16 24
32
H
E
L
L
O
19
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

20
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 cant 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 cant be recovered using real-mode style
  segment-register loads (20-bit addresses)

21
Nevertheless

• Weve 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

22
In-class exercise

• The Intel SM Save State data-structure is
  described in Intels 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?

23
Important!
DONT FORGET TO DO A COLD RESTART BEFORE YOU
GO HOME TONIGHT