EDK2_00_02 - StandaloneMmPkg (PoC)

Owned by Andrei Warkentin
Last updated: Jul 11, 2024 by Yong Li (Deactivated)
4 min read

About

This Standalone MM project aims to port Tiano StandaloneMmPkg on RISC-V to support authenticated variable store and other MM scenarios.

For general background on Management Mode (MM), as noted in the PI specification Volume 4: Management Mode Core Interface,

MM is a generic term used to describe a secure execution environment provided by the CPU and related silicon that is entered when the CPU detects a Management Mode Interrupt (MMI).

x86 systems implement MM with System Management Mode (SMM) and ARM systems do so with TrustZone (TZ), while the RISC-V implementation will be based on various "Secure Monitor" environments (eg: raw M mode using OpenSBI, TEE using Salus/Penglai/etc)




Project Scope and Timelines

Main Features:

  • Securing EFI variables access required for UEFI secure boot
  • Ensure the access to the secure non-volatile storage only via code executing in MM mode

Main Phases:

  • Phase 1: The project's initial focus will be prototype and enable securing EFI variables required for UEFI secure boot on M-Mode OpenSBI and QEMU - Done
  • Phase 2: Future phase of the project will focus on enabling the StandaloneMM on a sPMP based TEE or TVM on QEMU  - Not ready, CoVE could be a good secure monitor candidate
  • Phase 3: The final phase of the project will try to build a reference StandaloneMM based secure boot solution on a real hardware.   - Done

Details:

Components and Repos

edk2-staging branch(https://github.com/tianocore/edk2-staging/tree/RiscV64StandaloneMm) to implement StandaloneMm on RiscV64

Upstream edk2, with the branch used consistent with other RISE UEFI projects .

Stakeholders and Partners

Dependencies

Software

The StandaloneMmPkg will be based on TEE Secure Monitor or Trusted FW implementation on RiscV64.

  • The OpenSBI domain can be used as the trusted fw implemenation in the non-hypervisor based PoC.
  • The Salus project(https://github.com/rivosinc/salus/) which is a AP-TEE hypervisor will be used for the PoC.  Most likely, additonal CoVE/CoVE-IO changes on both specification and implementation side are needed.

Specifications

CoVE

CoVE needs to allow the creation of certain "protected" TVMs by UEFI - e.g. like StandaloneMmPkg. The OS should not be able to manipulate such a TVM (This could be done by invoking a special SBI call in UEFI to protect all existing TVMs - preventing any further control on them, even from UEFI RT). 

https://github.com/riscv-non-isa/riscv-ap-tee/tree/main

CoVE-IO

CoVE-IO needs to allow certain platform devices (non-PCIe devices). The assignment along with TVM creation will be done by UEFI, not an OS.

https://github.com/riscv-non-isa/riscv-ap-tee-io/blob/main/specification/requirements.adoc

RPMI

Use RPMI SBI extention messaging to communicate between Secure Exection Environment and normal world OS, the proposal for the MM service is raised in the following document.

https://github.com/riscv-non-isa/riscv-rpmi

Measure of Success

An accepted and tested design and implementation for Phase 1 and Phase 2 by end of 2H23 (slated for merging).

A QEMU based implementaion (based on RiscVirt) ready for upstream

RISE Requirements

None (not accounting any of existing engineering investment against RISE resources).

Status

Dependency

Function work, but code hasn't been frozon. Depends on RPMI spec ratifaction, related patch upstream


Development

ONGOING


Development Timeline

Upstreaming

NA


Upstream version

Contacts

Tuan Phan  (Ventana)

Yong Li (Deactivated)  (Intel)



Participants

Name (Company)Notes

Tuan Phan  (Ventana)


Yong Li (Deactivated)  (Intel)


Dhaval Samuel (Rivos)

Updates

Status:

Status:

  • Phase 1: OpenSBI based PoC (Non-Hypvervisor platform) - Done
    • A QEMU based implementaion (based on RiscVirt) in edk2 staging repo
    • Contributed MM service to RPMI spec, currently in Google doc
    • OpenSBI domain context implementation in review
  • Phase 2: TVM based PoC
    • Initial prototype in StandaloneMmPkg based on CoVE has been done, but the whole design has not been aligned
  • Phase 3: Reference Implementation Done
    • Built a reference StandaloneMM based secure boot solution on StarFive's VF2 board

More detail summary:

Next Step:

  • Upstream OpenSBI domain context manager code
  • Contribute RPMI MM to the PRXY and RPMI PoC
  • Wait RPMI spec ratifiaction, upstream the StandaloneMmPkg to edk2 repo
  • Hypervisor platfrom design discussion

Design and the Implementation:

  • High Level Design Document   - Draft done. EDK2_00_02_02 Standalone MM design (draft)
  • Unify MM payload for ARM and RISC-V  - Done
  • Unify MM entrypoint API for ARM and RISC-V - Done,  The patch is under review https://edk2.groups.io/g/devel/message/108661
  • Hob re-structure and MM entrypoint with HOB address  - Done, Now use a0 for hartid, and a2 for bootinfo which is align with the edk2 side HOB implementation
  • Qemu to support flash1 storage variable.  - Done Rebased with the latest EDK2 repo. flash1 has been used for storage variable

Specification:

Evaluation:

Next Step:

  • Base on the new RPMI proposal and port the StandaloneMm to the OpenSBI located in RPMI PoC.
  • Work with StarFive together to evaluate the StandaloneMmPkg and the secure boot on VisionFiveV2 board (though may have dma risk)
  • Work with Rivos for the next step plan based on the CoVE spec

 

Baseline code pushed to the staging branch

https://github.com/tianocore/edk2-staging/tree/RiscV64StandaloneMm

 

Project reported to RISE board as active priority.