Typos & minor suggestions

src/attestation.adoc

@@ -292,7 +292,7 @@ composed of both the hardware RoT generated Platform Token and the TSM-driver
 created TSM Token (See <<TSM Token>>). It is signed by the Platform CDI-derived
 attestation key.
 
-As the following step in the DICE chain, the TSM generates and provision any TVM
+As the following step in the DICE chain, the TSM generates and provisions any TVM
 it creates with its CDI. TVM CDIs are derived from the TSM CDI and the TVM
 specific measurements. However, unlike the RoT and the TSM-driver, the TSM does
 not pass attestation certificates to its TVMs. For evidence freshness
@@ -330,8 +330,8 @@ formatted as an untagged, unprotected Concise Binary Object Representation
 (<<CBOR>>) Web Token (<<UCCS>>). A CoVE EAT profile is proposed to narrow the
 EAT specification for the CoVE use case to enable interoperability.
 
-The UCCS is composed of one EAT submodule Claims-Set map where the map values
-are attestation tokens for the TVM, TSM and Platform Claims.
+The UCCS (Unprotected CWT Claims Set) is composed of one EAT submodule Claims-Set 
+map where the map values are attestation tokens for the TVM, TSM and Platform Claims.
 
 The TVM EAT is a CWT tagged CBOR formatted token, wrapped with a
 COSE_Sign1 <<COSE>> envelope. It is signed by the TSM attestation key and must
@@ -347,8 +347,8 @@ COSE_Sign1 <<COSE>> envelope. It is signed by the RoT attestation key and must
 include the DICE derived public key for the Platform.
 
 The CoVE layered Evidence structure is represented by the above described
-composition of cryptographically chained EAT tokens. Verifier can then attest
-of a CoVE workload trustworthiness by independently inspecting each token,
+composition of cryptographically chained EAT tokens. The Verifier can then attest
+a CoVE workload trustworthiness by independently inspecting each token,
 while being able to verify that the TCB represented by one token was used to
 generate the next one.
 

src/contributors.adoc

@@ -5,7 +5,7 @@ contributed to directly or indirectly by (in alphabetical order):
 
 [.text-justify]
 Andrew Bresticker, Andy Dellow, Atish Patra, Atul Khare, Beeman Strong,
-Christian Bollis, Dingji Li, Dong Du, Dylan Reid, Eckhard Delfs,
+Christian Bolis, Dingji Li, Dong Du, Dylan Reid, Eckhard Delfs,
 Fabrice Marinet, Guerney Hunt, Jiewen Yao, Kailun Qin, Manuel Offenberg,
 Nicholas Wood, Nick Kossifidis, Osman Koyuncu, Qing Li, Rajnesh Kanwal,
 Ravi Sahita (Editor), Rob Bradford, Samuel Ortiz, Steven Bellock,

src/overview.adoc

@@ -28,11 +28,12 @@ On processors supporting multiple supervisor domains (the Smmtt extension), the
 resources managed by the hosting supervisor domain (OS/VMM) include memory, CPU,
 I/O resources and platform capabilities required to host the TVM workload. The
 terms hosting supervisor domain and OS/VMM are used interchangeably in this
-specification. The underlying memory isolation mechanisms for supervisor domains
+specification. The underlying memory isolation mechanism for supervisor domains
 (Smmtt) is agnostic of the number of supervisor domains. On processors that do
 not support multiple supervisor domains where Smmtt is not mandated, a single
 confidential  supervisor domain and a single hosting supervisor domain can be
-supported (for example <<dep3>>, other deployment models are also possible).
+supported using other hardware memory isolation techniques like PMP 
+(for example <<dep3>>, other deployment models are also possible).
 
 [id=dep1]
 [caption="Figure {counter:image}", reftext="Figure {image}"]
@@ -47,7 +48,7 @@ trusted intermediary between TEE and non-TEE workloads on the same platform.
 The TSM should have a minimal hardware-attested footprint. The TCB (which
 includes
 the TSM and hardware) enforces strict confidentiality and integrity security
-properties for workloads in this supervisor domain. The Root Security Manager,
+properties for workloads in this supervisor domain. The Root Domain Security Manager,
 also called the " *TSM-driver* ", isolates the Confidential Supervisor Domain
 from all other Supervisor domains and other platform components
 (non-confidential and
@@ -93,8 +94,8 @@ execute and destroy a TVM - _this specification aims to describe the TEEI and
 TSM interfaces_. By using the Hypervisor extension of the RISC-V privileged
 specification <<R0>>, this specification minimizes ISA changes to introduce
 a scalable architecture for hosting TEE workloads. More than one confidential
-supervisor domains may be hosted by the TSM-driver. Similarly, more than one
-TVMs may be hosted by the host OS/VMM via confidential supervisor domains.
+supervisor domain may be hosted by the TSM-driver. Similarly, more than one
+TVM may be hosted by the host OS/VMM via confidential supervisor domains.
 Each TVM may consist of the guest firmware, a guest OS and applications. The
 software components included in the TVM are implementation specific.
 
@@ -165,7 +166,7 @@ management.
 <<dep1>> shows TVMs (a.k.a. confidential VMs) managed by a VMM and <<dep1a>>
 shows Confidential applications managed by an untrusted host (OS/VMM). As
 evident from the architecture, the difference between these two scenarios is the
-software TCB (owned by the tenant within the TVM) for the tenant workload in the
+software TCB (owned by the tenant within the TVM): for the tenant workload in the
 application TEE case, a minimal guest runtime may be used; whereas in the VM TEE
 case, an enlightened guest OS is expected in the TVM TCB. Other software models
 that map to the VU/VS modes of operation are also possible as TEE workloads.

src/refarch.adoc

@@ -161,7 +161,7 @@ TSM-driver and the TSM. The TSM-driver is responsible for enforcing isolation of
 confidential memory regions (e.g., via PMP or MTT) and the TSM
 is responsible for enforcing isolation of confidential memory pages among TVMs
 (e.g., via G-stage page tables). Pages assigned to the TVM may be exclusively
-accessible to the condidential supervisor domain or may be shared with the
+accessible to the confidential supervisor domain or may be shared with the
 hosting supervisor domain (e.g., to allow for paravirtualized IO access).
 
 [NOTE]
@@ -482,7 +482,7 @@ In this deployment model, other supervisor domains have access to 1st
 and G-stage paging hardware the root security manager (TSM-driver) must use MTT
 to isolate supervisor domain memory. In this deployment model,
 TEE and TVM address spaces are identified by supervisor domain identifiers
-(Smsdid) to maintain the isolation during access and in internal
+(SDIDs) to maintain the isolation during access and in internal
 address translation caches, e.g., Hart TLB lookup may be extended with the
 SDID in addition to the ASID, VMID for workloads in the Confidential supervisor
 domain. TVM memory isolation must support sparse memory management

src/sbi_cove.adoc

@@ -12,10 +12,10 @@ extension. This specification introduces four new extensions:
 
 === CoVE FID namespaces
 
-Implementations may support more than one confidential supervisor domains. In
+Implementations may support more than one confidential supervisor domain. In
 order to support that scenario, as shown in <<cove-fid>>, the most significant 6
 bits of the SBI Function Id for the CoVE Extension may be set by the host to
-specifies the target Supervisor Domain Idenfier/TSM for the CoVH or COVI
+specify the target Supervisor Domain Identifier/TSM for the CoVH or COVI
 function invoked. For guest-invoked COVG functions, the RDSM must specify the
 Supervisor Domain Identifier for the callee. `a6` bits [16..25] are reserved for
 future use. `a6` bits [0..15] are used by the host to specify the CoVE functions

src/swlifecycle.adoc

@@ -58,7 +58,7 @@ The VMM may assign memory to the TVM via a sequence of
 `sbi_covh_add_tvm_zero_pages()` - the former grants memory pages that are to
 contain second-stage paging structures entries that translate a TVM guest
 physical address to the system physical address, while the latter two are used
-to hold TVM data and is referenced by the hgatp leaf page table entries. For
+to hold TVM data and are referenced by the hgatp leaf page table entries. For
 pages added to the TVM, the VMM must invoke `sbi_covh_add_tvm_measured_pages()`
 which extends the initial measurement hash of the TVM. The hash will be used by
 the TSM to generate the attestation report (evidence) when requested by a
@@ -132,7 +132,7 @@ requires that the TVM supervisor code should not locate VS-stage page
 tables in non-confidential memory. The TSM enforces that G-stage page
 tables are in confidential memory.
 * TVM access to confidential or non-confidential memory is subject to
-VS-stage address translation (this is existing). G-stage address
+VS-stage address translation (if this is existing). G-stage address
 translation is enforced via the TSM-managed hgatp with the listed
 recommendations in <<TSM and TVM Isolation>>.
 
@@ -243,28 +243,34 @@ the GPA and enforced for memory access for the TVM by the hardware.
 
 ====  Information tracked per physical page
 
-For implementations that utilize MTT the Extended Memory Tracking Table (EMTT)
+For implementations that utilize MTT, the Extended Memory Tracking Table (EMTT)
 information managed by the TSM
 is used to track additional fields of metadata associated with physical
 addresses.
 The page size is implicit in the MTT and EMTT lookup - 4KB, 2MB, 1GB, 512GB.
 Actual page sizes supported are implementation-specified.
 
 |===
-| *Memory Type* | *Confidential or Non-confidential (enforced via MTT)*
-| Page-Type   | Reserved - page that may not be assigned to any TEE entity
+h| Memory Type h| Confidential or Non-confidential (enforced via MTT)
+| Page-Type   
+a| Reserved - page that may not be assigned to any TEE entity.
+
 If the Memory Type is Confidential, the following page types may be used:
+
 * Unassigned - page not assigned to any TEE (TSM or TVM)
-* TVM - page assigned to a TVM (mapped via G-stage page table).
+* TVM - page assigned to a TVM (mapped via G-stage page table)
 * TSM - page used by the TSM (for MTT and other control structures)
 | Page Owner  | If the Memory Type is Confidential and Page-Type is TVM,
 this value holds the identifier (e.g., PPN) for the TVM control page (4KB TEE-
 TSM-TVM page); else it is 0.
-| Page sub-type | Following types apply if Memory Type is Confidential and
+| Page sub-type a| Following types apply if Memory Type is Confidential and
 Page-Type is TVM:
+
 * HGATP - pages used for HGATP structures
 * Data - pages used for TVM content
-Following types apply If Memory Type is Confidential and Page-Type is TSM:
+
+Following types apply if Memory Type is Confidential and Page-Type is TSM:
+
 * MTT - pages used for MTT structures
 * TVMC - pages used for TVM control structure(s) for global control
 * VHCS - pages used for TVM VHCS (virtual hart control structures)
@@ -423,7 +429,7 @@ during the vcpu run.
 mappings exist at this point -----
 * Invoke the specific mapping change operation, such as remove, relocate,
 promote, migrate etc.
-* Checks that the affected mapping(s) are invalidated in the MTT and/or g-stage
+* Checks that the affected mapping(s) are invalidated in the MTT and/or G-stage
 mapping and validate the mapping.
 * Subsequent page walks may create cached mappings from this point onwards.
 
@@ -441,7 +447,7 @@ page(s) to be used for the hgatp structure entries
 
 * Verify that the TVM has been created successfully.
 * Verify that the PPN(s) for the new page(s) to be used for TVM hgatp is/are
-Unassigned-Confidential per the MTT.
+Unassigned-Confidential per the EMTT.
 * For the GPA to be mapped, perform a TVM-hgatp walk to locate the non-leaf
 entry that should refer to the new page being added (to hold the next level of
 the mapping for the GPA). If the mapping already exists, the operation is
@@ -501,7 +507,7 @@ While OS/VMMs traditionally have unfettered access to the virtualized timer and
 interrupt state of legacy VMs, TVMs must be protected from malicious injection
 or filtering of interrupts or modification of timers which could lead to
 incorrect execution of or information leakage from the TVM. As such, a
-combination of hardware isolation features and COVH support are necessary to
+combination of hardware isolation features and COVH support is necessary to
 guard access to this state while still ultimately giving the OS/VMM control over
 resource management.
 
@@ -568,17 +574,17 @@ isolating guest interrupt file CSR state from the OS/VMM.
 Two fundamental operations must be supported by the TSM in order to enable the
 use of the IMSIC or MRIFs for TVM virtual harts:
 
-*Binding* a TVM virtual hart to an IMSIC guest interrupt file on a physical CPU,
+* *Binding* a TVM virtual hart to an IMSIC guest interrupt file on a physical CPU,
 migrating any interrupt state from the virtual hart's MRIF.
 
-*Unbinding* a TVM virtual hart from an IMSIC guest interrupt file and
+* *Unbinding* a TVM virtual hart from an IMSIC guest interrupt file and
 migrating interrupt state to an MRIF.
 
 If MRIFs are not supported by the hardware then TSM must additionally support
 one more operation to allow TVM virtual hart migration from one physical hart to
 another:
 
-*Rebinding* a TVM virtual hart to an IMSIC guest interrupt file on a physical
+* *Rebinding* a TVM virtual hart to an IMSIC guest interrupt file on a physical
 CPU, migrating any interrupt state from the virtual hart's previous IMSIC guest
 interrupt file.
 
@@ -727,7 +733,7 @@ and non-confidential, may allow the VMM to grant the confidential memory to
 another TVM or reclaim all memory granted to the TVM via
 `sbi_covh_reclaim_pages()` which will verify the TSM hgatp mapping and tracking
 for the page and restore it as a VMM-available page to grant to a
-non-confidential VM. This reclaim TSM operation:
+non-confidential VM. TSM memory reclaim operation:
 
 * Verifies that the PAs referenced are either Non-confidential (No-operation) or
 Confidential-Unassigned state.