diff options
| author |   Angelos Mouzakitis <a.mouzakitis@virtualopensystems.com> | 2023-10-10 14:33:42 +0000 |
|---|---|---|
| committer | Angelos Mouzakitis <a.mouzakitis@virtualopensystems.com> | 2023-10-10 14:33:42 +0000 |
| commit | af1a266670d040d2f4083ff309d732d648afba2a (patch) | |
| tree | 2fc46203448ddcc6f81546d379abfaeb323575e9 /roms/skiboot/doc/secvar/edk2.rst | |
| parent | e02cda008591317b1625707ff8e115a4841aa889 (diff) | |
Change-Id: Iaf8d18082d3991dec7c0ebbea540f092188eb4ec
Diffstat (limited to 'roms/skiboot/doc/secvar/edk2.rst')
| -rw-r--r-- | roms/skiboot/doc/secvar/edk2.rst | 49 |
1 files changed, 49 insertions, 0 deletions
diff --git a/roms/skiboot/doc/secvar/edk2.rst b/roms/skiboot/doc/secvar/edk2.rst new file mode 100644 index 000000000..1e4cc9e31 --- /dev/null +++ b/roms/skiboot/doc/secvar/edk2.rst @@ -0,0 +1,49 @@ +.. _secvar/edk2: + +Skiboot edk2-compatible Secure Variable Backend +=============================================== + +Overview +-------- + +The edk2 secure variable backend for skiboot borrows from edk2 concepts +such as the three key hierarchy (PK, KEK, and db), and a similar +structure. In general, variable updates must be signed with a key +of a higher level. So, updates to the db must be signed with a key stored +in the KEK; updates to the KEK must be signed with the PK. Updates to the +PK must be signed with the previous PK (if any). + +Variables are stored in the efi signature list format, and updates are a +signed variant that includes an authentication header. + +If no PK is currently enrolled, the system is considered to be in "Setup +Mode". Any key can be enrolled without signature checks. However, once a +PK is enrolled, the system switches to "User Mode", and each update must +now be signed according to the hierarchy. Furthermore, when in "User +Mode", the backend initialized the ``os-secure-mode`` device tree flag, +signaling to the kernel that we are in secure mode. + +Updates are processed sequentially, in the order that they were provided +in the update queue. If any update fails to validate, appears to be +malformed, or any other error occurs, NO updates will not be applied. +This includes updates that may have successfully applied prior to the +error. The system will continue in an error state, reporting the error +reason via the ``update-status`` device tree property. + +P9 Special Case for the Platform Key +------------------------------------ + +Due to the powerful nature of the platform key and the lack of lockable +flash, the edk2 backend will store the PK in TPM NV rather than PNOR on +P9 systems. (TODO expand on this) + +Update Status Return Codes +-------------------------- + +TODO, edk2 driver needs to actually return these properly first + + +Device Tree Bindings +-------------------- + +TODO |