Using ‘Virtual-8086’ mode to execute real-mode procedures in a protected-mode environment

• At power-up the Pentium begins executing in real-address mode (memory addressing does not require use of descriptor tables)
• CPU privilege-restrictions are not imposed
• Memory addresses are limited to 20-bits
• Interrupt-routing is handled using the IVT
• Multitasking and paging are unsupported
• Lots of ‘legacy’ software written for 8086

• It is desirable to run multiple 8086 tasks in an environment that ‘protects’ each task from interference by other tasks, yet offers each task the illusion of being in control of the system (as in ‘real-mode’ environment)
• Duplicate the environment of an 8086 cpu
• Synchronize access to shared resources,
(such as files and peripheral i/o devices)

• 1981: IBM-PC (to compete with CP/M)
• 1984: Macintosh (introduces graphics)
• 1985: Windows 1.0 (to rival Macintosh)
• 1986: Windows 2.0 (80286 multitasking)
• Macintosh had 32-bit processor (M68000), but Windows 2.0 had 16-bit processor and was handicapped by slow mode-switching needed to execute its firmware routines

• Windows 3.0 ran on new 32-bit processor:
– Faster mode-switching (whenever needed)
– Virtual memory support (for task isolation)
– Hardware ‘breakpoint’ debugging support
– Virtual-8086 (for firmware and legacy code)

• The CPU executes in ‘Virtual-8086’ mode when the VM-bit (bit #17) in EFLAGS is 1
• POPFL instruction cannot modify VM-bit
• Two methods for entering VM86-mode:
1) use the IRET instruction (.code32)
2) use a task-switch to a new 386 TSS
• The only way to leave VM86-mode is with an interrupt (either hardware or software) or by resetting the processor (i.e., reboot)

Execute IRET instruction from 32-bit code-segment while in protected-mode at privilege-level 0
SS:ESP
Ring-0 Stack-Frame
GS-image
FS-image
DS-image
ES-image
SS-image
SP-image
EFLAGS ( VM=1, NT=0 )
CS-image
IP-image

• While in VM86-mode, certain instructions are
‘sensitive’ to the current value of the IOPL-field in EFLAGS:
– The CLI and STI instructions
– The PUSHF and POPF instructions
– The PUSHFL and POPFL instructions
– The IRET and IRETL instructions
– The INT-nn instruction
• The above instructions will generate a General
Protection Exception (INT-13) unless IOPL==3

31 17 13 12 0
0 0 0 0 0 0 0 0 0 0
I
D
V
I
P
V
I
F
A V
C M
R
F
0
N
T
I
O
P
L
O
F
D
F
I
F
T
F
S
F
Z
F
0
A
F
0
P
F
1
C
F
Legend: VM = Virtual-8086 Mode (1=yes, 0=no)
IOPL = I/O Privilege-Level (0,1,2,3)
VIF = Virtual Interrupt-Flag (if CR4.0 = 1)
VIP = Virtual Interrupt Pending (if CR4.0 = 1)
ID = CPUID-supported (1=yes, 0=no)
CF = Carry-Flag
PF = Parity-Flag
AF = Auxilliary-Flag
ZF = Zero-Flag
SF = Sign-Flag
OF = Overflow-Flag
TF = Trap-Flag
IF = Interrupt-Flag
DF = Direction-Flag
RF = Resume-Flag
NT = Nested Task
AC = Alignment Check

• Suppose a task executing in VM86-mode tries to disable deviceinterrupts, using a ‘cli’ instruction
• If IOPL ≠ 3, this instruction will cause a GP-fault
(exception 0x0D) with an error-code equal to 0
• An exception-handler can examine the opcode
(by using the saved CS:IP address on its stack)
• If that opcode equals 0xFA (i.e., ‘cli’), then the handler can clear bit #9 in the saved EFLAGS image (i.e., the IF-bit), increment the saved IP, then execute IRET to resume the VM86 task

• A VM86-task executes at privilege-level 3
• If IOPL==3, then the VM86 task is allowed to execute all the IO-sensitive instructions
( except INT-nn ) without generating a fault

• In VM86-mode, certain instructions trigger a General Protection Fault regardless of the current value in EFLAGS’ IOPL-field
• One of these is the halt-instruction (‘hlt’)
• The GP fault-handler can examine the opcode that triggered the fault (using the saved CS:IP address on its ring0 stack) and, if it is 0xF4 (i.e., ‘hlt’), can terminate the VM86 task, if that is what is desired

• This demo illustrates entering and leaving a Virtual-8086 procedure within a 386 task that is executing in protected-mode
• The procedure draws directly to video ram, changing all the characters’ attribute-bytes to white on a blue-colored background
• It executes with device-interrupts disabled
• It includes no ‘io-sensitive’ instructions
• It uses ‘hlt’ to exit from Virtual-8086 mode

• We want to modify ‘ vm86demo.s
’ -- to do something that’s much more interesting!
• Let’s add a ‘software interrupt’ instruction, to try executing some ROM-BIOS code
• Easiest to try is ‘int $0x1C’ -- because it normally does nothing but return (‘iret’)
• We will need to add code to our GP-fault handler that ‘emulates’ an ‘int-nn’ opcode

• Increment the saved IP-image by 2 bytes
(to simulate fetching the instruction)
• Simulate the ‘push’ of FLAGS, CS, and IP onto the VM86 task’s ring3 stack
• Identify the interrupt’s ID-number, and copy its vector from IVT onto ring0 stack
• Clear IF and TF bits in the saved EFLAGS
• Use ‘iret’ to resume ‘virtual-8086’ mode

Ring-3
Stack
FLAGS
CS
IP int nn
Ring-3 code-segment
Ring-0 Stack
GS
FS
DS
ES
SS
SP
EFLAGS
CS
IP
Real-Mode IVT
CS
IP
SS:ESP

Ring-3
Stack
FLAGS
CS
IP
Ring-0 Stack
GS
FS
DS
ES
SS
SP
EFLAGS
CS
IP
SS:ESP

• If you try executing code in Virtual-8086 mode without IOPL==3, then you’re likely to need to emulate the other io-sensitive instructions (iret, cli, sti, pushf, popf)
• The CLI and STI instructions are easy
• The PUSHF/POPF are a little harder
• The IRET is the most complex of these

SS:ESP
Ring-0 Stack
GS
FS
DS
ES
SS
SP
EFLAGS
CS
IP
Simply adjust bit number 9 in the saved image of the EFLAGS register on the ring0 stack

SS:ESP
Ring-3
Stack
Ring-0 Stack
GS
FS
DS
ES
SS
SP
EFLAGS
CS
IP
FLAGS
Copy the topmost word from the ring3 stack to the low-half of the saved EFLAGS-image on the ring0 stack;
Add 2 to the saved SP-value;
Add 1 to the saved IP-value; then execute IRET to resume

SS:ESP
Ring-3
Stack
Ring-0 Stack
GS
FS
DS
ES
SS
SP
EFLAGS
CS
IP
FLAGS
Subtract 2 from the saved SP-image;
Copy low-half of the saved EFLAGS-image from ring0 stack to top word of ring3 stack;
Add 1 to the saved IP-value; then execute IRET to resume

• For tasks that execute in VM86-mode, the ability to execute IN/OUT instructions can be controlled on a port-by-port basis, using a bitmap data-structure within the TSS
• The bitmap can be up to 8192 bytes long
(one bit for each of the 65536 i/o ports)
• The CPU finds this bitmap by using the value at offset 0x66 within the TSS, which holds the bitmap’s starting TSS offset

I/O Permission
Bitmap
IOMAP
0x66
TSS Base-Address

• If you do not want a VM86 task to directly perform I/O operations on a specific port, you can set that port’s bit within the bitmap
• For example, to prevent a VM86 task from reading mouse-data (io-port 0x60), just set bit $0x60 within that task’s io-permission bitmap: this will causes a GP-fault if the instruction ‘in $0x60, %al’ is encountered

• The Pentium processor introduced some speed-improvements to Virtual-8086 mode
(largely for the benefit of Windows 3.0)
• So-called ‘Virtual Mode Extensions’ (VME) can be enabled (by setting bit #0 in a new
Control Register named CR4)
• Then even software-interrupt instructions don’t require use of ‘emulation’ code