Merge pull request #48 from riscv/topic/smmtt-updates

Smmtt updates per TG call on 4/30 and 5/14

chapter2.adoc

@@ -1,190 +1,56 @@
 [[chapter2]]
 ==  Summary of extensions for Supervisor Domain Access Protection
 
-=== Architecture Extensions
+The following normative architecture extensions are defined.
 
-The following normative architecture extensions are defined. The following
-sub-section describes the (informative) theory of operation.
-
-* `Smsdid` (<<Smsdid>>) - An interface to signal the active supervisor domain
+* `Smsdid` (<<Smsdid>>) - An interface to program 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 CSR r/w
 instructions  - herewith called the `supervisor domain identifier` assigned to
-the hart. Supervisor domains are orthogonal to hart privilege levels and since
-Smmtt enables physical memory isolation, there is one CSR (per hart) managed by
-M-mode. `Smsdid` is expected to be used in conjunction with `Smmtt` for physical
-memory isolation along with mechanisms such as `PMP` and `Smepmp`. Device side
-accesses are addressed in the `IO-MTT` extension. Isolation of data within a
-device is out of scope of this specification.
-
-* `Smmtt` (<<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 and e(PMP) are always active.
-MTT may be configured to be `Bare` if granular memory access control
-is not required. The SDID
-CSR defined by `Smsdid` is used as defined.
-
-* `IO-MTT` (<<IO-MTT>>) - This non-ISA interface enables programming of an IO
-interconnect to associate SDID to IOMMU ID (called the SD Classifier). The
+the hart. The SDID is a local identifier for the hart and may be used to tag
+hart-local resources to access-control data associated with the supervisor
+domain. The supervisor domain identifier is independent from the hart privilege
+levels and is held in a M-mode CSR. This extension may be
+used independently or may be combined with other extensions in this
+specification.
+
+* `Smmtt` (<<Smmtt>>) - An extension to set the access permissions for a memory
+region or page associated with a supervisor domain. This extension allows for
+dynamic changes of access permission. Such dynamic changes may require flushing of
+appropriate state cached in harts. The access properties are programmed via an Memory
+Tracking Table (MTT) structure. The physical page number (PPN) of the root table of
+the MTT is programmed into a M-mode CSR. When `Smmtt` is implemented, MTT
+and e(PMP) are always active. Although there is no option to disable MTT, it can be
+effectively disabled if granular memory access control is not required by configuring
+MTT mode to be `Bare`.
+
+* `IO-MTT` (<<IO-MTT>>) - A non-ISA extension that enables programming of an IO
+interconnect to associate an IOMMU and devices in scope of that IOMMU with an SD. 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-addresses encountered during IOMMU address translation as well for the
-final physical address of access.
-
-* `Smsdia` (<<Smsdia>>) - This M-mode CSR interface enables assignment of 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
+purview of the RDSM. IO-MTT extension specifies the memory access control mechanisms for
+memory accesses performed by the IOMMU as well as by the devices associated with that SD.
+Note that isolation of data within a device is
+out of scope of this specification.
+
+* `Smsdia` (<<Smsdia>>) - This extension enables assignment of IMSIC
+interrupt file(s) or an APLIC domain to a supervisor domain. The extension also
+provides CSRs to allow M-mode software to retain control on notification of
 interrupts when Supervisor domains are enabled.
 
 * `Smsdedbg` (<<Smsdedbg>>) - This extension provides the controls to indicate
 if external debug is allowed for a supervisor domain. Whether external debug is
 authorized or not is expected to be done via a root of trust (RoT) and is
 outside the scope of this specification.
 
-=== Theory of operation (informative)
-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 access 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 other than 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.
-
-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 <<mtt-lookup>>).
-
-[caption="Figure {counter:image}: ", reftext="Figure {image}"]
-[title= "MTT lookup for Supervisor Domain Access", id=mtt-lookup]
-image::images/fig2.png[]
-
-The MTT checker is a functional block that 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 supervisor domain and may be handled by
-the M-mode Root domain security manager. Such disallowed accesses are ideally
-handled with no data divulged. This MTT checker may be implemented
-as an MMU extension in the hart, and/or in the IO interconnect to check device
-accesses. The MTT checker is designed to work together with the page-based
-virtual memory (MMU, IOMMU) systems and Physical Memory Protection
-(PMP, IOPMP) mechanisms. 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.
-
-MTTs are checked by the MTT checker for all accesses to eligible
-physical memory, including accesses that have undergone virtual to
-physical memory translation, but excluding MTT structure accesses. The
-MTT checker indexes the MTT using the physical address of the access to
-retrieve the access permissions, and checks that the hart or device is allowed
-to access the physical memory accessed. A mismatch of the access type and
-the access permissions specified in the MTT entry that applies to the
-accessed region is reported as a trap to the supervisor domain software or
-to the RDSM and the access is
-disallowed with no data divulged. As described above, to support
-architectural virtual address page sizes, the MTT allows configuration
-at those supported architectural page sizes. MTT violations manifest as
-instruction, load, or store access-fault exceptions. The exception
-conditions for MTT are checked when the access to memory is performed.
-
-MTT may be used to provide permissions for physical memory addresses
-that hold regular main memory or IO memory. Memory may be assigned to
-the RDSM to bootstrap the subsequent run-time lookup structures for MTT.
-All memory should be covered by the MTT, though some memory may not be
-eligible to be qualified for assignment to a specific supervisor domain.
-This limitation may arise due to platform configuration and security
-policies - for example, if the platform security policy requires memory
-for a domain to be encrypted and some memory access paths are not
-enforced via an inline memory encryption engine. It is expected that the
-RDSM can use trusted platform-specific methods to enumerate which
-regions can be designated as access-controlled via the MTT.
-
-MTT must support both static and run-time configurability. A memory
-region (consisting of one or more pages) may be (re)assigned from one
-domain to another at run-time e.g. this is done by revoking the
-permission for one domain and assigning permissions to another domain.
-Run-time configuration may be performed via M-mode CSRs and/or in-memory
-structures. The in-memory structures used for MTT must themselves be
-access-limited to the RDSM by use of the MTT structures to disallow any
-supervisor domain from accessing the structures unless explicitly
-delegated by the Root Domain Security Manager (RDSM) to a particular
-domain (per use case policies). To support MTT dynamic reconfiguration,
-an interface is expected to be provided to set the attributes by passing
-requests to a trusted driver (in the RDSM) that can reconfigure the
-memory region assignment. Converting memory regions assignment from one
-domain to another might involve platform-specific operations based on
-the enforcement mechanism, such as TLB/cache flushes, that must be
-enforced by the RDSM and hardware. The RDSM is expected to change the
-settings and flush caches if necessary, so the system is only incoherent
-during the transition between domain assignment settings. This
-transitory state should not be visible to lower privilege levels (i.e.
-supervisor domains). There are also security aspects to be considered during
-(re)configuration, e.g., clearing memory used by the current SD before
-assigning it to another SD. Refer to the RISC-V CoVE cite:[CoVE] ABI and threat
-model as a reference.
-
-A hart/device may perform accesses to memory exclusively accessible to it's
-supervisor domain, or to memory shared globally with one or more 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 associated with the hart or device. Access to physical addresses
-initiated from a hart or a device assigned a supervisor domain identifier may be
-denied by virtue of the permissions in the MTT lookup - such disallowed accesses
-cause a trap which may be reported to the supervisor domain software or to the
-RDSM to report a fault.
+* `Smsdetrc` (<<Smsdetrc>>) - This extension provides the controls to indicate
+if external trace is allowed for a supervisor domain. Whether external trace is
+authorized or not is expected to be done via a root of trust (RoT) and is
+outside the scope of this specification.
 
-The intra-domain isolation of memory between two harts/devices belonging
-to the same supervisor domain, but different tenant workloads, is
-achieved via the use of MMU, (S)PMP, IOMMU and IOPMP depending on the
-type of platform and the type of access. To successfully achieve this
-isolation, the page table structures for a domain's workloads must be
-managed by the Supervisor Domain Security Manager (SDSM) and the paging
-structures must be located in memory exclusively-accessible only to the
-Supervisor Domain. Additional security properties may be enforced based
-on type (data fetch, instruction fetch, etc.) and locality (hart
-supervisor domain identifier) of memory accesses as required for the
-security policy specific to usages. An example policy may be to require
-certain accesses to target only exclusively-owned domain memory. The MTT
-checker may utilize the supervisor domain identifier or additional metadata
-for the access to enforce such policies. The description of different types
-of Supervisor Domain policies possible is outside the scope of this document.
+* `Smsqosid` and CBQRI for Supervisor Domains (<<Smsdqos>>) - This extension
+provides an interface for the RDSM to enforce that resource accesses from a
+supervisor domain or the RDSM must not be observable by entities that are not
+within their TCB using the resource usage monitors. Similarly, the resource
+allocations for a supervisor domain or the RDSM must not be influenced by
+entities outside their TCB.
 
-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. The TCB of a particular supervisor domain
-(and devices that are bound to it) may be independently evaluated via
-attestation of the HW and SW TCB by a relying party using standard Public-Key
-Infrastructure-based mechanisms.