diff --git a/specification/riscv-platform-security-model.pdf b/specification/riscv-platform-security-model.pdf index 467f0a5..23130fc 100644 Binary files a/specification/riscv-platform-security-model.pdf and b/specification/riscv-platform-security-model.pdf differ diff --git a/specification/src/chapter1.adoc b/specification/src/chapter1.adoc index c4ebd26..2cdf9db 100644 --- a/specification/src/chapter1.adoc +++ b/specification/src/chapter1.adoc @@ -3,19 +3,19 @@ == Introduction -This specification provides guidelines for how RISC-V security building blocks +This specification provides guidelines for how RISC-V security building blocks can be used to build secure systems for different use cases. It is aimed at developers of RISC-V technical specifications, as well as at designers of secure RISC-V systems. -A few example uses cases based on commonly used deployment models are provided. -These use cases are not intended to be exhaustive, or to act as protection profiles. -They are intended as templates to be used as general guidelines, -which can be applied to a wide variety of use cases. +A few example uses cases based on commonly used deployment models are provided. +These use cases are not intended to be exhaustive, or to act as protection +profiles. They are intended as templates to be used as general guidelines, +which can be applied to a wide variety of use cases. -The examples may be extended over time as required. Protection profiles for more -specific use cases are expected to be provided within relevant certification bodies, -or as separate RISC-V specifications if required. +The examples may be extended over time as required. Protection profiles for more +specific use cases are expected to be provided within relevant certification +bodies, or as separate RISC-V specifications if required. === Requirements and tracking @@ -28,9 +28,12 @@ trackable requirements using the following format: | ID# | Requirement -| CAT_NNN -| The `CAT` is a category prefix that logically groups the requirements and is -followed by 3 digits - `NNN` - assigning a numeric ID to the requirement. + +| SR_CAT_NNN +| The `SR_CAT` is a "Security Requirement CATegory" prefix that logically groups +the requirements (e.g. SR_UPD denotes security requirements related to updates, +and SR_ATT denotes security requirements related to attestation) and is followed +by 3 digits - `NNN` - assigning a numeric ID to the requirement. + The requirements use the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" that are to be interpreted as described in diff --git a/specification/src/chapter2.adoc b/specification/src/chapter2.adoc index b8e349a..a1dd683 100644 --- a/specification/src/chapter2.adoc +++ b/specification/src/chapter2.adoc @@ -40,12 +40,15 @@ Examples of assets include: * Proprietary models * Secret algorithms -In this specification, a _hardware provisioned asset_ is an immutable asset provisioned in hardware by a security provisioning process, before a device is used in a production environment. For example, hardware provisioned keys or identities. +In this specification, a _hardware provisioned asset_ is an immutable asset +provisioned in hardware by a security provisioning process, before a device is +used in a production environment. For example, hardware provisioned keys or +identities. ==== Trusted Computing Base (TCB) The _Trusted Computing Base (TCB)_ of a component is the minimum amount of -software and hardware that needs to be trusted by that component. +software and hardware that needs to be trusted by that component. The TCB of a component typically includes other software. For example: @@ -56,7 +59,9 @@ The TCB of a component typically includes other software. For example: ==== Root of trust -The minimum amount of hardware and/or software that always has to be trusted on a system is its _root of trust (RoT)_. A RoT supports fundamental security services, for example: +The minimum amount of hardware and/or software that always has to be trusted on +a system is its _root of trust (RoT)_. A RoT supports fundamental security +services, for example: * Boot and attestation * Security lifecycle management @@ -69,39 +74,49 @@ Depending on use case and ecosystem requirements, a RoT can be: * A dedicated trusted subsystem (HW RoT), supporting a FW RoT Using a HW RoT moves critical functions and assets off a Hart to a dedicated -trusted subsystem, which can provide stronger protection against physical and logical attack than a complex Hart. +trusted subsystem, which can provide stronger protection against physical and +logical attack than a complex Hart. -NOTE: It is common for secure systems to support multiple trust chains with their own root of trust. For example, a TPM can be a root of trust for UEFI -boot flows within a runtime environment, and a SIM can be a root of trust for user identity management. + +NOTE: It is common for secure systems to support multiple trust chains with +their own root of trust. For example, a TPM can be a root of trust for UEFI +boot flows within a runtime environment, and a SIM can be a root of trust for +user identity management. + + For the purpose of this document, these should be treated as _secondary roots of trust_. + + -The HW RoT acts as a _primary root of trust_ on the system. For example, the HW RoT governs boot, and can load firmware and manage the security lifecycle of a secondary root of trust. +The HW RoT acts as a _primary root of trust_ on the system. For example, the HW +RoT governs boot, and can load firmware and manage the security lifecycle of a +secondary root of trust. +[#cat_sr_sub_rot] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_ROT_001 | A complex secure system MUST implement a HW RoT -| CAT_NNN +| SR_ROT_002 | A simpler system MAY not require a HW RoT but one is still recommended |=== -Examples of a complex system include one with coherent multi-core, or out of order, application Harts. +Examples of a complex system include one with coherent multi-core, or out of +order, application Harts. Examples of a simpler system include a single core in-order microcontroller. -NOTE: In this document, the terms "FW RoT" and "HW RoT" will be used as defined above. The term "RoT" on its own can be used where a rule or a rational applies to either model. +NOTE: In this document, the terms "FW RoT" and "HW RoT" will be used as defined +above. The term "RoT" on its own can be used where a rule or a rational applies +to either model. ==== Isolation -Assets can be protected by _isolation_. Isolation reduces dependencies between components, and reduces the amount of software that needs to be trusted. +Assets can be protected by _isolation_. Isolation reduces dependencies between +components, and reduces the amount of software that needs to be trusted. Isolation protects _resources_: @@ -116,8 +131,10 @@ privileged software. * Physical memory isolation + More privileged software controls memory access for less privileged software. * Domain isolation + -Software in one domain cannot access or modify resources assigned to a different domain (without consent), regardless of privilege level. + -(Higher privileged software in one domain cannot access resources assigned to a lower privilege level in a different domain) +Software in one domain cannot access or modify resources assigned to a different +domain (without consent), regardless of privilege level. + +(Higher privileged software in one domain cannot access resources assigned to a +lower privilege level in a different domain) * Virtualization + Virtualization creates and manages _virtual resources_ - compute, memory, devices - independent of actual physical hardware. A system, or individual @@ -158,79 +175,101 @@ break security guarantees, either directly or indirectly. For example: * Power and timing management * RAS (_reliability, accessibility, serviceability_) +[#cat_sr_sub_inv] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_INV_001 | Invasive subsystems MUST be controlled, or moderated, by a RoT. +| SR_INV_002 +| Invasive subsystems SHOULD be enabled separately for M-mode & +non-M-mode software. |=== ==== Event counters -Event counters are commonly used for performance management and resource allocation. +Event counters are commonly used for performance management and resource +allocation. -However, they can also pose a security risk. For example, one workload monitoring an operation in a different workload, or an operation by higher privilege software, could be able to reveal assets used in those operations. +However, they can also pose a security risk. For example, one workload +monitoring an operation in a different workload, or an operation by higher +privilege software, could be able to reveal assets used in those operations. +[#cat_sr_sub_pmu] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN -| Lower privilege software MUST NOT be able to monitor higher privilege software. +| SR_PMU_001 +| Lower privileged software MUST NOT be able to monitor higher privileged +software. -| CAT_NNN -| Software in one domain MUST NOT be able to monitor software in a different domain, without consent. +| SR_PMU_002 +| Software in one domain MUST NOT be able to monitor software in a different +domain, without consent. |=== ==== Platform quality of service -Server platforms can provide _platform quality of service (QoS)_ features, consisting of Hart and system hardware and firmware aimed at managing access to shared physical resources across workloads, minimizing contention. For example: +Server platforms can provide _platform quality of service (QoS)_ features, +consisting of Hart and system hardware and firmware aimed at managing access to +shared physical resources across workloads, minimizing contention. For example: * Memory bandwidth management * Cache allocation policies across workloads, including workload prioritization * Hart allocation policies across workloads -These types of features rely on monitoring resource utilization of workloads, similar to event counters, and optimizing resource allocation policies. +These types of features rely on monitoring resource utilization of workloads, +similar to event counters, and optimizing resource allocation policies. +[#cat_sr_sub_qos] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN -| Lower privilege software MUST NOT be able to monitor higher privilege software. +| SR_QOS_001 +| Lower privileged software MUST NOT be able to monitor higher privileged +software. -| CAT_NNN -| Software in one domains MUST NOT be able to monitor software in a different domain, without consent. +| SR_QOS_002 +| Software in one domains MUST NOT be able to monitor software in a different +domain, without consent. |=== ==== Denial of service -The RISC-V security model is primarily concerned with protection of assets. +The RISC-V security model is primarily concerned with protection of assets. -For example, a hosting environment is free to apply their own resource allocation policy to any workloads. Including denying service. This applies in the same way to confidential workloads. +For example, a hosting environment is free to apply their own resource +allocation policy to any workloads. Including denying service. This applies in +the same way to confidential workloads. +[@cat_sr_sub_dos] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN -| Lower privilege software MUST NOT be able to deny service to higher privilege software, or other isolated workloads at the same privilege level. +| SR_DOS_001 +| Lower privileged software MUST NOT be able to deny service to higher +privileged software, or other isolated workloads at the same privilege level. |=== -Higher privilege software always has to be able to enforce its own resource management policy without interference. Including scheduling and resource assignment policies. +Higher privileged software always has to be able to enforce its own resource +management policy without interference. Including scheduling, resource +assignment and recovation policies. === Adversarial model @@ -290,6 +329,7 @@ models and requirements. ==== Logical +[#cat_sr_sub_lgc] [width=100%] [%header, cols="5,5,5,10,15,10"] |=== @@ -300,7 +340,7 @@ models and requirements. | Current RISC-V mitigations | Planned RISC-V mitigations -| CAT_NNN +| SR_LGC_001 | Unrestricted access | Direct + Logical @@ -310,14 +350,15 @@ a| * RISC-V privilege levels * RISC-V hardware virtualization (H extension, MMU) | -| CAT_NNN +| SR_LGC_002 | Transient execution attacks | Chained + Logical | Attacks on speculative execution implementations. | Known (documented) attacks, except Spectre v1, are specific to particular -micro-architectures. Micro-architecture for RISC-V systems is implementation specific, but must not introduce such vulnerabilities. + - + +micro-architectures. Micro-architecture for RISC-V systems is implementation +specific, but must not introduce such vulnerabilities. + + + This is an evolving area of research. + + For example: + @@ -328,7 +369,7 @@ https://developer.arm.com/documentation/#cf-navigationhierarchiesproducts=Arm%20 vulnerability] | Fence.t, or similar future extensions, could at least partially mitigate against Spectre v1. -| CAT_NNN +| SR_LGC_003 | Interface abuse | Chained + Logical @@ -338,7 +379,7 @@ a| * RISC V privilege levels * RISC-V isolation | High assurance cryptography -| CAT_NNN +| SR_LGC_004 | Event counting | Direct + Logical @@ -349,7 +390,7 @@ a| * Data-independent timing instructions (sscofpmf, smcntrpmf) | -| CAT_NNN +| SR_LGC_005 | Redirect control flow | Chained + Logical @@ -363,6 +404,7 @@ a| * Shadow stacks (Zicfiss) ==== Physical and remote +[#cat_sr_sub_phy] [width=100%] [%header, cols="5,10,10,15,15"] |=== @@ -372,7 +414,7 @@ a| * Shadow stacks (Zicfiss) | Description | RISC-V recommendations -| CAT_NNN +| SR_PHY_001 | Analysis of physical leakage | Direct or indirect + Physical or remote @@ -380,7 +422,7 @@ Physical or remote a| * Implement robust power management and radiation control * Data Independent Execution Latency (Zkt, Zvkt) -| CAT_NNN +| SR_PHY_002 | Physical memory manipulation | Direct + Logical or physical @@ -395,7 +437,7 @@ or physical tamper resistance derive memory encryption contexts at domain or workload granularity * Provide a degree of tamper resistance -| CAT_NNN +| SR_PHY_003 | Boot attacks | Chained + Logical or physical @@ -404,7 +446,7 @@ a| * Glitching to bypass secure boot a| * Implement robust power management * Implement cryptographic memory protection with at least boot freshness -| CAT_NNN +| SR_PHY_004 | Subverting supply chains | Remote | Infiltration or collusion to subvert security provisioning chains, software @@ -430,13 +472,14 @@ This is discussed more in use case examples later in this specification. ==== Secure identity +[cat_sr_sub_idn] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_IDN_001 | A security platform MUST be securely identifiable |=== @@ -462,13 +505,14 @@ provisioned assets. ==== Security lifecycle +[#cat_sr_sub_lfc] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_LFC_001 | A secure system MUST manage a security lifecycle. |=== @@ -476,22 +520,33 @@ provisioned assets. [title= "Generic security lifecycle"] image::img_ch2_security-lifecycle.png[] +[#security-lifecycle] A security lifecycle reflects the trustworthiness of a system during its lifetime and reflects the lifecycle state of hardware provisioned assets. -It can be extended as indicated below to cover additional security provisioning steps such as device onboarding, device activation, user management, and RMA processes. These are use case or ecosystem specific and out of scope of this +It can be extended as indicated below to cover additional security provisioning +steps such as device onboarding, device activation, user management, and RMA +processes. These are use case or ecosystem specific and out of scope of this specification. -For the purpose of this specification, _revealing debug_ includes any HW or FW debug capability which +For the purpose of this specification, _revealing debug_ includes any HW or FW +debug capability which -* Could break security guarantees or could expose assets -* Is not part of an attested trust contract with a relying party +* Could break security guarantees or could expose assets +* Is not part of an attested trust contract with a relying party -Examples of revealing debug include revealing logging, external debug or boundary scans, dedicated debug builds of software components, or enabling self-hosted debug for a component. +Examples of revealing debug include revealing logging, external debug or +boundary scans, dedicated debug builds of software components, or enabling +self-hosted debug for a component. -Depending on use case, an attested software component can include debug capabilities managed through an ecosystem defined governance process - _trusted debug_. For example, self-hosted debug enabled following an ecosystem specific authorization process. In this case the debug capability, and the associated governance, is part of the trust contract with a relying party. +Depending on use case, an attested software component can include debug +capabilities managed through an ecosystem defined governance process +- _trusted debug_. For example, self-hosted debug enabled following an ecosystem +specific authorization process. In this case the debug capability, and the +associated governance, is part of the trust contract with a relying party. -For the purpose of this specification, a minimum security lifecycle includes at least the following states: +For the purpose of this specification, a minimum security lifecycle includes at +least the following states: * Manufacture - The system may not yet be locked down and has no hardware provisioned assets @@ -501,21 +556,27 @@ Depending on ecosystem requirement, security provisioning could be performed in multiple stages through a supply chain and may require additional sub-states. These types of application specific extensions are out of scope of this specification. -* Secured - hardware provisioned assets are locked (immutable), only authorized software can be used, and revealing debug is not enabled. + +* Secured - hardware provisioned assets are locked (immutable), only authorized +software can be used, and revealing debug is not enabled. + Additional specific provisioning stages can take place in this state - for example network onboarding and device activation, TSS/App/Device attestation or user identity management. This is out of scope of this specification. * Recoverable debug - part of the system is in a revealing debug state + -At least the RoT is not compromised and hardware provisioned secrets remain protected. + -This state is both attestable and recoverable. For example, revealing debug is enabled for a domain without compromising another domain or any RoT services. +At least the RoT is not compromised and hardware provisioned secrets remain +protected. + +This state is both attestable and recoverable. For example, revealing debug is +enabled for a domain without compromising another domain or any RoT services. * Terminated - any system change which could expose hardware provisioned assets + Typically hardware provisioned assets are made permanently inaccessible and -revoked before entering this state. This also protects any derived assets such as attestation and sealing keys. +revoked before entering this state. This also protects any derived assets such +as attestation and sealing keys. A system could support re-provisioning from a terminated state, for example -following repair/RMA. This can be viewed as equivalent to starting over from the security provisioning state, and creates a new instance with a new secure identifier. +following repair/RMA. This can be viewed as equivalent to starting over from the +security provisioning state, and creates a new instance with a new secure +identifier. [width=100%] [%header, cols="5,20"] @@ -523,11 +584,11 @@ following repair/RMA. This can be viewed as equivalent to starting over from the | ID# | Requirement -| CAT_NNN +| SR_LFC_002 | Hardware provisioned assets MUST only be accessible while the system is in secured state, or a recoverable debug state. -| CAT_NNN +| SR_LFC_003 | Derived assets MUST only be available if a component is in secured state. |=== @@ -537,15 +598,17 @@ secured state, or a recoverable debug state. | ID# | Requirement -| CAT_NNN +| SR_LFC_004 | Hardware provisioned assets MUST only be accessible while the system is in -secured state, or a recoverable debug state (with the recoverable debug state in attestation evidence). +secured state, or a recoverable debug state (with the recoverable debug state in +attestation evidence). -| CAT_NNN +| SR_LFC_005 | Derived assets MUST only be available if a component is in secured state. |=== -A derived asset in this context is any asset derived from hardware provisioned assets. For example attestation keys, or sealing keys for a supervisor domain. +A derived asset in this context is any asset derived from hardware provisioned +assets. For example attestation keys, or sealing keys for a supervisor domain. [width=100%] [%header, cols="5,20"] @@ -553,19 +616,25 @@ A derived asset in this context is any asset derived from hardware provisioned a | ID# | Requirement -| CAT_NNN +| SR_LFC_006 | Revealing debug MUST be reflected in attestation. |=== -_Attestable states_ are ones where the RoT and hardware provisioned assets are not compromised by debug and a valid attestation can be generated reflecting that state: +_Attestable states_ are ones where the RoT and hardware provisioned assets are +not compromised by debug and a valid attestation can be generated reflecting +that state: * Secured * Recoverable debug -In other states the system is not able to generate a valid attestation key. It is still _indirectly attestable_ as any generated attestation will not be signed correctly and can be rejected by a relying party. +In other states the system is not able to generate a valid attestation key. It +is still _indirectly attestable_ as any generated attestation will not be signed +correctly and can be rejected by a relying party. -Trusted debug is part of a trust contract with a relying party, and application specific. The presence of trusted debug can be determined indirectly by a relying party through other attested properties, for example measurements. +Trusted debug is part of a trust contract with a relying party, and application +specific. The presence of trusted debug can be determined indirectly by a +relying party through other attested properties, for example measurements. ==== Attestable services @@ -573,13 +642,14 @@ For the purpose of this specification a confidential service can be any isolated component on a system. For example, a hosted confidential workload, or an isolated application security service. +[#cat_sr_sub_att] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_ATT_001 | A confidential service, and all software and hardware components it depends on, MUST be attestable. |=== @@ -611,42 +681,46 @@ examples later in this specification. | ID# | Requirement -| CAT_NNN -| A security platform attestation MUST be signed by a HW RoT, if present, or else by -a FW RoT +| SR_ATT_002 +| A security platform attestation MUST be signed by a HW RoT, if present, or +else by a FW RoT -| CAT_NNN +| SR_ATT_003 | A security platform attestation MUST be signed using a hardware provisioned (directly or derived) secure identity -| CAT_NNN +| SR_ATT_004 | A layered attestation MAY be signed by lower privileged software, itself attested by a security platform attestation -| CAT_NNN -a| Layered attestations MUST be cryptographically bound such that a relying party can determine that they +| SR_ATT_005 +a| Layered attestations MUST be cryptographically bound such that a relying +party can determine that they: * Were generated on the same system -* Are fresh. +* Are fresh. |=== -NOTE: Software interfaces should only support either direct attestation or layered attestation workflows, never both, to prevent impersonation attacks. +NOTE: Software interfaces should only support either direct attestation or +layered attestation workflows, never both, to prevent impersonation attacks. ==== Authorized software Running unauthorized software can compromise the security state of the system. +[#cat_sr_sub_aut] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN -| A system in secured or recoverable debug states MUST only load authorized software. +| SR_AUT_001 +| A system in secured or recoverable debug states MUST only load authorized +software. -| CAT_NNN +| SR_AUT_002 | A system in security provisioning state SHOULD only load authorized software. |=== @@ -689,16 +763,17 @@ authorization. The measurement is included in derivations of other assets, for example sealing keys, binding assets to a measured state. +[#cat_sr_sub_msm] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_MSM_001 | A security platform MUST be measured. -| CAT_NNN +| SR_MSM_002 | A security platform MUST be verified, either directly or indirectly, before launching services which depend on the security platform. @@ -712,7 +787,7 @@ Verification ensures the system has loaded authorized software | ID# | Requirement -| CAT_NNN +| SR_MSM_003 | A system MUST only use authorizations from trusted authority. |=== @@ -720,7 +795,8 @@ Verification ensures the system has loaded authorized software authority before loading an image + For example, a signed image, or a separately signed authorization message. -* Indirect verification requires a signed authorization from a trusted authority for migrating assets bound to a previously measured state + +* Indirect verification requires a signed authorization from a trusted authority +for migrating assets bound to a previously measured state + For example, a signed provisioning message. Either way, only authorizations from trusted authorities should be used. For @@ -732,7 +808,8 @@ authorities. |=== | ID# | Requirement -| CAT_NNN + +| SR_MSM_004 | Local verification MUST be rooted in immutable boot code. |=== @@ -745,13 +822,14 @@ Over time, any non-immutable component may need updates to address vulnerabilities or functionality improvements. A system update can concern software, firmware, microcode, or any other updatable component on a system. +[#cat_sr_sub_upd] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_UPD_001 | All components on a system which are not immutable MUST be updatable. |=== @@ -769,7 +847,7 @@ any system update. | ID# | Requirement -| CAT_NNN +| SR_UPD_002 | A system update MUST be measured and verified before launch. |=== @@ -789,10 +867,10 @@ The update can be effected without restarting any dependent components. | ID# | Requirement -| CAT_NNN +| SR_UPD_003 | Updates affecting a security platform SHOULD be deferred. -| CAT_NNN +| SR_UPD_004 | Updates MAY be live if live update capability, and suitable governance, is part of an already attested trust contract between a relying party and the system. @@ -809,10 +887,10 @@ or not, as well as affect any derived assets such as sealing keys. | ID# | Requirement -| CAT_NNN +| SR_UPD_005 | System updates MUST be monotonic -| CAT_NNN +| SR_UPD_006 | System updates SHOULD be robust against update failures |=== @@ -837,7 +915,7 @@ and a dedicated recovery loader. | ID# | Requirement -| CAT_NNN +| SR_UPD_007 | System updates, and authorization messages, SHOULD only be received from trusted sources. @@ -860,13 +938,14 @@ and integration actors often share mutual distrust: Use cases later in this specification provide examples of RISC-V isolation models. +[#cat_sr_sub_iso] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_ISO_001 | Isolated software components SHOULD be supported |=== @@ -879,7 +958,7 @@ accessible to other components. | ID# | Requirement -| CAT_NNN +| SR_ISO_002 | Devices MUST not access memory belonging to an isolated component without permission |=== @@ -888,28 +967,36 @@ Isolation can also extend to other features, such as interrupts and debug. ==== Sealing -Sealing is the process of protecting confidential assets on a system, typically using sealing keys derived in different ways for different use cases as discussed in this section. For example, from a hardware provisioned root key, from a boot state (measurements, security lifecycle state), or provisioned at runtime by a remote provisioning system. +Sealing is the process of protecting confidential assets on a system, typically +using sealing keys derived in different ways for different use cases as +discussed in this section. For example, from a hardware provisioned root key, +from a boot state (measurements, security lifecycle state), or provisioned at +runtime by a remote provisioning system. Sealing can be: * Local + -Local sealing binds assets to a local device (hardware unique sealing) or to a measured boot state. +Local sealing binds assets to a local device (hardware unique sealing) or to a +measured boot state. * Remote + Remote sealing binds assets to credentials provided by a remote provisioning service following successful attestation. +[#cat_sr_sub_slg] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_SLG_001 | Sealed assets SHOULD only be possible to unseal in a secured state |=== -For example, local sealing key derivations should take the security lifecycle state of the system into account. And remote sealing key provisioning should always attest the system before releasing unsealing credentials or keys. +For example, local sealing key derivations should take the security lifecycle +state of the system into account. And remote sealing key provisioning should +always attest the system before releasing unsealing credentials or keys. Local sealing can be: @@ -925,12 +1012,14 @@ privileged software. | ID# | Requirement -| CAT_NNN -| Locally sealed assets MUST only be possible to unseal on the same physical instance of a system that they were sealed on. +| SR_SLG_002 +| Locally sealed assets MUST only be possible to unseal on the same physical +instance of a system that they were sealed on. |=== -For example, using sealing keys derived from a hardware provisioned _hardware unique key (HUK)_. +For example, using sealing keys derived from a hardware provisioned _hardware +unique key (HUK)_. [width=100%] [%header, cols="5,20"] @@ -938,8 +1027,10 @@ For example, using sealing keys derived from a hardware provisioned _hardware un | ID# | Requirement -| CAT_NNN -| Locally sealed assets bound to a boot measurement MUST only be possible to unseal if that measurement has not changed, or the system has received an authorized update. +| SR_SLG_003 +| Locally sealed assets bound to a boot measurement MUST only be possible to +unseal if that measurement has not changed, or the system has received an +authorized update. |=== diff --git a/specification/src/chapter3.adoc b/specification/src/chapter3.adoc index 23e8625..bc3356d 100644 --- a/specification/src/chapter3.adoc +++ b/specification/src/chapter3.adoc @@ -54,9 +54,14 @@ MMU, PMP/ePMP, and sPMP are discussed later in this chapter. https://github.com/riscv/riscv-isa-manual/releases/tag/Priv-v1.12[Privileged ISA] -_Physical memory attributes (PMA)_ are intended to capture inherent properties of the underlying hardware. For example, read-only ROM regions, or non-cachable device regions. Often PMA can be fixed at design time or at boot, but sometimes runtime PMA can be required. +_Physical memory attributes (PMA)_ are intended to capture inherent properties +of the underlying hardware. For example, read-only ROM regions, or non-cachable +device regions. Often PMA can be fixed at design time or at boot, but sometimes +runtime PMA can be required. -A separate hardware checker - _PMA checker_ - enforces PMA rules at runtime once a physical address is known. PMA rules are always checked on every physical access, and typically configured by region. +A separate hardware checker - _PMA checker_ - enforces PMA rules at runtime once +a physical address is known. PMA rules are always checked on every physical +access, and typically configured by region. ==== PMP and ePMP @@ -66,13 +71,14 @@ ISA] _Physical memory protection (PMP)_ enables M-mode to access-control physical memory for supervisor or HS modes. +[#cat_sr_sub_pmp] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_PMP_001 | PMP configurations MUST only be directly accessible to machine mode |=== @@ -89,7 +95,7 @@ against privilege escalation attacks, for example. | ID# | Requirement -| CAT_NNN +| SR_PMP_002 | If PMP is supported then ePMP MUST be supported. |=== @@ -114,9 +120,9 @@ memory allocations to its workloads. | ID# | Requirement -| CAT_NNN -| Either sPMP, 1st-stage or G-stage page tables MUST be used to protect -Supervisor domain H/S-mode from lower privilege levels. +| SR_PMP_003 +| if Sv is not supported, sPMP SHOULD be used to protect Supervisor domain +S-mode from lower privilege levels. |=== ==== MMU @@ -131,15 +137,20 @@ translation) * Isolating a hypervisor from a guest, on a system with H-extension (two-stage translation) +[#cat_sr_sub_mmu] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_MMU_001 | Either PMP/ePMP or MTT MUST be used to protect M-mode from lower privilege levels. + +| SR_MMU_002 +| if Sv is supported 1st-stage and/or G-stage page tables MUST used to protect +Supervisor domain H/S-mode from lower privilege levels. |=== ==== Supervisor domains @@ -154,15 +165,17 @@ memory, execution state, and devices - from other supervisor domains regardless of privilege level (below M-mode). Isolation and context switching between supervisor domains are managed by M-mode firmware. -A supervisor domain is identified at architecture level by a _supervisor domain id (SDID)_, managed by M-mode firmware. +A supervisor domain is identified at architecture level by a _supervisor domain +id (SDID)_, managed by M-mode firmware. +[cat_sr_sub_sud] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NN +| SR_SUD_001 | PMP/ePMP or MTT MUST be used to enforce physical memory isolation boundaries for supervisor domains, and to protect machine mode from any supervisor domain. @@ -174,7 +187,12 @@ PMP can be used for more static and deterministic use cases. MTT can be used where more fine grained dynamic resource management across supervisor domain boundaries is required. -NOTE: MTT can be sufficient for protecting Root domain in the sense that M-mode can enforce that its own resources are never assigned to another domain. PMP/ePMP still add further protections for M-mode, such as the ability to implement temporal isolation boundaries within M-mode (for example, protect early boot code), or to prevent itself from accessing or executing from memory assigned to lower privilege levels (privilege escalation). +NOTE: MTT can be sufficient for protecting Root domain in the sense that M-mode +can enforce that its own resources are never assigned to another domain. +PMP/ePMP still add further protections for M-mode, such as the ability to +implement temporal isolation boundaries within M-mode (for example, protect +early boot code), or to prevent itself from accessing or executing from memory +assigned to lower privilege levels (privilege escalation). [width=100%] [%header, cols="5,20"] @@ -183,10 +201,10 @@ NOTE: MTT can be sufficient for protecting Root domain in the sense that M-mode | ID# | Requirement -| CAT_NNN +| SR_SUD_002 | A system supporting supervisor domains MUST support supervisor domain -extensions for interrupts (Smsdia) and performance counters (TBD), and SHOULD -support supervisor domain extensions for external debug (Smsdsd TBD). +extensions for interrupts (Smsdia) and SHOULD support supervisor domain +extensions for external debug (TBD). |=== @@ -217,21 +235,27 @@ enable fine grained dynamic memory management across supervisor domain boundaries, with policy typically set by a hypervisor in a hosting domain responsible for resource management. +[#cat_sr_sub_mtt] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_MTT_001 | Either PMP/ePMP or MTT MUST be used to protect M-mode from lower privilege levels -| CAT_NNN +| SR_MTT_002 | MTT configurations MUST only be directly accessible to machine mode |=== -NOTE: MTT can be sufficient for protecting Root domain in the sense that M-mode can enforce that its own resources are never assigned to another domain. PMP/ePMP still add further protections for M-mode, such as the ability to implement temporal isolation boundaries within M-mode (for example, protect early boot code), or to prevent itself from accessing or executing from memory assigned to lower privilege levels (privilege escalation). +NOTE: MTT can be sufficient for protecting Root domain in the sense that M-mode +can enforce that its own resources are never assigned to another domain. +PMP/ePMP still add further protections for M-mode, such as the ability to +implement temporal isolation boundaries within M-mode (for example, protect +early boot code), or to prevent itself from accessing or executing from memory +assigned to lower privilege levels (privilege escalation). ==== IOPMP @@ -240,21 +264,24 @@ https://github.com/riscv-non-isa/iopmp-spec IOPMP is a system level component providing physical memory access control for device-initiated transactions, complementing PMP and sPMP rules. +[#cat_sr_sub_iop] [width=100%] [%header, cols="5,20"] |=== | ID# | Requirement -| CAT_NNN +| SR_IOP_001 | A system which supports PMP/ePMP, or sPMP, MUST implement IOPMP for device access control. -| CAT_NNN +| SR_IOP_002 | IOPMP configurations MUST only be directly accessible to machine mode. |=== -NOTE: IOPMP defines multiple "models" for different system configurations. Unless specified differently in the use cases in this specification, system designers are free to choose any IOPMP model. +NOTE: IOPMP defines multiple "models" for different system configurations. +Unless specified differently in the use cases in this specification, system +designers are free to choose any IOPMP model. ==== IOMTT @@ -269,26 +296,32 @@ device-initiated transactions, complementing MTT rules. | ID# | Requirement -| CAT_NNN +| SR_IOM_001 | A system which supports MTT MUST implement IOMTT for access-control for device-initiated memory accesses. -| CAT_NNN +| SR_IOM_002 | IOMTT configurations MUST only be directly accessible to machine mode. -| CAT_NNN +| SR_IOM_003 | A system which implements IOMTT MAY also implement IOPMP to access-control device-initiated access to M-mode memory. |=== -NOTE: IOMTT can also be sufficient for protecting Root devices in the sense that M-mode can enforce that its own resources are never assigned to another domain. Use of IOPMP or similar still adds further protections. For example, a system may require that Root devices are not able to access memory assigned to TEE domain. +NOTE: IOMTT can also be sufficient for protecting Root devices in the sense that +M-mode can enforce that its own resources are never assigned to another domain. +Use of IOPMP or similar still adds further protections. For example, a system +may require that Root devices are not able to access memory assigned to TEE +domain. ==== IOMMU https://github.com/riscv-non-isa/riscv-iommu -IOMMU is a system level component performing memory address translation from IO Virtual Address to Physical Address, allowing devices to access virtual memory locations. It complements MMU configurations. +IOMMU is a system level component performing memory address translation from IO +Virtual Address to Physical Address, allowing devices to access virtual memory +locations. It complements MMU configurations. [width=100%] [%header, cols="5,20"] @@ -296,10 +329,10 @@ IOMMU is a system level component performing memory address translation from IO | ID# | Requirement -| CAT_NNN +| SR_IOM_004 | Systems supporting MMU SHOULD also support IOMMU -| CAT_NNN +| SR_IOM_005 | Systems supporting IOMMU MUST also enforce physical memory access control for M-mode memory against device-initiated transactions (IOMTT or IOPMP). @@ -373,11 +406,11 @@ recommendations and references. | ID# | Requirement -| CAT_NNN +| SR_CPT_001 | RISC-V systems SHOULD support either scalar or vector cryptographic ISA extensions -| CAT_NNN +| SR_CPT_002 | The entropy source ISA extension MUST be supported if either scalar or vector cryptographic ISA extensions are supported. diff --git a/specification/src/chapter4.adoc b/specification/src/chapter4.adoc index 34a0017..f2b4c31 100644 --- a/specification/src/chapter4.adoc +++ b/specification/src/chapter4.adoc @@ -2,14 +2,14 @@ == Use case examples -This chapter provides a selection of example uses cases based on commonly used deployment models. -These use cases are not intended to be exhaustive, or to act as protection profiles. -They are intended as templates which can be used as general guidelines, which can be applied to a wide -variety of use cases. +This chapter provides a selection of example uses cases based on commonly used +deployment models. These use cases are not intended to be exhaustive, or to act +as protection profiles. They are intended as templates which can be used as +general guidelines, which can be applied to a wide variety of use cases. -The examples may be extended over time as required. Protection profiles for more -specific use cases are expected to be provided within relevant certification bodies, -or as separate RISC-V specifications if required. +The examples may be extended over time as required. Protection profiles for more +specific use cases are expected to be provided within relevant certification +bodies,or as separate RISC-V specifications if required. === Generic system without supervisor domains @@ -19,39 +19,65 @@ or as separate RISC-V specifications if required. [title= "Generic vertically integrated system"] image::img_ch4_priv.png[] -A generic vertically integrated system can be either virtualized or non-virtualized. +A generic vertically integrated system can be either virtualized or +non-virtualized. -M-mode hosts a FW RoT. An OS or a Hypervisor in S or HS mode controls applications or guests. Guests and applications execute in U or VS/VU modes and trust the OS or Hypervisor to provide isolation guarantees. +M-mode hosts a FW RoT. An OS or a Hypervisor in S or HS mode controls +applications or guests. Guests and applications execute in U or VS/VU modes and +trust the OS or Hypervisor to provide isolation guarantees. A system level HW RoT is recommended. -NOTE: The RISC-V architecture also caters for systems with just M and U modes, commonly used in embedded systems, helper cores, and similar use cases. On secure systems not supporting S mode a FW RoT has to share M-mode with an OS. RISC-V does not exclude such implementations - for example, implementations using a certified OS and FW RoT, or using a HW RoT to isolate sensitive code and assets (physical isolation). There is no current mechanism in RISC-V for isolation within M-mode itself other than temporal boundaries + +NOTE: The RISC-V architecture also caters for systems with just M and U modes, +commonly used in embedded systems, helper cores, and similar use cases. On +secure systems not supporting S mode a FW RoT has to share M-mode with an OS. +RISC-V does not exclude such implementations - for example, implementations +using a certified OS and FW RoT, or using a HW RoT to isolate sensitive code +and assets (physical isolation). There is no current mechanism in RISC-V for +isolation within M-mode itself other than temporal boundaries + + -To minimize the TCB of the FW RoT RISC-V recommends that secure systems implement S mode, and de-privilege non-RoT firmware such as an OS. +To minimize the TCB of the FW RoT RISC-V recommends that secure systems +implement S mode, and de-privilege non-RoT firmware such as an OS or +non-security services. ==== Isolation model [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_GEN_001 | PMP/ePMP, or MTT, MUST be used to isolate M-mode from lower privilege levels. -| CAT_NNN -| sPMP or MMU MUST be used to isolate user applications or virtual guests +| SR_GEN_002 +| if Sv is not supported, sPMP SHOULD be used to protect Supervisor domain +S-mode from lower privilege levels. + +| SR_GEN_003 +| if Sv is supported 1st-stage and/or G-stage page tables MUST used to protect +Supervisor domain H/S-mode from lower privilege levels. |=== -NOTE: MTT can be sufficient for protecting Root domain in the sense that M-mode can enforce that its own resources are never assigned to another domain. PMP/ePMP still add further protections for M-mode, such as the ability to implement temporal isolation boundaries within M-mode (for example, protect early boot code), or to prevent itself from accessing or executing from memory assigned to lower privilege levels (privilege escalation). +NOTE: MTT can be sufficient for protecting Root domain in the sense that M-mode +can enforce that its own resources are never assigned to another domain. +PMP/ePMP still add further protections for M-mode, such as the ability to +implement temporal isolation boundaries within M-mode (for example, protect +early boot code), or to prevent itself from accessing or executing from memory +assigned to lower privilege levels (privilege escalation). -Using sPMP is typically a more static model and can achieve a more deterministic system, for example in automotive or automation use cases. +Using sPMP is typically a more static model and can achieve a more +deterministic system, for example in automotive or automation use cases. -MMU is typically required for Linux based systems, for example MMI use cases or edge devices. +MMU is typically required for Linux based systems, for example MMI use cases or +edge devices. -Either MMU and sPMP can be used both with or without hypervisor extension. For example, the hypervisor extension with sPMP can support static partition hypervisors, commonly used in automotive. And a single stage MMU can be used without hypervisor extension for full Linux support. +Either MMU and sPMP can be used both with or without hypervisor extension. For +example, the hypervisor extension with sPMP can support static partition +hypervisors, commonly used in automotive. And a single stage MMU can be used +without hypervisor extension for full Linux support. ==== Root of Trust @@ -60,57 +86,71 @@ See xref:chapter2.adoc#_reference_model[reference model]. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_GEN_004 | A secure system SHOULD implement a HW RoT |=== ==== Authorized Boot -Multiple models can be used to ensure a secure system can only run authorized software. +Multiple models can be used to ensure a secure system can only run authorized +software. See xref:chapter2.adoc#_authorized_software[authorized software]. ==== Attestation -Multiple models can be used to prove to a relying party that a secure system is in a trustworthy state. +Multiple models can be used to prove to a relying party that a secure system is +in a trustworthy state. See xref:chapter2.adoc#_attestable_services[attestable services]. ==== Sealing -Multiple models can be used to protect assets if a system is not in a trustworthy state. +Multiple models can be used to protect assets if a system is not in a +trustworthy state. See xref:chapter2.adoc#_sealing[sealing]. ==== Device access control -For the purpose of this specification, a device can be a logical device. A physical device can present one or more logical devices, each with its own (logical) control interface. +For the purpose of this specification, a device can be a logical device. A +physical device can present one or more logical devices, each with its own +(logical) control interface. -Isolation guarantees provided to software also apply to device initiated transaction. +Isolation guarantees provided to software also apply to device initiated +transaction. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT NNN -| IOPMP or IOMTT MUST be used to guarantee that devices assigned to lower privilege levels cannot access resources assigned to M-mode. +| SR_GEN_005 +| IOPMP or IOMTT MUST be used to guarantee that devices assigned to lower +privilege levels cannot access resources assigned to M-mode. -| CAT_NNN -| IOPMP, or IOMTT with IOMMU, MUST be used to enforce access rules for devices assigned to user applications or guests on a virtualized system. +| SR_GEN_006 +| IOPMP, or IOMTT with IOMMU, MUST be used to enforce access rules for devices +assigned to user applications or guests on a virtualized system. |=== -On a non-virtualized system, user devices can be managed by the OS which can enforce access rules for user applications. +On a non-virtualized system, user devices can be managed by the OS which can +enforce access rules for user applications. -On a virtualized system, devices can be virtualized and assigned to guests by the hypervisor configuring MMU and IOMMU translation rules. +On a virtualized system, devices can be virtualized and assigned to guests by +the hypervisor configuring MMU and IOMMU translation rules. -NOTE: IOMTT can also be sufficient for protecting Root devices in the sense that M-mode can enforce that its own resources are never assigned to another domain. Use of IOPMP or similar may still add further protections. For example, a system may require that Root devices cannot access memory assigned to Confidential domain. +NOTE: IOMTT can also be sufficient for protecting Root devices in the sense that +M-mode can enforce that its own resources are never assigned to another domain. +Use of IOPMP or similar may still add further protections. For example, a system +may require that Root devices cannot access memory assigned to Confidential +domain. === Debug and performance management @@ -120,62 +160,69 @@ See https://github.com/riscv-non-isa/riscv-external-debug-security[enhanced RISC [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT NNN -| External debug SHOULD be enabled separately for M-mode and non M-mode software. - -| CAT_NNN -| External debug MUST only be enabled by HW RoT (M-mode external debug) or by FW RoT (non M-mode external debug). +| SR_GEN_007 +| External debug MUST only be enabled by HW RoT (M-mode external debug) or by FW +RoT (non M-mode external debug). +| SR_GEN_008 +| External debug SHOULD be enabled separately for M-mode & non-M-mode software. |=== -Enables recoverable external debug of non M-mode software. In turn enabling supply chain separation. +Enables recoverable external debug of non M-mode software. In turn enabling +supply chain separation. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_GEN_009 | Self-hosted debug MAY be used for debug of non M-mode software. -| CAT_NNN +| SR_GEN_010 | Self-hosted debug MUST only be enabled by a higher privileged component. |=== -For example, within normal domain an S-mode OS can enable self-hosted debug for a user application. Only M-mode firmware should enable self-hosted debug for the S-mode OS. +For example, within normal domain an S-mode OS can enable self-hosted debug for +a user application. Only M-mode firmware should enable self-hosted debug for the +S-mode OS. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_GEN_011 | FW RoT MAY disable self-hosted debug for all non M-mode software. |=== -For example, disable self-hosted debug in a production system for certification reasons. +For example, disable self-hosted debug in a production system for certification +reasons. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN -| External debug MUST only be enabled following system reset (part of measuring) of the affected component. +| SR_GEN_012 +| External debug MUST only be enabled following system reset (part of measuring) +of the affected component, moderated by a RoT. -| CAT_NNN -| Revealing self-hosted debug MUST only be enabled following reboot (part of measuring) of the affected component. +| SR_GEN_013 +| Revealing self-hosted debug MUST only be enabled following reboot (part of +measuring) of the affected component. -| CAT_NNN -| Trusted self-hosted debug MAY be enabled at runtime (after measuring) of the affected component, to an application specific governance process. +| SR_GEN_014 +| Trusted self-hosted debug MAY be enabled at runtime (after measuring) of the +affected component, to an application specific governance process. |=== @@ -187,16 +234,20 @@ Guarantees the system remains attestable. | ID# | Requirement -| CAT_NNN -| Lower privilege software MUST NOT be able to monitor higher privilege software. +| SR_GEN_015 +| Lower privileged software MUST NOT be able to monitor higher privileged +software. -| CAT_NNN -| Software in one domain MUST NOT be able to monitor software in a different domain, without consent. +| SR_GEN_016 +| Software in one domain MUST NOT be able to monitor software in a different +domain, without consent. |=== -Prevents using event counters to monitor across application or privilege boundaries. Event counters can be managed by higher privileged software as part of context switching across boundaries. - +Prevents using event counters to monitor across application or privilege +boundaries. Event counters can be managed by higher privileged software as part +of context switching across boundaries. + === Global Platform TEE ==== Overview @@ -205,9 +256,12 @@ Prevents using event counters to monitor across application or privilege boundar [title= "Global platform TEE use cases"] image::img_ch4_gp-tee.png[] -https://globalplatform.org/[Global platform] defines technical standards, interface specifications and programming models, open source firmware, and certification programmes for _trusted execution environments (TEE)_. +https://globalplatform.org/[Global platform] defines technical standards, +interface specifications and programming models, open source firmware, and +certification programmes for _trusted execution environments (TEE)_. -A TEE is an isolated environment providing security services. TEE services can be available to software on multiple Harts. For example: +A TEE is an isolated environment providing security services. TEE services can +be available to software on multiple Harts. For example: * Payment clients * DRM clients and content protection @@ -218,26 +272,38 @@ A TEE is an isolated environment providing security services. TEE services can b The TEE model divides software into physically isolated domains: * Normal domain + -Typically hosting a _rich OS_ (for example, RTOS or Linux), and user applications. +Typically hosting a _rich OS_ (for example, RTOS or Linux), and user +applications. * TEE domain + -Hosts a _TEE OS_ (domain security manager) and _trusted applications (TA)_. +Hosts a _TEE OS_ (domain security manager) and _trusted applications (TA)_. * Root domain + Hosts RoT firmware, including a secure monitor. -The TEE OS is primarily responsible for isolation of TA, and for providing root of trust services, within the TEE domain. +The TEE OS is primarily responsible for isolation of TA, and for providing root +of trust services, within the TEE domain. -The OS in Normal domain typically controls scheduling on the system, across all Harts available to it. To interact with TA services in TEE domain, the OS in Normal domain interacts with a TEE OS through a secure monitor in Root domain. +The OS in Normal domain typically controls scheduling on the system, across all +Harts available to it. To interact with TA services in TEE domain, the OS in +Normal domain interacts with a TEE OS through a secure monitor in Root domain. -The secure monitor is responsible for context switching and isolation across domain boundaries, including event management. +The secure monitor is responsible for context switching and isolation across +domain boundaries, including event management. -For the purpose of this specification, TEE deployment models can be separated as: +For the purpose of this specification, TEE deployment models can be separated +as: * Static partition TEE + -A single TEE provides security services to Normal domain. TA are typically installed at boot by RoT FW and TEE OS, though Global Platform does also define protocols for installation of TA at runtime. System configuration and resource allocation can be mostly static, making the system more deterministic. + +A single TEE provides security services to Normal domain. TA are typically +installed at boot by RoT FW and TEE OS, though Global Platform does also define +protocols for installation of TA at runtime. System configuration and resource +allocation can be mostly static, making the system more deterministic. + + -_Use case examples:_ edge devices and IoT, automation, and automotive. +_Use case examples:_ edge devices and IoT, automation, and automotive. * Virtualized TEE + -On a virtualized system, TEE can also be virtualized. In this case a _secure partition manager_ in TEE domain is responsible for isolation of multiple TEE guests (for example, an OEM TEE and separate third party TEE). This model can also support more dynamic resource allocation. + +On a virtualized system, TEE can also be virtualized. In this case a _secure +partition manager_ in TEE domain is responsible for isolation of multiple TEE +guests (for example, an OEM TEE and separate third party TEE). This model can +also support more dynamic resource allocation. + + _Use case examples:_ mobile clients, and automotive. @@ -248,77 +314,98 @@ A Global Platform TEE requires the following isolation guarantees: [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN -| Root domain MAY access resources assigned to any domain, but SHOULD prevent itself from unintended access to resources assigned to a different domain (privilege escalation). +| SR_TEE_001 +| Root domain MAY access resources assigned to any domain, but SHOULD prevent +itself from unintended access to resources assigned to a different domain +(privilege escalation). -| CAT_NNN +| SR_TEE_002 | No other domains can access resources assigned to Root domain -| CAT_NNN +| SR_TEE_003 | Resources assigned to TEE domain MUST NOT be accessible to Normal domain -| CAT_NNN -| Resources assigned to Normal domain MUST be accessible to Normal domain (r/w/x), and to TEE domain (r/w) (default sharing rule) +| SR_TEE_004 +| Resources assigned to Normal domain MUST be accessible to Normal domain +(r/w/x), and to TEE domain (r/w) (default sharing rule) -| CAT_NNN -| Resources assigned to a single TA, or a guest TEE, MUST not be accessible by a different TA, or guest TEE, without consent. +| SR_TEE_005 +| Resources assigned to a single TA, or a guest TEE, MUST not be accessible by a +different TA, or guest TEE, without consent. |=== -In the standard GP TEE model, each TA is expected to be a self-contained unit providing a specific security service, either to Normal domain or to other TA. All communications are implemented through secure channels managed by the TEE OS or SPM. +In the standard GP TEE model, each TA is expected to be a self-contained unit +providing a specific security service, either to Normal domain or to other TA. +All communications are implemented through secure channels managed by the TEE OS +or SPM. -Sharing of memory between TA is generally discouraged. But there are mechanisms to do so in specific use cases. For example, sharing media buffers in a secure media path. Such policies are enforced by SPM or TEE OS. +Sharing of memory between TA is generally discouraged. But there are mechanisms +to do so in specific use cases. For example, sharing media buffers in a secure +media path. Such policies are enforced by SPM or TEE OS. -Processes in Normal domain can share memory assigned to Normal domain when interacting with a TA in TEE world (default sharing rule). Such shared memory can be cached when context switching between Normal and TEE domains. +Processes in Normal domain can share memory assigned to Normal domain when +interacting with a TA in TEE world (default sharing rule). Such shared memory +can be cached when context switching between Normal and TEE domains. -RISC-V hardware enforced isolation mechanisms can be used as follows to meet those guarantees: +RISC-V hardware enforced isolation mechanisms can be used as follows to meet +those guarantees: [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_TEE_006 | PMP/ePMP, or MTT, MUST be used to isolate Root domain from other domains. -| CAT_NNN -| Supervisor domains MUST be used to enforce isolation between Normal and TEE domains. +| SR_TEE_007 +| Supervisor domains MUST be used to enforce isolation between Normal and TEE +domains. |=== See xref:chapter3.adoc#_supervisor_domains[supervisor domains]. -For static partition TEE, using PMP/ePMP, with supervisor domains can be sufficient. +For static partition TEE, using PMP/ePMP, with supervisor domains can be +sufficient. For virtualized TEE, MTT should be used with supervisor domains. -NOTE: MTT can be sufficient for protecting Root domain in the sense that M-mode can enforce that its own resources are never assigned to another domain. PMP/ePMP still add further protections for M-mode, such as the ability to implement temporal isolation boundaries within M-mode (for example, protect early boot code), or to prevent itself from accessing or executing from memory assigned to lower privilege levels (privilege escalation). +NOTE: MTT can be sufficient for protecting Root domain in the sense that M-mode +can enforce that its own resources are never assigned to another domain. +PMP/ePMP still add further protections for M-mode, such as the ability to +implement temporal isolation boundaries within M-mode (for example, protect +early boot code), or to prevent itself from accessing or executing from memory +assigned to lower privilege levels (privilege escalation). [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN -| For a static partition TEE, sPMP or MMU MUST be used to enforce isolation between TA in TEE domain. +| SR_TEE_008 +| For a static partition TEE, sPMP or MMU MUST be used to enforce isolation +between TA in TEE domain. |=== [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_TEE_009 | For a virtualized TEE, hypervisor extension MUST be supported -| CAT_NNN -| For a virtualized TEE, MMU MUST be used to enforce isolation between guest TEE, and between TA within a TEE. +| SR_TEE_010 +| For a virtualized TEE, MMU MUST be used to enforce isolation between guest +TEE, and between TA within a TEE. |=== ==== Root of Trust @@ -328,10 +415,10 @@ See xref:chapter2.adoc#_reference_model[reference model]. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_TEE_011 | A TEE based system SHOULD implement a HW RoT |=== @@ -345,22 +432,23 @@ TEE boot is typically based on: * Measured and verified local boot (direct or indirect) * Sealing, to protect TEE production assets -The process can involve multiple stages (layered boot). +The process can involve multiple stages (layered boot). ==== Attestation See xref:chapter2.adoc#_attestable_services[attestable services]. -Static partition TEE attestation is typically based on a direct security platform attestation. +Static partition TEE attestation is typically based on a direct security +platform attestation. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN -a| A direct security platform attestation MUST cover at least: +| SR_TEE_012 +a| A direct security platform attestation MUST cover at least: * TEE domain * Root domain @@ -368,30 +456,37 @@ a| A direct security platform attestation MUST cover at least: |=== -Virtualized TEE attestation can be layered, for performance or separation of concern. For example: +Virtualized TEE attestation can be layered, for performance or separation of +concern. For example: -* A security platform attestation, signed by a RoT, covering trusted subsystems, Root domain, and SPM -* Separate guest TEE attestation(s) signed by SPM +* A security platform attestation, signed by a RoT, covering trusted subsystems, +Root domain, and SPM +* Separate guest TEE attestation(s) signed by SPM ==== Sealing See xref:chapter2.adoc#_sealing[sealing]. -In the Global Platform security model, SPM or TEE OS typically provide local trusted storage, key management, and cryptographic services to TA and guest TEE. These services support local sealing of TA or guest TEE assets, and minimize exposure of cryptographic materials. +In the Global Platform security model, SPM or TEE OS typically provide local +trusted storage, key management, and cryptographic services to TA and guest TEE. +These services support local sealing of TA or guest TEE assets, and minimize +exposure of cryptographic materials. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN -| Local sealing for a TA, or a TEE guest, MUST be unique to TEE domain and to a physical instance of a system. +| SR_TEE_013 +| Local sealing for a TA, or a TEE guest, MUST be unique to TEE domain and to a +physical instance of a system. -| CAT_NNN -| Local sealing for a TA, or a TEE guest, SHOULD also be unique to the TEE guest or the TA. +| SR_TEE_014 +| Local sealing for a TA, or a TEE guest, SHOULD also be unique to the TEE guest +or the TA. -| CAT_NNN +| SR_TEE_015 | Local sealing MAY be layered. |=== @@ -399,39 +494,61 @@ In the Global Platform security model, SPM or TEE OS typically provide local tru For example: * TEE domain unique sealing keys derived by a RoT from a hardware unique key -* TA, or guest TEE, unique sealing keys derived by TEE OS or SPM from a TEE domain unique sealing key +* TA, or guest TEE, unique sealing keys derived by TEE OS or SPM from a TEE +domain unique sealing key ==== Device access control -For the purpose of this specification, a device can be a logical device. A physical device can present one or more logical devices, each with its own (logical) control interface. +For the purpose of this specification, a device can be a logical device. A +physical device can present one or more logical devices, each with its own +(logical) control interface. -The security guarantees also apply to device initiated accesses, for example DMA and interrupts. +The security guarantees also apply to device initiated accesses, for example DMA +and interrupts. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_TEE_016 | A static partition TEE MUST use IOPMP to enforce access rules for devices. -| CAT_NNN -| A virtualized TEE MUST use IOMTT and IOMMU to enforce access rules for devices assigned to Normal or TEE domains, and SHOULD use IOPMP to enforce access rules for Root devices. +| SR_TEE_017 +| A virtualized TEE MUST use IOMTT and IOMMU to enforce access rules for devices +assigned to Normal or TEE domains, and SHOULD use IOPMP to enforce access rules +for Root devices. |=== -For a static partition TEE, domain level granularity can be sufficient as device access within TEE and Normal domains is governed by TEE OS and the rich OS respectively. It can be implemented using IOPMP. Policy can be controlled by boot configuration, by a HW or FW RoT. +For a static partition TEE, domain level granularity can be sufficient as device +access within TEE and Normal domains is governed by TEE OS and the rich OS +respectively. It can be implemented using IOPMP. Policy can be controlled by +boot configuration, by a HW or FW RoT. -For a virtualized TEE, IOMTT enforces supervisor domain level access rules (physical isolation). IOMMU enforces guest and TA level access rules (virtualization), supporting device assignment to a guest TEE or a TA. +For a virtualized TEE, IOMTT enforces supervisor domain level access rules +(physical isolation). IOMMU enforces guest and TA level access rules +(virtualization), supporting device assignment to a guest TEE or a TA. -NOTE: IOMTT can also be sufficient for protecting Root devices in the sense that M-mode can enforce that its own resources are never assigned to another domain. Use of IOPMP or similar may still add further protections. For example, a system may require that Root devices cannot be used to access memory assigned to Confidential domain. +NOTE: IOMTT can also be sufficient for protecting Root devices in the sense that +M-mode can enforce that its own resources are never assigned to another domain. +Use of IOPMP or similar may still add further protections. For example, a system +may require that Root devices cannot be used to access memory assigned to +Confidential domain. ==== System integration -In the case of a Global Platform TEE system a rich OS in Normal domain is free to schedule services, including TEE services, on any Hart available to it. The number and make-up of supervisor domains can be known, and a simple convention can be used for common identification (SDID value, see xref:chapter3.adoc#_supervisor_domains[supervisor domains]) of Normal, TEE, and Root domains across multiple Harts in a system. +In the case of a Global Platform TEE system a rich OS in Normal domain is free +to schedule services, including TEE services, on any Hart available to it. The +number and make-up of supervisor domains can be known, and a simple convention +can be used for common identification (SDID value, see +xref:chapter3.adoc#_supervisor_domains[supervisor domains]) of Normal, TEE, and +Root domains across multiple Harts in a system. -System integration in this context involves providing _security attributes_ on a system interconnect, tagging all transactions (CPU or system agent initiated) to either Root, Normal, or TEE domains. +System integration in this context involves providing _security attributes_ on +a system interconnect, tagging all transactions (CPU or system agent initiated) +to either Root, Normal, or TEE domains. Possible use cases include: @@ -439,9 +556,12 @@ Possible use cases include: * Tagging interrupts, debug accesses, or coherent memory accesses * Device assignment (IOPMP/IOMTT integration), static or dynamic -The attributes can be derived, for example, from SDID and privilege level, from PMA, or from dynamic meta-data during Sv address translation (MTT svpam). +The attributes can be derived, for example, from SDID and privilege level, from +PMA, or from dynamic meta-data during Sv address translation (MTT svpam). -For some use cases security attributes can be extended to reflect finer granularity, for example for cryptographic memory protection with TA granularity. +For some use cases security attributes can be extended to reflect finer +granularity, for example for cryptographic memory protection with TA +granularity. === Debug and performance management @@ -451,67 +571,78 @@ See https://github.com/riscv-non-isa/riscv-external-debug-security[enhanced RISC [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_TEE_018 | External debug MUST be enabled separately for Root domain. -| CAT_NNN +| SR_TEE_019 | External debug MUST be enabled separately for each supervisor domain. -| CAT_NNN -| External debug MUST only be enabled by a HW RoT (Root domain external debug) or by Root domain (supervisor domain external debug). +| SR_TEE_020 +| External debug MUST only be enabled by a HW RoT (Root domain external debug) +or by Root domain (supervisor domain external debug). |=== -Enables recoverable external debug of a supervisor domain separately from other supervisor domains, and Root domain. In turn enabling supply chain separation. +Enables recoverable external debug of a supervisor domain separately from other +supervisor domains, and Root domain. In turn enabling supply chain separation. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_TEE_021 | Self-hosted debug MAY be used for debug within a supervisor domain. -| CAT_NNN +| SR_TEE_022 | Self-hosted debug MUST only be enabled by a higher privileged component. |=== -For example, within normal domain an S-mode or VS-mode OS can enable self-hosted debug for a user application. Or an HS-mode hypervisor can enable self-hosted debug for a VS-mode guest. Only Root domain should enable self-hosted debug for an S-mode OS or an HS mode hypervisor. +For example, within normal domain an S-mode or VS-mode OS can enable +self-hosted debug for a user application. Or an HS-mode hypervisor can enable +self-hosted debug for a VS-mode guest. Only Root domain should enable +self-hosted debug for an S-mode OS or an HS mode hypervisor. -Within TEE domain a TEE OS can enable self-hosted debug for a TA. An SPM can enable self-hosted debug for guest TEE. Only Root domain should enable self-hosted debug of SPM (virtualized) or TEE OS (non-virtualized). +Within TEE domain a TEE OS can enable self-hosted debug for a TA. An SPM can +enable self-hosted debug for guest TEE. Only Root domain should enable +self-hosted debug of SPM (virtualized) or TEE OS (non-virtualized). [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_TEE_023 | Root domain MAY disable self-hosted debug for a whole domain. |=== -For example, for all of TEE domain on a production system, for certification reasons. +For example, for all of TEE domain on a production system, for certification +reasons. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN -| External debug MUST only be enabled following system reset (part of measuring) of the affected component. +| SR_TEE_024 +| External debug MUST only be enabled following system reset (part of measuring) +of the affected component. -| CAT_NNN -| Revealing self-hosted debug MUST only be enabled following reboot (part of measuring) of the affected component. +| SR_TEE_025 +| Revealing self-hosted debug MUST only be enabled following reboot (part of +measuring) of the affected component. -| CAT_NNN -| Trusted self-hosted debug MAY be enabled at runtime (after measuring) of the affected component, to an application specific governance process. +| SR_TEE_026 +| Trusted self-hosted debug MAY be enabled at runtime (after measuring) of the +affected component, to an application specific governance process. |=== @@ -523,15 +654,19 @@ Guarantees the system remains attestable. | ID# | Requirement -| CAT_NNN -| Lower privilege software MUST NOT be able to monitor higher privilege software. +| SR_TEE_027 +| Lower privileged software MUST NOT be able to monitor higher privileged +software. -| CAT_NNN -| Software in one domain MUST NOT be able to monitor software in a different domain, without consent. +| SR_TEE_028 +| Software in one domain MUST NOT be able to monitor software in a different +domain, without consent. |=== -Prevents using event counters to monitor across guest/application, privilege and supervisor domain boundaries. Event counters can be managed by higher privileged software as part of context switching across boundaries. +Prevents using event counters to monitor across guest/application, privilege +and supervisor domain boundaries. Event counters can be managed by higher +privileged software as part of context switching across boundaries. === Confidential computing on RISC-V (CoVE) ==== Overview @@ -539,28 +674,48 @@ Prevents using event counters to monitor across guest/application, privilege and [title= "Confidential compute use case"] image::img_ch4_cove.png[] -In hosting environments, tenant workloads rely on isolation primitives that are managed by host privileged software. This can lead to a large TCB for tenants which could include, for example, a hypervisor, orchestration services, and host management services. It could also include other tenants exploiting vulnerabilities in complex hosting software. - -Confidential compute aims to achieve a minimal and certifiable TCB for _confidential workloads_. - -_CoVE (Confidential VM Extensions)_ https://github.com/riscv-non-isa/riscv-ap-tee/tree/main/specification[specification] defines a confidential compute platform for RISC-V systems, including interfaces and programming models, covering lifecycle management, attestation, resource management and devices assignment, for confidential workloads. It is based on principles defined by https://confidentialcomputing.io/[Confidential Computing Consortium]. Reference firmware for CoVE is being developed as part of the https://riseproject.dev/[RISC-V Software Ecosystem] project. - -CoVE is primarily aimed at cloud hosting of confidential workloads. But the underlying isolation model could potentially be used in other use cases, such as some mobile clients or edge devices. +In hosting environments, tenant workloads rely on isolation primitives that are +managed by host privileged software. This can lead to a large TCB for tenants +which could include, for example, a hypervisor, orchestration services, and +host management services. It could also include other tenants exploiting +vulnerabilities in complex hosting software. + +Confidential compute aims to achieve a minimal and certifiable TCB for +_confidential workloads_. + +_CoVE (Confidential VM Extensions)_ +https://github.com/riscv-non-isa/riscv-ap-tee/tree/main/specification[specification] +defines a confidential compute platform for RISC-V systems, including +interfaces and programming models, covering lifecycle management, attestation, +resource management and devices assignment, for confidential workloads. It is +based on principles defined by +https://confidentialcomputing.io/[Confidential Computing Consortium]. +Reference firmware for CoVE is being developed as part of the +https://riseproject.dev/[RISC-V Software Ecosystem] project. + +CoVE is primarily aimed at cloud hosting of confidential workloads. But the +underlying isolation model could potentially be used in other use cases, such +as some mobile clients or edge devices. CoVE divides software into physically isolated domains: * Normal domain + -Typically hosting a hypervisor, and Normal guests and services. +Typically hosting a hypervisor, and Normal guests and services. * Confidential domain + Hosts a _TSM_ (domain security manager) and confidential guests. * Root domain + Hosts RoT firmware, including a secure monitor. -The TSM is primarily responsible for isolation of confidential workloads, and for providing RoT services, within the Confidential domain. +The TSM is primarily responsible for isolation of confidential workloads, and +for providing RoT services, within the Confidential domain. -A hypervisor in Normal domain typically controls scheduling and resource assignment on the system across all Harts available to it, including for confidential workloads. It interacts with the TSM through the secure monitor in Root domain to manage confidential workloads. +A hypervisor in Normal domain typically controls scheduling and resource +assignment on the system across all Harts available to it, including for +confidential workloads. It interacts with the TSM through the secure monitor in +Root domain to manage confidential workloads. -The secure monitor is responsible for context switching and isolation across domain boundaries, including event management. +The secure monitor is responsible for context switching and isolation across +domain boundaries, including event management. ==== Isolation model @@ -569,63 +724,78 @@ Confidential workloads are provided the following isolation guarantees: [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN -| Root domain MAY access resources assigned to any domain, but SHOULD prevent itself from unintended access to resources assigned to a different domain (privilege escalation). +| SR_CFC_001 +| Root domain MAY access resources assigned to any domain, but SHOULD prevent +itself from unintended access to resources assigned to a different domain +(privilege escalation). -| CAT_NNN +| SR_CFC_002 | Resources assigned to Root domain MUST be private to Root domain -| CAT_NNN -| Resources assigned only to Confidential domain MUST not be accessible by Normal domain +| SR_CFC_003 +| Resources assigned only to Confidential domain MUST not be accessible by +Normal domain -| CAT_NNN -| Resources assigned only to Normal domain MUST not be accessible by Confidential domain +| SR_CFC_004 +| Resources assigned only to Normal domain MUST not be accessible by +Confidential domain -| CAT_NNN -| Resources MAY be assigned to both Normal and Confidential domains (sharing by consent). +| SR_CFC_005 +| Resources MAY be assigned to both Normal and Confidential domains (sharing by +consent). -| CAT_NNN -| Resources assigned to a single confidential workload MUST NOT be accessible by any other confidential workload +| SR_CFC_006 +| Resources assigned to a single confidential workload MUST NOT be accessible +by any other confidential workload -| CAT_NNN -| Resources MAY be assigned to multiple confidential workloads (sharing by consent) +| SR_CFC_007 +| Resources MAY be assigned to multiple confidential workloads (sharing by +consent) |=== -RISC-V hardware enforced isolation mechanisms can be used as follows to meet those guarantees: +RISC-V hardware enforced isolation mechanisms can be used as follows to meet +those guarantees: [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_CFC_008 | PMP/ePMP or MTT MUST be used to isolate Root domain from other domains. -| CAT_NNN -| Supervisor domains MUST be used to enforce isolation between Normal and Confidential domains. +| SR_CFC_009 +| Supervisor domains MUST be used to enforce isolation between Normal and +Confidential domains. |=== See xref:chapter3.adoc#_supervisor_domains[supervisor domains]. -NOTE: MTT can be sufficient for protecting Root domain in the sense that M-mode can enforce that its own resources are never assigned to another domain. PMP/ePMP still add further protections for M-mode, such as the ability to implement temporal isolation boundaries within M-mode (for example, protect early boot code), or to prevent itself from accessing or executing from memory assigned to lower privilege levels (privilege escalation). +NOTE: MTT can be sufficient for protecting Root domain in the sense that M-mode +can enforce that its own resources are never assigned to another domain. +PMP/ePMP still add further protections for M-mode, such as the ability to +implement temporal isolation boundaries within M-mode (for example, protect +early boot code), or to prevent itself from accessing or executing from memory +assigned to lower privilege levels (privilege escalation). [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_CFC_010 | Hypervisor extension MUST be supported -| CAT_NNN -| MMU MUST be used to enforce isolation between Confidential guests within Confidential domain. +| SR_CFC_011 +| MMU MUST be used to enforce isolation between Confidential guests within +Confidential domain. |=== ==== Root of trust @@ -635,10 +805,10 @@ See xref:chapter2.adoc#_reference_model[reference model]. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_CFC_012 | A CoVE system MUST implement a HW RoT |=== @@ -650,11 +820,12 @@ See xref:chapter2.adoc#_authorized_software[authorized software]. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN -a| Confidential guests MUST not boot until at least the security platform has been verified: +| SR_CFC_013 +a| Confidential guests MUST not boot until at least the security platform has +been verified: * TSM in Confidential domain * Root domain @@ -664,28 +835,33 @@ a| Confidential guests MUST not boot until at least the security platform has be Boot in a cloud hosting context is typically based on: * Measured boot of a hosting platform, including Root domain and TSM -* Platform attestation and security provisioning (unsealing) by a remote provisioning system -* Launch and measurement of confidential workloads, only once the system has been unsealed +* Platform attestation and security provisioning (unsealing) by a remote +provisioning system +* Launch and measurement of confidential workloads, only once the system has +been unsealed A _trusted platform module_ (TPM) can be used to measure the security platform. Measuring confidential guests can be done by TSM in Confidential domain. -The process can involve multiple stages (layered boot). +The process can involve multiple stages (layered boot). ==== Attestation See xref:chapter2.adoc#_attestable_services[attestable services]. -Virtualized TEE attestation can be layered, for performance or separation of concern. For example: +Virtualized TEE attestation can be layered, for performance or separation of +concern. For example: -* A security platform attestation, signed by a RoT, covering trusted subsystems, Root domain, and SPM -* Separate guest TEE attestation(s) signed by SPM +* A security platform attestation, signed by a RoT, covering trusted subsystems, +Root domain, and SPM +* Separate guest TEE attestation(s) signed by SPM See xref:chapter2.adoc#_attestable_services[attestable services]. -Attestation of confidential workloads is typically layered, for performance and separation of concern: +Attestation of confidential workloads is typically layered, for performance and +separation of concern: * A security platform attestation, signed by a hardware root of trust * A confidential workload attestation, signed by TSM @@ -693,11 +869,11 @@ Attestation of confidential workloads is typically layered, for performance and [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN -a| A security platform attestation MUST cover at least: +| SR_CFC_014 +a| A security platform attestation MUST cover at least: * HW RoT * TSM @@ -710,46 +886,67 @@ a| A security platform attestation MUST cover at least: See xref:chapter2.adoc#_sealing[sealing]. -Sealing of confidential workloads is typically based on remote sealing, unsealing assets for a confidential workload following successful attestation by a remote provisioning system. This enables use cases such as: +Sealing of confidential workloads is typically based on remote sealing, +unsealing assets for a confidential workload following successful attestation +by a remote provisioning system. This enables use cases such as: -* Shared assets across multiple instances of a confidential workload (scale or redundancy) +* Shared assets across multiple instances of a confidential workload (scale or +redundancy) * Unsealing different sets of assets for different users of a service -TSM itself is typically stateless across reset and does not require any sealed assets of its own. +TSM itself is typically stateless across reset and does not require any sealed +assets of its own. [#_cove_device_access_control] ==== Device access control -For the purpose of this specification, a device can be a logical device. A physical device can present more than one logical devices, each with its own (logical) control interface. +For the purpose of this specification, a device can be a logical device. A +physical device can present more than one logical devices, each with its own +(logical) control interface. -The security guarantees also apply to device initiated accesses, for example DMA and interrupts. +The security guarantees also apply to device initiated accesses, for example +DMA and interrupts. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN -| IOMTT and IOMMU MUST be used to enforce access rules for devices assigned to Normal or Confidential domains. +| SR_CFC_015 +| IOMTT and IOMMU MUST be used to enforce access rules for devices assigned to +Normal or Confidential domains. -| CAT_NNN +| SR_CFC_016 | IOPMP SHOULD be used to enforce access rules for Root devices. -| CAT_NNN -| IOPMP and IOMTT configurations MUST only be directly accessible by Root domain. +| SR_CFC_017 +| IOPMP and IOMTT configurations MUST only be directly accessible by +Root domain. |=== -IOMTT enforces supervisor domain level access rules (physical isolation). IOMMU enforces guest and TA level access rules (virtualization), supporting device assignment to a Confidential guest. +IOMTT enforces supervisor domain level access rules (physical isolation). +IOMMU enforces guest and TA level access rules (virtualization), supporting +device assignment to a Confidential guest. -NOTE: IOMTT can also be sufficient for protecting Root devices in the sense that M-mode can enforce that its own resources are never assigned to another domain. Use of IOPMP or similar still adds further protections. For example, a system may require that Root devices cannot be used to access memory assigned to Confidential domain. +NOTE: IOMTT can also be sufficient for protecting Root devices in the sense +that M-mode can enforce that its own resources are never assigned to another +domain. Use of IOPMP or similar still adds further protections. For example, +a system may require that Root devices cannot be used to access memory assigned +to Confidential domain. ==== System integration -In the case of a confidential compute system, hypervisor in Normal domain typically controls scheduling and resource assignment on the system across all Harts available to it. The number and make-up of supervisor domains can be known, and a simple convention can be used for common identification of Normal, Confidential, and Root domains across multiple Harts in a system. +In the case of a confidential compute system, hypervisor in Normal domain +typically controls scheduling and resource assignment on the system across all +Harts available to it. The number and make-up of supervisor domains can be +known, and a simple convention can be used for common identification of Normal, +Confidential, and Root domains across multiple Harts in a system. -System integration in this context involves providing _security attributes_ on the interconnect, tagging all transactions (CPU or system agent initiated) to either Root, Normal, or TEE domains. +System integration in this context involves providing _security attributes_ on +the interconnect, tagging all transactions (CPU or system agent initiated) to +either Root, Normal, or TEE domains. Possible use cases include: @@ -757,27 +954,38 @@ Possible use cases include: * Tagging interrupts, debug accesses, or coherent memory accesses * Device assignment (IOPMP/IOMTT integration), static or dynamic -The attributes can be derived, for example, from dynamic meta-data during Sv address translation (MTT Svpam). +The attributes can be derived, for example, from dynamic meta-data during Sv +address translation (MTT Svpam). -For some use cases security attributes can be extended to reflect finer granularity, for example for cryptographic memory protection with confidential workload granularity. +For some use cases security attributes can be extended to reflect finer +granularity, for example for cryptographic memory protection with confidential +workload granularity. ==== Trusted device assignment -The goal of confidential compute is to provide a minimum TCB for a confidential service, and CPU isolation mechanisms discussed so far does that on a Hart. +The goal of confidential compute is to provide a minimum TCB for a confidential +service, and CPU isolation mechanisms discussed so far does that on a Hart. -But most confidential services also make use of devices, both on-chip and external. <<_cove_device_access_control, Device virtualization>> can guarantee exclusivity for devices assigned to a confidential workload - TSM can guarantee that a device assigned to a confidential workload cannot be accessed by: +But most confidential services also make use of devices, both on-chip and +external. <<_cove_device_access_control, Device virtualization>> can guarantee +exclusivity for devices assigned to a confidential workload - TSM can guarantee +that a device assigned to a confidential workload cannot be accessed by: * Any other confidential workload * Any software in Normal domain -But the confidential workload still has to trust all intermediaries between the workload and the device, both physical and software. For example: +But the confidential workload still has to trust all intermediaries between the +workload and the device, both physical and software. For example: * Drivers * Physical interconnects and device hardware interfaces -Secure access to devices is important in a number of use cases where a device performs work on assets owned by a confidential workload, such as accelerators. +Secure access to devices is important in a number of use cases where a device +performs work on assets owned by a confidential workload, such as accelerators. -The _TEE device interface security protocol (TDISP)_ defined by PCIe provides a security architecture and protocols allowing a confidential workload to securely attest, manage and exchange data with a trusted device. +The _TEE device interface security protocol (TDISP)_ defined by PCIe provides a +security architecture and protocols allowing a confidential workload to +securely attest, manage and exchange data with a trusted device. CoVE defines RISC-V support for TDISP. See: @@ -792,54 +1000,62 @@ See https://github.com/riscv-non-isa/riscv-external-debug-security[enhanced RISC [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_CFC_018 | External debug MUST be enabled separately for Root domain. -| CAT_NNN +| SR_CFC_019 | External debug MUST be enabled separately for each supervisor domain. -| CAT_NNN -| External debug MUST only be enabled by a HW RoT (Root domain external debug) or by Root domain (supervisor domain external debug). +| SR_CFC_020 +| External debug MUST only be enabled by a HW RoT (Root domain external debug) +or by Root domain (supervisor domain external debug). |=== -Enables recoverable external debug of a supervisor domain separately from other supervisor domains, and Root domain. In turn enabling supply chain separation. +Enables recoverable external debug of a supervisor domain separately from other +supervisor domains, and Root domain. In turn enabling supply chain separation. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN +| SR_CFC_021 | Self-hosted debug MAY be used for debug within a supervisor domain. -| CAT_NNN +| SR_CFC_022 | Self-hosted debug MUST only be enabled by a higher privileged component. |=== -For example, within normal domain an HS-mode hypervisor can enable self-hosted debug for a VS-mode guest. Only Root domain should enable self-hosted debug for the HS mode hypervisor. +For example, within normal domain an HS-mode hypervisor can enable self-hosted +debug for a VS-mode guest. Only Root domain should enable self-hosted debug for +the HS mode hypervisor. -Within Confidential domain the TSM can enable self-hosted debug for a confidential guest. Only Root domain should enable self-hosted debug of TSM. +Within Confidential domain the TSM can enable self-hosted debug for a +confidential guest. Only Root domain should enable self-hosted debug of TSM. [width=100%] [%header, cols="5,20"] |=== -| ID# +| ID# | Requirement -| CAT_NNN -| External debug MUST only be enabled following system reset (part of measuring) of the affected component. +| SR_CFC_023 +| External debug MUST only be enabled following system reset (part of measuring) +of the affected component. -| CAT_NNN -| Revealing self-hosted debug MUST only be enabled following reboot (part of measuring) of the affected component. +| SR_CFC_024 +| Revealing self-hosted debug MUST only be enabled following reboot (part of +measuring) of the affected component. -| CAT_NNN -| Trusted self-hosted debug MAY be enabled at runtime (after measuring) of the affected component, to an application specific governance process. +| SR_CFC_025 +| Trusted self-hosted debug MAY be enabled at runtime (after measuring) of the +affected component, to an application specific governance process. |=== @@ -851,17 +1067,21 @@ Guarantees the system remains attestable. | ID# | Requirement -| CAT_NNN -| Lower privilege software MUST NOT be able to measure higher privilege software. +| SR_CFC_026 +| Lower privileged software MUST NOT be able to measure higher privileged +software. -| CAT_NNN -| Software in one domain MUST NOT be able to measure software in a different domain, without consent. +| SR_CFC_027 +| Software in one domain MUST NOT be able to measure software in a different +domain, without consent. |=== -Prevents using event counters to measure across guest/application, privilege and supervisor domain boundaries. +Prevents using event counters to measure across guest/application, privilege +and supervisor domain boundaries. -Event counters can be managed by higher privileged software as part of context switching across boundaries. +Event counters can be managed by higher privileged software as part of context +switching across boundaries. ==== Platform QoS @@ -873,12 +1093,14 @@ See xref:chapter2.adoc#_platform_quality_of_service[platform quality of service] | ID# | Requirement -| CAT_NNN +| SR_CFC_028 | Lower privilege software MUST NOT be able to measure higher privilege software. -| CAT_NNN -| Software in one domain MUST NOT be able to measure software in a different domain, without consent. +| SR_CFC_29 +| Software in one domain MUST NOT be able to measure software in a different +domain, without consent. |=== -Event counters can be managed by higher privileged software as part of context switching across boundaries. +Event counters can be managed by higher privileged software as part of context +switching across boundaries. diff --git a/specification/src/chapter5.adoc b/specification/src/chapter5.adoc index 2d8b67c..d1d28a5 100644 --- a/specification/src/chapter5.adoc +++ b/specification/src/chapter5.adoc @@ -2,24 +2,40 @@ == Cryptography -RISC-V supports a number of ISA-level extensions aimed at improving performance for cryptographic operations (scalar and vector). They also include an ISA-level entropy source, and guidelines for data independent execution latency. +RISC-V supports a number of ISA-level extensions aimed at improving performance +for cryptographic operations (scalar and vector). They also include an +ISA-level entropy source, and guidelines for data independent execution latency. See xref:chapter3.adoc#_cryptography[cryptography] + See https://github.com/riscv/riscv-crypto -Current ISA level cryptographic extensions work at round level. With the data independent execution latency properties, they can provide some mitigation against some side-channel attacks, such as cache timing attacks. They may not defend fully against some differential power analysis, for example. +Current ISA level cryptographic extensions work at round level. With the data +independent execution latency properties, they can provide some mitigation +against some side-channel attacks, such as cache timing attacks. They may not +defend fully against some differential power analysis, for example. -Work is on-going to define ISA-level _high assurance cryptography (HAC)_. This work includes defining full-round operations to increase side-channel resistance; adding operations supporting _post-quantum cryptography (PQC)_; and adding ISA-level privilege-based key management. +Work is on-going to define ISA-level _high assurance cryptography (HAC)_. This +work includes defining full-round operations to increase side-channel +resistance; adding operations supporting _post-quantum cryptography (PQC)_; and +adding ISA-level privilege-based key management. -Cryptographic requirements depend on target ecosystem, as well as on varying regulatory requirements in different geographic regions. This chapter summarizes commonly used cryptographic guidance for secure systems, provided as guidance for development of RISC-V specifications and RISC-V based secure systems. +Cryptographic requirements depend on target ecosystem, as well as on varying +regulatory requirements in different geographic regions. This chapter +summarizes commonly used cryptographic guidance for secure systems, provided as +guidance for development of RISC-V specifications and RISC-V based secure +systems. === PQC readiness -Quantum safe cryptography is an evolving area of research. For example, see: https://csrc.nist.gov/projects/post-quantum-cryptography. +Quantum safe cryptography is an evolving area of research. For example, see: +https://csrc.nist.gov/projects/post-quantum-cryptography. -ML-KEM (FIPS-203), ML-DSA (FIPS-204), and SLH-DSA (FIPS-205). ML-KEM defines a key-encapsulation mechanism used to establish a shared secret key over a public channel. ML-DSA and SLH-DSA defined digital signature schemes. +ML-KEM (FIPS-203), ML-DSA (FIPS-204), and SLH-DSA (FIPS-205). ML-KEM defines a +key-encapsulation mechanism used to establish a shared secret key over a public +channel. ML-DSA and SLH-DSA defined digital signature schemes. -RISC-V systems and specifications must at least support a migration path towards use of PQC. +RISC-V systems and specifications must at least support a migration path +towards use of PQC. [width=100%] [%header, cols="5,20"] @@ -27,21 +43,29 @@ RISC-V systems and specifications must at least support a migration path towards | ID# | Requirement -| CAT_NNN -| In applications which require a migration path to PQC algorithms, all immutable components SHOULD support PQC alternatives. +| SR_CPT_003 +| In applications which require a migration path to PQC algorithms, all +immutable components SHOULD support PQC alternatives. -| CAT_NNN -| All mutable components MUST at least have a migration path to quantum safe cryptography. +| SR_CPT_004 +| All mutable components MUST at least have a migration path to quantum safe +cryptography. |=== -Immutable components, in particular immutable boot code, cannot be updated. To provide a full migration path for a system, immutable components need to support PQC alternatives. +Immutable components, in particular immutable boot code, cannot be updated. To +provide a full migration path for a system, immutable components need to +support PQC alternatives. -Mutable stages can be updated, and can provide a migration path to quantum safe cryptography. For example, system designers should consider protocols, governance, and storage requirements for upgrading hardware provisioned assets to PQC versions. +Mutable stages can be updated, and can provide a migration path to quantum safe +cryptography. For example, system designers should consider protocols, +governance, and storage requirements for upgrading hardware provisioned assets +to PQC versions. === Cryptographic algorithms and guidelines -The following resources provide general cryptographic guidance applicable to most western jurisdictions: +The following resources provide general cryptographic guidance applicable to +most western jurisdictions: https://csrc.nist.gov/Projects/Cryptographic-Standards-and-Guidelines https://www.cnss.gov/CNSS/issuances/Memoranda.cfm @@ -52,13 +76,21 @@ In particular, for most new systems: * Block cipher: AES-256 * Hash function: SHA-512, or SHA-3 * Message authentication: HMAC-SHA-512 -* Asymmetric signing/encryption: RSA-3072, or ECC-384 (see <<_pqc_readiness, PQC readiness>>) +* Asymmetric signing/encryption: RSA-3072, or ECC-384 (see <<_pqc_readiness, +PQC readiness>>) -Some legacy use cases may require use of other algorithms, such as SHA-256 or AES-128. In these cases, wherever possible, an upgrade path should be supported. For example, allocating sufficient storage to accommodate larger sizes in future updates. +Some legacy use cases may require use of other algorithms, such as SHA-256 or +AES-128. In these cases, wherever possible, an upgrade path should be +supported. For example, allocating sufficient storage to accommodate larger +sizes in future updates. -Some use cases, such as cryptographic memory protection, may sometimes use specialized algorithms for performance in a constrained use case. These are not discussed here but should have similar properties to the ones listed above, but with different trade-offs. +Some use cases, such as cryptographic memory protection, may sometimes use +specialized algorithms for performance in a constrained use case. These are not +discussed here but should have similar properties to the ones listed above, but +with different trade-offs. -For Chinese markets, equivalent _ShangMi (SM)_ algorithm support is required. In particular: +For Chinese markets, equivalent _ShangMi (SM)_ algorithm support is required. +In particular: * SM2: Authentication (ECC based) * SM3: Hash function (256-bit) @@ -66,8 +98,11 @@ For Chinese markets, equivalent _ShangMi (SM)_ algorithm support is required. In See http://gmbz.org.cn/main/index.html -RISC-V cryptographic ISA extensions also include support for ShangMi algorithms (SM3 and SM4) +RISC-V cryptographic ISA extensions also include support for ShangMi algorithms +(SM3 and SM4) Some Shang-Mi algorithms are also described in ISO specifications. -Other specific markets also require regional cryptographic algorithms, for example Russian Ghost. RISC-V cryptographic ISA extensions currently do not directly support Russia specific algorithms. +Other specific markets also require regional cryptographic algorithms, for +example Russian Ghost. RISC-V cryptographic ISA extensions currently do not +directly support Russia specific algorithms. diff --git a/specification/src/contributors.adoc b/specification/src/contributors.adoc index 8f42b78..01bd35e 100644 --- a/specification/src/contributors.adoc +++ b/specification/src/contributors.adoc @@ -1,8 +1,8 @@ == Contributors This RISC-V specification has been contributed to directly or indirectly by (in -alphabetical order): Ali Zhang, Andy Dellow, Carl Shaw, Colin O'Flynn, -Dean Liberty, Dong Du, Deepak Gupta, Colin O'Flynn, Guerney Hunt, Luis Fiolhais, -Manuel Offenberg, Markku Juhani Saarinen, Munir Geden, Mark Hill, Nicholas Wood, -Paul Elliott, Ravi Sahita, Samuel Ortiz, Steve Wallach, Suresh Sugumar, -Terry Wang, Victor Lu, Ved Shanbhogue, Yann Loisel +alphabetical order): Ali Zhang, Andy Dellow, Carl Shaw, Colin O'Flynn, Dean +Liberty, Dong Du, Deepak Gupta, Colin O'Flynn, Guerney Hunt, Luis Fiolhais, +Manuel Offenberg, Markku Juhani Saarinen, Munir Geden, Mark Hill, Nicholas Wood +(editor), Paul Elliott, Ravi Sahita (co-editor), Samuel Ortiz, Steve Wallach, +Suresh Sugumar, Terry Wang, Victor Lu, Ved Shanbhogue, Yann Loisel diff --git a/specification/src/header.adoc b/specification/src/header.adoc index 078b78d..cc1402b 100644 --- a/specification/src/header.adoc +++ b/specification/src/header.adoc @@ -1,8 +1,8 @@ [[header]] :description: RISC-V Security Model (non-normative) :company: RISC-V.org -:revdate: 11/2023 -:revnumber: 0.1 +:revdate: 12/2023 +:revnumber: 0.2 :revremark: This document is in development. Assume everything can change. See http://riscv.org/spec-state for details. :url-riscv: http://riscv.org :doctype: book