ARM Exception Levels

 ARM Exception Levels: A Layered Approach to Events

ARM processors employ a multi-layered exception handling mechanism to manage various events that disrupt normal program execution. These levels prioritize critical events and ensure smooth system operation. Here's a concise summary:







Exception Levels:

Imagine a hierarchy with increasing privilege as you move up:

  • EL0 (Exception Level 0): The lowest privilege level. It's the playground for unprivileged user-space applications – think of them as guests in a house.
  • EL1 (Exception Level 1): The primary level for running the operating system kernel and most user applications. It acts as the host, managing resources for applications in EL0.
  • EL2 (Exception Level 2): An optional level used for specific purposes like secure co-processor functions or virtualization. Think of it as a special room in the house with restricted access.
  • EL3 (Exception Level 3): The highest privilege level. It's the most secure zone, typically used for secure boot, memory management, and virtual memory management by the operating system or hypervisor. Imagine it as the control center of the house, overseeing everything.

Key Points to Remember:

  • Prioritization: Critical events like interrupts or system calls are handled at higher privilege levels (EL1, EL2, or EL3) for a faster response.
  • Security: Higher privilege levels isolate user applications (EL0) from accessing sensitive system resources, enhancing security.
  • Modular Design: Exception handlers for different events can be written independently, promoting code organization and easier maintenance.

Analogy: Restaurant Reservations

Imagine a restaurant with different seating sections:

  • EL0: The general seating area for walk-in customers (unprivileged applications).
  • EL1: The reservation section for regular customers (operating system kernel and user applications).
  • EL2 (Optional): A private dining room for VIPs (specific secure functions).
  • EL3: The manager's office, overseeing everything (secure boot, memory management).

Events like a fire alarm (interrupt) would require immediate evacuation (handled at a higher level), while placing an order (system call) would be handled by the waiter (operating system at EL1).

Understanding these exception levels is fundamental for ARM system software development. It ensures proper handling of various events, maintaining system stability, security, and efficient resource management.


Switching Between ARM Exception Levels: A Behind-the-Scenes Look

ARM processors implement a multi-level exception handling mechanism, and switching between these levels is crucial for managing various events during program execution. Here's a breakdown of the switching process with examples:

The Switching Sequence:

  1. Exception Trigger: An event like an interrupt, system call, or error condition triggers an exception.
  2. Exception Entry: The processor saves the current state of the executing program, including the program counter (PC) and registers. This ensures the program can resume from where it left off after handling the exception.
  3. Exception Vector Table Lookup: Based on the exception type, the processor consults the Exception Vector Table (EVT). This table acts like a directory, containing addresses of specific exception handler code for each exception type.
  4. Exception Handler Execution: The processor switches to the saved Exception Level (usually EL1 for most exceptions) and jumps to the address retrieved from the EVT. This initiates the execution of the appropriate exception handler code.
  5. Exception Return: Once the exception handler finishes its task (e.g., servicing an interrupt or handling a system call), it restores the saved processor state and resumes execution from where it was interrupted.

Example 1: System Call (EL0 to EL1):

Imagine a user application (running at EL0) needs to access a file on the disk. This requires a system call, which is a controlled way for applications to request services from the operating system kernel. Here's the switch:

  1. The application triggers a system call instruction.
  2. The processor saves the application's state (registers, PC).
  3. The EVT points to the system call handler in the operating system kernel (running at EL1).
  4. The processor switches to EL1 and starts executing the system call handler, which opens the file for the application.
  5. Once the file is opened, the handler restores the application's state and resumes execution at the point of the system call, allowing the application to continue using the opened file.

Example 2: Interrupt (External Event to EL1):

Imagine an external device like a keyboard generates an interrupt signal. This needs immediate attention:

  1. The interrupt signal triggers an exception.
  2. The processor saves the state of the currently running program (either user application or kernel code, depending on who was running at EL1).
  3. The EVT points to the interrupt handler for that specific device.
  4. The processor switches to EL1 (assuming the interrupt handler is part of the kernel) and executes the interrupt handler, which reads the key press and updates the system accordingly.
  5. After handling the interrupt, the handler restores the saved state and resumes execution from where it was interrupted.

Switching Mechanisms:

  • Mode Switching: Switching between user mode (EL0) and privileged modes (EL1, EL2, EL3) involves saving and restoring additional context, like processor flags and control registers.
  • Stack Switching: Each exception level typically has its own dedicated stack for storing saved registers and other state information during exception handling.
  • Saved Program Status Register (SPSR): This register stores the saved processor flags and other information needed to resume execution after handling an exception.

By understanding how switching between exception levels works, you gain insight into how ARM processors efficiently manage various events, ensuring smooth system operation and a responsive user experience.


Switching Between Higher Exception Levels (EL1, EL2, EL3) in ARM Processors

While most exceptions occur and are handled at EL1, ARM processors also utilize EL2 and EL3 for specific scenarios. Here's a breakdown of switching between these higher exception levels with examples:

General Switching Process:

The core switching mechanism remains similar to EL0 and EL1 transitions, involving:

  1. Exception Trigger: An event like a secure world request or a system call to a hypervisor triggers an exception.
  2. Exception Entry: The processor saves the current state, including registers and PC.
  3. Exception Vector Table Lookup: The EVT points to the appropriate handler code based on the exception type.
  4. Exception Handler Execution: The processor switches to the target Exception Level (EL2 or EL3) and executes the retrieved handler code.
  5. Exception Return: After handling the exception, the processor restores the saved state and resumes execution at the original level.

Key Differences in Switching:

  • Mode Switching: Switching between EL1 and EL2 or EL3 involves entering a different privileged mode, requiring additional context saving and restoring.
  • Security Considerations: Transitions to higher privilege levels (EL2 or EL3) often involve security checks to ensure authorized access.

Example 1: Secure World Entry (EL1 to EL2):

Imagine a user application (running at EL1) needs to access a secure enclave, a protected environment within the processor for secure tasks like cryptography. This requires entering the Secure World (often implemented at EL2):

  1. The application triggers a secure world entry instruction.
  2. The processor verifies the access rights of the application.
  3. If authorized, the processor saves the application's state (registers, PC) at EL1.
  4. The EVT points to the secure world entry handler in the secure monitor (running at EL2).
  5. The processor switches to EL2 and executes the secure world entry handler, which sets up the secure world environment.
  6. The secure world code can then access secure resources and perform secure operations.
  7. Upon exiting the secure world, the handler restores the application's state and resumes execution at EL1.

Example 2: Hypervisor Call (EL1 to EL3):

Consider a system running a hypervisor, a software layer that allows multiple operating systems (guests) to share the hardware resources of a processor. If a guest OS (running at EL1) needs to invoke a hypervisor service (e.g., memory management), it triggers a hypervisor call:

  1. The guest OS executes a hypervisor call instruction.
  2. The processor saves the guest OS state (registers, PC) at EL1.
  3. The EVT points to the hypervisor call handler code within the hypervisor (running at EL3).
  4. The processor switches to EL3 and executes the hypervisor call handler, which performs the requested service for the guest OS.
  5. After completing the service, the handler restores the guest OS state and resumes execution at EL1.

In conclusion, switching between EL1, EL2, and EL3 allows for secure and efficient management of privileged tasks like secure world access and hypervisor interactions in ARM systems.

USECASES -

Exception Level Switching During a WhatsApp Call on a Smartphone (ARM Processor)

Imagine you're having a WhatsApp call on your smartphone. Several exception levels and switching mechanisms come into play to ensure a smooth call experience. Here's a breakdown:

Scenario: You initiate a WhatsApp video call.

Initial State:

  • The user interface (UI) for the WhatsApp call application is running at EL0 (Exception Level 0), the unprivileged user-space level.

Steps Involved:

  1. Initiating the Call (EL0 to EL1):

    • You tap the video call button in the WhatsApp app.
    • This action triggers a system call instruction within the WhatsApp application code (running at EL0).
    • The processor saves the application's state (registers, PC).
    • The Exception Vector Table (EVT) points to the system call handler in the operating system kernel (running at EL1).
    • The processor switches to EL1 and executes the system call handler, which initiates the call process.

  2. Accessing Hardware (EL1 to Device Drivers):

    • The kernel code (EL1) needs to access various hardware components like the camera, microphone, and network for the call functionality.
    • Device drivers, which are specialized software modules for interacting with hardware, handle these interactions.
    • The kernel may trigger exceptions (like device interrupts) to notify the driver about events (e.g., new camera frame captured).
    • The processor might switch to a temporary exception level to execute the device driver code, depending on the driver implementation.
    • The driver code interacts with the hardware and provides data back to the kernel.

  3. Audio and Video Processing (Potential Switch to DSP):

    • The captured audio and video data from the camera and microphone require processing.
    • Some systems might utilize a dedicated Digital Signal Processor (DSP) co-processor for efficient audio and video processing.
    • If a DSP is involved, the processor might switch to a specific exception level for the DSP to handle the processing tasks.
    • After processing, the data is sent back to the main processor for further handling.

  4. Displaying the Video and Playing Audio (EL1):

    • The processed video frames and audio data are sent back to the kernel at EL1.
    • The kernel interacts with the graphics driver and audio driver to display the video on the screen and play the audio through the speakers/earpiece.
    • Similar to hardware access, these interactions might involve temporary exception level switches for driver execution.

  5. Handling Incoming Network Data (EL1):

    • During the call, data packets containing video and audio information from the other party are received over the network.
    • Network interrupts might trigger a switch to a temporary exception level to execute the network driver code.
    • The driver processes the received data and passes it to the kernel for further handling.

  6. Potential Security Checks (EL2 or EL3):

    • Depending on the system implementation, some security checks might be performed during the call process.
    • These checks might involve switching to a higher exception level (EL2 or EL3) for secure world components or the hypervisor to handle security-critical tasks.

  7. User Interaction (EL0):

    • Throughout the call, you might interact with the call controls on the user interface.
    • These user interactions are handled by the WhatsApp application code running at EL0.

Exception Level Summary:

  • EL0: User application (WhatsApp UI) and user interactions.
  • EL1: Operating system kernel, device driver interactions (temporary switches for specific drivers), and overall call management.
  • Potential Temporary Switches: Device drivers or a DSP co-processor might utilize specific exception levels for handling hardware interactions and processing tasks.
  • Potential Switches (EL2/EL3): Depending on the system, security checks might involve a switch to higher exception levels for secure world components or the hypervisor.

Important Note: The specific exception levels used for device drivers and security checks might vary depending on the smartphone architecture and operating system implementation. This provides a general overview of the potential switching mechanisms involved during a WhatsApp call.


Exception Level Switching During a Google Pay Transaction on a Smartphone (ARM Processor)

Using Google Pay for a contactless payment involves various software components working together. Let's explore the potential exception level switches during this process:

Scenario: You're making a payment at a store using Google Pay on your smartphone.

Initial State:

  • The Google Pay app displaying the payment confirmation screen is running at EL0 (Exception Level 0), the unprivileged user-space level.

Steps Involved:

  1. Confirming Payment (EL0 to EL1):

    • You tap the "Pay" button in the Google Pay app.
    • This action triggers a system call instruction within the Google Pay application code (running at EL0).
    • The processor saves the application's state (registers, PC).
    • The Exception Vector Table (EVT) points to the system call handler in the operating system kernel (running at EL1).
    • The processor switches to EL1 and executes the system call handler, which initiates the secure payment process.

  2. NFC Communication (EL1 to Secure Element):

    • To communicate with the contactless payment terminal, the kernel needs to activate the Near Field Communication (NFC) module.
    • However, secure elements (SE) are often used to store payment credentials and perform cryptographic operations for secure transactions.
    • The communication with the SE might involve a switch to a specific exception level designated for the SE driver or a trusted execution environment (TEE) for security reasons.
    • The secure element or TEE handles the secure communication with the payment terminal.

  3. Authorization and Processing (EL1):

    • The kernel interacts with Google Pay servers for authorization and transaction processing.
    • This might involve network calls and interactions with other system services, potentially triggering temporary exception level switches for network drivers or service handlers.

  4. User Interface Updates (EL1):

    • The kernel communicates with the Google Pay app to update the user interface with the transaction status.
    • This might involve interactions with the graphics driver, potentially causing a temporary switch for driver execution.

  5. Security Checks (Potential Switch to EL2/EL3):

    • Depending on the system implementation, additional security checks might be performed during the transaction.
    • These checks might involve switching to a higher exception level (EL2 or EL3) for secure world components or the hypervisor to ensure secure handling of payment credentials.

Exception Level Summary:

  • EL0: User application (Google Pay UI) and user interactions.
  • EL1: Operating system kernel, communication with Google Pay servers, and overall transaction management.
  • Potential Temporary Switches: Secure element driver, network drivers, and graphics driver might utilize specific exception levels for handling communication and display updates.
  • Potential Switches (EL2/EL3): Depending on the system, security checks might involve a switch to higher exception levels for secure world components or the hypervisor.

Important Note: The specific details of exception level usage can vary depending on the smartphone's architecture, security implementation, and the way Google Pay interacts with the secure element. This provides a general understanding of the potential switching mechanisms involved during a Google Pay transaction.



No comments:

Post a Comment

Subscribe to: Posts (Atom)