Added summary of extensions

chapter2.adoc

@@ -1,23 +1,36 @@
 [[chapter2]]
 ==  Summary of extensions for Supervisor Domain Access Protection
 
-Supervisor Domain Access Protection extensions specifies if a physically-addressed memory or device-mapped region is accessible (read/write) by a hart/device operating in a supervisor domain (or not). Associating a memory region with a supervisor domain via Smmtt implies that the physical-addressable region is accessible only from software or hardware accesses occurring in the context of the owner supervisor domain. Hence, software or hardware accesses that originate from other supervisor domains outside the owner supervisor domain are prevented by hardware. The RDSM has access to all supervisor domains.
+Supervisor Domain Access Protection extensions are used by M-mode software to program if physically-addressed memory (or device-mapped region) is 
+accessible (read/write) by a hart/device operating under the control of S-mode software within a domain. Associating a hart/device with a supervisor domain 
+implies that any physical-addressable region accesses occurring in the context of the supervisor domain is subject to access-checks for that domain. 
+Hence, software or hardware accesses that originate from other supervisor domains outside the owner supervisor domain can be 
+explicitly prevented/allowed by using the Smmtt extension. The RDSM has access to physical memory for all supervisor domains.
 
 In order to enforce these properties, the following architecture extensions are required:
 
 * Smsdid - An interface to signal the active supervisor domain under which a hart is operating. This is a dynamic control state on the hart that can be held in an M-mode CSR and modifiable by the RDSM via the CSR r/w instructions  - herewith called the supervisor domain identifier assigned to the hart. Domains are orthogonal to privilege levels within the supervisor domain and since Smmtt enables physical memory isolation, there is one CSR (per hart) managed by the M-mode. Similarly for devices, a supervisor domain identifier may be assigned to the device to signify assignment - A cross-reference to the IO supervisor domain will be added in the future; Isolation of data within a device is out of scope of this specification.
 
 * Smmtt - An interface to set the access permissions for a memory region or page associated with a supervisor domain. This interface allows dynamic changes of association (which may require appropriate flushing of any state cached in harts). The association mapping is programmed via an Memory Tracking Table (MTT) structure, accessed via per-hart M-mode CSRs and which may be backed by additional in-memory structures. The M-mode CSR interface is expected to program the root physical page (MTTPPN) - for when the MTT is a memory-based structure, the MTTPPN would hold the physical address of the root page of the MTT structure in memory - the MTT is expected to be memory resident at time of access. Write access to MTT structures must be restricted by and to the RDSM (except for when explicitly allowed by the RDSM). Privilege levels may affect changes in the MTT under purview of the Supervisor Domain Security Manager (SDSM) either through an SBI interface into M-mode (or may have the ability to edit MTT structures by virtue of how the MTT structure in memory is accessible to lower privilege levels).
 
-* MTT checker - this functional block looks up the MTT using the physical address of the access as an index to retrieve the access permissions for the supervisor domain. This checker thus enforces that for a load initiated by the hart, the physical address is readable, and for a store initiated by the hart, the physical address is also writable, else reports a fault. An access violation is reported as a trap to the M-mode Root domain security manager, and the access is disallowed with no data divulged. This checker may be implemented as an MMU extension in the hart. The MTT checker is designed to work together with the page-based virtual memory (MMU) systems and Physical Memory Protection (PMP) mechanism. Read and Write permissions for memory are derived from the page table, the PMP and the MTT - an access is allowed only when all protection mechanisms allow the access. When paging is enabled, instructions that access virtual memory may result in multiple physical-memory accesses, including (implicit S-mode) accesses to the page tables. MTT checks also apply to these implicit accesses - those accesses will be treated as reads for translation and as writes when A/D bits are updated in page table entries for Svadu is implemented).
+[NOTE]
+====
+Memory regions may be accessed by harts or by other devices on the platform. When harts and devices are assigned to a supervisor domain, the hart/device is said to perform memory accesses in the context of that supervisor domain. For all accesses using a physical address, the SDID is the supervisor domain identifier programmed into a CSR.  This CSR is programmed on the hart by the Root Domain Security Manager (RDSM). The assignment of the hart/device to a supervisor domain may be static (e.g. device assignment to a VM) or dynamic (e.g. scheduling a VM virtual cpu within a domain). The MTT for the supervisor domain active on the hart is programmed on the hart along with the supervisor domain identifier. The MTT does not perform any address translation; it simply provides access permissions for the physically addressed region/page (post any S-mode and/or G-stage address translation) to enforce the isolation properties per the use case requirements (see Figure 2.1).
+====
 
-* Physical address metadata selector (Svpams) - To support IO/memory sharing, a hart/device may perform accesses to memory exclusively accessible to its supervisor domain, and to memory shared globally with all supervisor domains or other specific supervisor domains. Memory sharing between supervisor domains is achieved by simply making the physical memory region accessible to the supervisor domains via the MTT structure. Access to physical addresses initiated from a hart or a device that is initialized with an MTT in non-`Bare` mode and valid supervisor domain identifier may be denied by virtue of the permissions in the MTT lookup - such disallowed accesses cause a trap to the RDSM to report a fault. When access to shared memory is allowed by the MTT, it may need to be additionally qualified to enforce downstream security-controls. To achieve this, a physical address metadata selector may be provided as part of the access. The possible metadata are specified in N(16?) of `MXLEN` bit CSRs per hart. The metadata that is associated with the accessed physical address is selected via a 4-bit physical address metadata selector field programmed into the S-mode or G-stage page table leaf entry traversed as part of the address translation. The domain workload is expected to manage the S-mode page table selectors, and the Supervisor domain security manager (operating in `HS-mode` is expected to manage the G-stage page table entry selectors. Additional usage information about Svpams is described below.
+* MTT checker - this functional block looks up the MTT using the physical address of the access as an index to retrieve the access permissions for the supervisor domain. This checker thus enforces that for a load initiated by the hart, the physical address is readable, and for a store initiated by the hart, the physical address is also writable, else reports a fault. An access violation is reported as a trap to the M-mode Root domain security manager, and the access is disallowed with no data divulged. This checker may be implemented as an MMU extension in the hart. The MTT checker is designed to work together with the page-based virtual memory (MMU) systems and Physical Memory Protection (PMP) mechanism. Read and Write permissions for memory are derived from the page table, the PMP and the MTT - an access is allowed only when all protection mechanisms allow the access. When paging is enabled, instructions that access virtual memory may result in multiple physical-memory accesses, including (implicit S-mode) accesses to the page tables. MTT checks also apply to these implicit accesses - those accesses will be treated as reads for translation and as writes when A/D bits are updated in page table entries when Svadu is implemented.
 
-Additional protection/isolation for memory associated with a supervisor domain is orthogonal (and usage-specific). Such additional protection for memory may be derived by the use of cryptography and/or access-control mechanisms. The mechanisms chosen for these additional protection methods are independent of Smmtt and may be platform-specific, though they may utilize the physical address metadata selected during the access. The TCB of a particular supervisor domain may be independently evaluated via attestation of the HW and SW TCB by a relying party using standard Public-Key Infrastructure-based mechanisms.
+* Physical address metadata selector (Svpams) - To support IO/memory sharing, a hart/device may perform accesses to memory exclusively accessible to its supervisor domain, and to memory shared globally with all supervisor domains or other specific supervisor domains. Memory sharing between supervisor domains is achieved by simply making the physical memory region accessible to the supervisor domains via the MTT structure. Access to physical addresses initiated from a hart or a device that is initialized with an MTT in non-`Bare` mode and valid supervisor domain identifier may be denied by virtue of the permissions in the MTT lookup - such disallowed accesses cause a trap to the RDSM to report a fault. When access to shared memory is allowed by the MTT, it may need to be additionally qualified to enforce downstream security-controls. To achieve this, a physical address metadata selector may be provided as part of the access. The possible metadata are specified in N(16?) of `MXLEN` bit CSRs per hart. The metadata that is associated with the accessed physical address is selected via a 4-bit physical address metadata selector field programmed into the S-mode or G-stage page table leaf entry traversed as part of the address translation. The domain workload is expected to manage the S-mode page table selectors, and the Supervisor domain security manager (operating in `HS-mode`) is expected to manage the G-stage page table entry selectors. Additional usage information about Svpams is described below.
 
-Memory regions may be accessed by harts or by other devices on the platform. When harts and devices are assigned to a supervisor domain, the hart/device is said to perform memory accesses in the context of that supervisor domain. For all accesses using a physical address, the SDID is the supervisor domain identifier programmed into a CSR.  This CSR is programmed on the hart by the Root Domain Security Manager (RDSM). The assignment of the hart/device to a supervisor domain may be static (e.g. device assignment to a VM) or dynamic (e.g. scheduling a VM virtual cpu within a domain). The MTT for the supervisor domain active on the hart is programmed on the hart along with the supervisor domain identifier. The MTT does not perform any address translation; it simply provides access permissions for the physically addressed region/page (post any S-mode and/or G-stage address translation) to enforce the isolation properties per the use case requirements (see Figure 2.1).
+* Smsdia - This interface describes the M-mode CSRs to assign dedicated IMSIC S-interrupt file or an APLIC domain to a Supervisor Domain. The interface also describes CSRs to allow M-mode software to retain control on notification of interrupts when Supervisor domains are enabled.
+
+* IO MTT - This interface describes the register interface for an IO interconnect to associate SDID to IOMMU ID (called the SD Classifier). The assignment of IOMMUs to supervisor domains is also expected to be under the purview of the RDSM. IO MTT interface specifies the memory access interface for physical-address encountered during IO MMU address translation as well for the final physical address of access. The specifics of device assignment are expected to be device/bus-specific and are out of scope of this specification.
+
+[NOTE]
+====
+Additional protection/isolation for memory associated with a supervisor domain is orthogonal (and usage-specific). Such additional protection for memory may be derived by the use of cryptography and/or access-control mechanisms. The mechanisms chosen for these additional protection methods are independent of Smmtt and may be platform-specific, though they may utilize the physical address metadata selected (via the Svpams extension) during the access. The TCB of a particular supervisor domain may be independently evaluated via attestation of the HW and SW TCB by a relying party using standard Public-Key Infrastructure-based mechanisms.
+====
 
-The assignment of devices and IOMMUs to supervisor domains is also expected to be under the purview of the RDSM. The specifics of device assignment are expected to be device/bus-specific and are out of scope of this specification.
 
 [caption="Figure {counter:image}: ", reftext="Figure {image}"]
 [title= "MTT lookup for Supervisor Domain Access"]