riscv-non-isa · rsahita · Dec 14, 2023 · Dec 11, 2023 · Dec 11, 2023 · Dec 13, 2023
diff --git a/specification/images/img_ch2_reference-model.png b/specification/images/img_ch2_reference-model.png
diff --git a/specification/images/img_ch4_cove.png b/specification/images/img_ch4_cove.png
diff --git a/specification/images/img_ch4_gp-tee.png b/specification/images/img_ch4_gp-tee.png
diff --git a/specification/images/img_ch4_priv.png b/specification/images/img_ch4_priv.png
diff --git a/specification/riscv-platform-security-model.pdf b/specification/riscv-platform-security-model.pdf
diff --git a/specification/src/chapter1.adoc b/specification/src/chapter1.adoc
@@ -3,14 +3,19 @@
 
 == Introduction
 
-This specifications provides guidelines for how RISC-V systems can use RISC-V
-security building blocks to build secure systems for different use cases.
-
-The guidelines are listed through a few example uses cases based on commonly
-used profiles. The guidelines are not intended to be exhaustive; it is expected
-that the principles described in the chosen examples are general enough to be
-applicable to other use cases as well. The examples may be extended over time
-as required.
+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. 
+
+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
 

diff --git a/specification/src/chapter2.adoc b/specification/src/chapter2.adoc
diff --git a/specification/src/chapter3.adoc b/specification/src/chapter3.adoc
@@ -50,6 +50,14 @@ yet].
 
 MMU, PMP/ePMP, and sPMP are discussed later in this chapter.
 
+==== PMA
+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.
+
+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
 
 https://github.com/riscv/riscv-isa-manual/releases/tag/Priv-v1.12[Privileged
@@ -146,14 +154,16 @@ 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.
+
 [width=100%]
 [%header, cols="5,20"]
 |===
 | ID#
 | Requirement
 
 | CAT_NN
-| Either PMP/ePMP or MTT MUST be used to enforce physical memory isolation
+| 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.
 
@@ -164,6 +174,8 @@ 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).
+
 [width=100%]
 [%header, cols="5,20"]
 |===
@@ -219,6 +231,8 @@ levels
 | 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).
+
 ==== IOPMP
 
 https://github.com/riscv-non-isa/iopmp-spec
@@ -240,6 +254,7 @@ access control.
 | 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.
 
 ==== IOMTT
 
@@ -267,12 +282,13 @@ 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.
+
 ==== IOMMU
 
 https://github.com/riscv-non-isa/riscv-iommu
 
-IOMMU is a system level component providing virtual memory access-control for
-device-initiated transactions, complementing MMU translation rules.
+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"]
@@ -285,8 +301,7 @@ device-initiated transactions, complementing MMU translation rules.
 
 | CAT_NNN
 | Systems supporting IOMMU MUST also enforce physical memory access control for
-M-mode memory against device-initiated transactions (e.g. via IOMTT, IOPMP or
-equivalent).
+M-mode memory against device-initiated transactions (IOMTT or IOPMP).
 
 |===
 
@@ -325,7 +340,7 @@ C.JR, C.JALR), from their original target address to a new target via
 modification in the return stack or in the memory used to obtain the jump/call
 target address.
 
-Risc-V provides two defenses:
+RISC-V provides two defenses:
 
 * Shadow stacks (Zicfiss) - protect return addresses on call stacks
 * Labeled Landing pads (Zicfilp) - protect target addresses in jumps and
@@ -335,20 +350,20 @@ branches
 
 https://github.com/riscv/riscv-crypto
 
-Risc-V includes ISA extensions in the following cryptographic areas:
+RISC-V includes ISA extensions in the following cryptographic areas:
 
 * Scalar cryptography
 * Vector cryptography
 * Entropy source (scalar)
 
-Risc-V cryptographic extensions are aimed at supporting efficient acceleration
+RISC-V cryptographic extensions are aimed at supporting efficient acceleration
 of cryptographic operations at ISA level. This can both help reduce the TCB of
 an isolated component, and avoid hardware bottlenecks (for example, system
 level cryptographic subsystems).
 
 The entropy source extension provides an ISA level interface to a hardware
 entropy source. Entropy source requirements can depend on use case or ecosystem
-specific requirements and Risc-V does not provide any entropy source technical
+specific requirements and RISC-V does not provide any entropy source technical
 specification. But the entropy source ISA specification does contain general
 recommendations and references.
 
@@ -359,7 +374,7 @@ recommendations and references.
 | Requirement
 
 | CAT_NNN
-| Risc-V systems SHOULD support either scalar or vector cryptographic ISA
+| RISC-V systems SHOULD support either scalar or vector cryptographic ISA
 extensions
 
 | CAT_NNN
@@ -393,7 +408,7 @@ other processes within the same workload.
 
 * TBD
 
-==== System level isolation
+==== System integration
 
 * WorldGuard