Privilege Levels in ARM Architecture

Ever wondered how your phone’s apps can run safely without crashing the entire operating
system, or how sensitive data like fingerprint scans remains isolated from everyday
applications? The answer lies deep within the processor’s architecture, specifically in
something called “privilege levels.”
This blog dives deep into ARM’s privilege model, explaining the different levels, how they
interact, and why they’re essential in secure, multitasking environments.

What are Privilege Levels?

Privilege levels define how much control a program has over system resources like memory,
interrupts, and device registers. Programs running at higher privilege levels can:

• Control hardware directly.
• Access all memory and I/O.
• Manage other programs.

Programs at lower privilege levels have restricted access and rely on higher levels (like the
OS) to mediate interactions.

Why Privilege Levels Matter?

Security

•  Prevents user applications from accessing sensitive system resources.
•  Isolates secure operations (e.g., cryptography, key storage) in higher privilege levels.

Stability

•  Ensures that only trusted code can modify system configurations.
• Reduces the risk of crashes due to rogue or buggy applications.

Performance

•  Enables efficient context switching between user and kernel space.
•  Supports virtualization and secure execution environments.

Privilege Levels in ARM v7

In ARMv7-A, there are two primary privilege levels:
• User Mode (PL0)

• Least privileged. For application code.
• Cannot access hardware directly.
• Restricted from executing privileged instructions.

• Privileged Modes (PL1)
Includes:

•  Supervisor (SVC) – OS kernel mode.
  
• IRQ/FIQ – For interrupt handling.
•  Abort/Undefined/System – For exceptions and advanced debugging.

Privilege Levels or Exception Levels in ARM v8

Starting with ARMv8-A, ARM processors use four Exception Levels (ELs):

Each level has its own set of system registers and operates in either Secure or Non-secure world  (with TrustZone). 

Exception Level	Role	Typical Software
EL3	Secure Monitor	TrustZone Monitor (TF-A)
EL2	Hypervisor	KVM, Xen, VMware
EL1	Operating System Kernel	Linux, RTOS, Windows
EL0	User Applications	Apps, processes

It’s important to note that each Exception Level (EL0, EL1, EL2, EL3) can conceptually exist  in both the Secure and Non-secure worlds, with EL3 acting as the gatekeeper to switch between  these two global states. For instance, an EL1 operating system can run in the Non-Secure  World, while a trusted application’s EL1 component could be running in the Secure World. 

EL0 – User Mode (Least Privileged) 

Purpose:
• Runs user applications.
• Has the least access to hardware.
• Can’t access memory directly or use privileged instructions.
Restrictions:
• Cannot configure memory or peripherals.
• Needs to use system calls to request services from the OS.

Example Applications
• Running apps like:

• Instagram
• WhatsApp
• A game on your phone

• A user-space program on Linux like nano, ls, or your C/C++ application.

EL1 – Kernel Mode (Privileged Mode)

Purpose:
• Runs the Operating System kernel.
• Manages:

• Memory
• Interrupts
• Drivers
• System calls

Capabilities:
• Can access hardware registers.
• Can manage virtual memory and page tables.
• Can handle interrupts and exceptions.

Example Applications:
• Linux kernel
• RTOS kernel (like FreeRTOS, Zephyr, or RTX on Cortex-A)
• ThreadX or VxWorks in embedded systems
• On Raspberry Pi running Linux, EL1 handles:

▪ File systems
▪ Process scheduling
▪ Device control

EL2 – Hypervisor Mode (Virtualization Layer)

Purpose:

•  Allows one physical machine to run multiple virtual machines (VMs).
•  Each VM runs its own OS as if it were on its own hardware.

Capabilities:

•  Controls and isolates guest operating systems.
• Can intercept privileged instructions from guest kernels.

Example Applications:

•  KVM (Kernel-based Virtual Machine) on Linux
• Xen Hypervisor on ARM servers
•  Android’s Virtualization Framework for secure containers
•  Samsung Knox, which uses EL2 for secure workspace separation

EL3 – Secure Monitor Mode (TrustZone Controller)

Purpose:

•  Manages TrustZone, separating:

▪ Secure World (for sensitive operations)
▪ Non-Secure World (normal OS/apps)

•  Acts as a gateway between these two worlds.

Capabilities:

•  Can switch between Secure and Non-Secure modes.
•  Can run trusted firmware and secure bootloaders.

Example Applications:

• ARM Trusted Firmware (ATF)
• Secure Boot mechanisms
•  Digital Rights Management (DRM)
•  Mobile Payment Security (e.g., Samsung Pay, Apple Secure Enclave uses a similar
  idea)

ARM TrustZone and Secure World

TrustZone extends the privilege model with secure vs non-secure states. This allows the
processor to operate in:

•  Secure World (for crypto, secure storage, DRM)
• Non-secure World (normal OS and apps)

Combined with ELs, this adds even more security flexibility. For instance, EL3 typically runs  the Secure Monitor, managing context switches between secure and non-secure worlds. 

Let’s take an Android phone as an example: 

Function	Privilege Level
Instagram app	EL0
Android OS (Linux Kernel)	EL1
Virtual Machine for secure apps	EL2
Secure Boot / Fingerprint unlock	EL3

How does the transition happen between different ARM Privilege Levels? 

In ARM architecture (especially ARMv8-A), privilege levels (EL0–EL3) aren’t just static  modes. Code and the system actively switch between them during execution — this is what  enables multitasking, system calls, virtualization, and secure operations. 

Let’s walk through how and why transitions happen, with examples. 

Overview: Who Can Switch Where? 

• Transitions typically happen from a lower level to a higher level (e.g., EL0 → EL1) via  exceptions or traps.
• Returning back (e.g., EL1 → EL0) is done using return-from-exception instructions (ERET).

EL0 → EL1: System Call or Exception 

When it happens:

• A user app (EL0) needs a service from the OS kernel (EL1), like:

▪ Reading a file
▪ Allocating memory
▪ Printing to console

How it happens:

• The app executes a system call instruction:

▪ ARMv8: SVC #imm (Supervisor Call)

• This generates an exception, which causes the CPU to:
  

▪ Save the current state.
▪ Jump to the EL1 exception handler (in the OS kernel). 

Example

This traps into EL1, where the kernel performs the write() system call.

EL1 → EL0: Return to User Space

When it happens: 

• The OS finishes the system call and gives control back to the user app.

How it happens: 

• Kernel executes the ERET instruction (Exception Return)
• CPU: 

▪ Restores saved state of EL0
▪ Switches back to user mode 

Tip:
The OS must validate everything before returning to EL0 to avoid security issues (e.g., buffer  overflows). 

EL1 → EL2: Hypervisor Trap 

When it happens: 

• The OS tries to execute a virtualization-sensitive instruction that’s restricted in  virtualized environments. 
• Or, the hypervisor wants to boot a guest OS. 

How it happens: 

• The instruction causes a trap to EL2. 
• EL2 hypervisor takes over, handles the trap, and may emulate or allow the instruction.

Example: 

• The Linux kernel running as a guest in KVM tries to access a device, → trap to EL2. 

EL2 → EL1: Return to Guest OS 

When it happens: 

• Hypervisor has finished handling a trap or has scheduled a guest OS to run.

How it happens:

•  EL2 restores the guest OS context and executes ERET.

EL1 or EL2 → EL3: Secure Monitor Call (SMC) 

When it happens: 

• A request is made to the Secure World, like: 

▪ Accessing a secure key
▪ Verifying a fingerprint
▪ Handling secure boot

How it happens: 

• Code executes an SMC (Secure Monitor Call) instruction. 
• CPU traps into EL3. 

Example: 

• Android device requesting cryptographic services from TrustZone. 

EL3 → EL1 or EL2: Return from Secure Monitor

When it happens:

•  EL3 has completed the secure operation.

How it happens:

•  EL3 uses ERET to return control back to EL1 or EL2.
• Also restores non-secure world context.

From → To	Trigger	Instruction	Example Scenario
EL0 → EL1	System call or fault	SVC	App asks OS to open a file
EL1 → EL0	Return from system  call	ERET	OS finishes task and returns to app
EL1 → EL2	Trap from guest OS	Auto trap	Virtualized OS accesses restricted  feature
EL2 → EL1	Resume guest OS	ERET	Hypervisor schedules next VM
EL1/2 → EL3	Secure Monitor Call	SMC	Fingerprint scan, secure transaction
EL3 → EL1/2	Return to  normal/non-secure	ERET	TrustZone returns control to  normal world

Key Takeaways 

• ARM uses ELs for security and stability 
• EL0 is for running user apps 
• EL1 is where the OS runs 
• EL2 is for hypervisors, & EL3 is for secure monitor 
• Transitions between lower EL to higher EL happen via exceptions like SVC or SMC  and return to lower EL with ERET command 

Understanding privilege levels in ARM is crucial for developers working on secure and  efficient systems. Whether you’re building an operating system, a secure IoT device, or a  virtualized environment, leveraging ARM’s privilege model helps you design with security and  reliability in mind.