The Foundation - Normal World Virtualization and EL2

Modern ARM systems aren't just about running code-they're about who controls what, and when. That's where Exception Levels come in.

For firmware engineers, understanding EL2 (Hypervisor) and EL3 (Secure Monitor) isn't optional anymore. These levels define the boundaries between:

• the normal world and secure world
• the host (hypervisor) and guest operating systems
• trusted firmware and everything else

EL3 sits at the top of the trust hierarchy, handling secure world transitions and enforcing system-wide security policies. EL2, on the other hand, enables virtualization-allowing multiple guest OSes to run safely on the same hardware while remaining isolated.

Why does this matter in practice?

Because firmware is responsible for:

• setting up the execution environment before any OS boots
• setting up Stage-2 translation tables (IPA to PA mapping)
• ensuring isolation guarantees that hypervisors depend on
• mapping trap routing and SMC (Secure Monitor Call) handlers

If EL2 and EL3 are not right, you don't just get bugs-you risk:

• broken isolation between VMs
• security vulnerabilities across worlds
• unpredictable system behavior under load

In short, EL2 and EL3 are where architecture meets control-and firmware is the layer that makes that control real.

The diagram below illustrates how these layers interact to maintain isolation while allowing for the complex communication required in mordern firmware.

Normal World Virtualization: Stage-2 Translation & Guest Isolation

At the heart of ARM virtualization is a deceptively simple idea: every memory access from a Guest OS is translated twice-once by the guest, and once by the hypervisor.

This two-stage translation is what makes strong isolation possible.

Step 1: Stage-1 (Guest-controlled view)

Each Guest OS believes it owns the machine.

It translates:

• Virtual Address (VA) → Internediate Physical Address (IPA).

This is entirely under the Guest OS’s control using its own page tables.

Step 2: Stage-2 (Hypervisor-controlled reality)

The hypervisor (EL2) takes over next. It translates:

• IPA → Physical Address (PA)

This mapping is defined by Stage-2 page tables, which are fully controlled by the hypervisor.

Why this matters

This indirection is the key:

👉 A Guest never directly controls real physical memory.

👉 It only operates within a sandboxed IPA space.

The hypervisor decides:

• Which IPA ranges are valid
• Which physical memory they map to
• What permissions apply (R/W/X)

How isolation is enforced

• Each VM has its own Stage-1 tables → private virtual view
• The hypervisor owns Stage-2 tables → global control layer
• Memory for one VM is never mapped into another VM’s IPA space
• Any illegal access triggers a Stage-2 fault, handled at EL2-specifically a Data or Instruction Abort at EL2, with the cause captured in the ESR_EL2 (Exception Syndrome Register).

The key insight

Stage-2 translation turns the hypervisor into a memory gatekeeper.

Even if:

• a guest OS is compromised
• or its page tables are malicious

…it still cannot escape its assigned memory, because the final translation is enforced by EL2.

The diagram below illustrates this two-stage flow. Each Guest OS operates in its own virtual address space, but all memory accesses ultimately pass through Stage-2 translation—where the hypervisor enforces isolation and access control.

Up Next in the Notebook

Stage-2 translation is powerful, but it's only half the story. What happens when you need to switch between these worlds instantly? In the next edition, we'll look at the Secure Monitor (EL3) and the SPM Dispatcher (SPMD) - the gatekeepers that manage the high-speed traffic between worlds.