Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ODP Security Architecture

Whether in the Patina or Embedded Controller domain, ODP's security architecture is designed to ensure the integrity and trustworthiness of firmware components. This architecture is built upon several key principles:

  • Least Privilege: Components operate with the minimum privileges necessary to perform their functions, reducing the risk of unauthorized access or damage.
  • Isolation: Components are isolated from one another to prevent unintended interactions and to contain potential security breaches.
  • Verification: Components are verified at boot time to ensure they have not been tampered with and that they meet the expected security standards.
  • Layered Defense: Security concerns are enforced at multiple levels — bootloader, firmware, EC messaging, and runtime service dispatch.
flowchart TD
    A[Reset Vector / ROM]
    B[Bootloader / Core Root of Trust]
    C[Patina DXE Core]
    D[OS Boot]
    E[EC Runtime]
    F[EC Services]

    A --> B
    B --> C
    C --> D

    B -->|Key Exchange, FFA| E
    E --> F

    subgraph Secure World
        B
        E
    end

    subgraph Non-Secure World
        C
        D
        F
    end

Figure: System Trust Boundaries

The ODP system defines strong isolation between secure and non-secure execution. Firmware integrity is established early and extended to runtime services. EC services may operate in either domain, depending on platform architecture.

AreaConcernsEnforced By
Secure BootRoot trust, signed firmware, measurementBootloader / Patina
Firmware UpdateVerification, rollback protectionUpdate agent, signing keys
EC ServicesIsolation, message auth, FF-A routingHafnium, UUID filtering, runtime logic