Merge pull request #72 from wojciechozga/main

Pass over the release candidate version of the spec

specification/contributors.adoc

@@ -8,4 +8,5 @@ Andrew Bresticker, Andy Dellow, Atish Patra, Atul Khare, Beeman Strong,
 Christian Bollis, 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, Vedvyas Shanbhogue, Yann Loisel
+Ravi Sahita (Editor), Rob Bradford, Samuel Ortiz, Vedvyas Shanbhogue, 
+Wojciech Ozga, Yann Loisel

specification/glossary.adoc

@@ -2,76 +2,78 @@
 == Glossary
 
 |===
-| Hypervisor or Virtual Machine Monitor (VMM) | HS mode software
-that manages Virtual Machines by virtualizing hart, guest physical memory and
-IO resources. This document uses the term VMM and hypervisor interchangeably
-for this software entity.
 
-| VM | Virtual Machines hosted by a VMM
+| AIA | Advanced interrupt architecture (AIA) is an architecture for handling interrupts.
 
-| Host software | All software elements including type-1 or type-2 HS-mode VMM
-and OS; U mode user-space VMM tools; ordinary VMs hosted by the VMM that
-emulate devices. The hosting platform is typically a multi-tenant platform
-that hosts multiple mutually distrusting Tenants.
-
-| Tenant software | All software elements including VS-mode guest kernel
-software, and guest user-space software (in VU-mode) that are deployed
-by the workload owner (in a multi-tenant hosting environment).
-
-| Trusted Computing Base (TCB); Also, System/Platform TCB | The hardware,
-software and firmware elements that are trusted by a relying party to
-protect the confidentiality and integrity of the relying parties' workload
-data and execution against a defined adversary model. In a system with
-separate processing elements within a package on a socket, the TCB
-boundary is the package. In a multi-socket system the TCB extends across
-the socket-to-socket interface, and is managed as one system TCB.
+| ABI | Application binary interface (ABI).
 
-| Application Processor (AP) | APs can support commodity operating systems,
+| AP | Application processors (AP)s can support commodity operating systems,
  hypervisors/VMMs and applications software workloads. The AP subsystem
  may contain several processing units, on-chip caches, and other controllers
 for interfacing with memory, accelerators, and other fixed-function logic.
 Multiple APs may be used within a logical system.
 
-| RISC-V Supervisor Domains | RISC-V privileged architecture <<R0>> defines
-the S-mode for execution of supervisor software. S-mode software may optionally
-enable Hypervisor extension to host virtual machines. Typically, there is a
-single supervisor domain of execution with access to all physical memory.
-*Supervisor Domains* <<R20>> is a RISC-V privileged architecture extension to
-support physical address space (memory and devices) isolation for more than one
-supervisor domain. Supervisor domains enable the reduction of the supervisor
-Trusted Computing Base (TCB), with differential access to memory and other
-platform resources e.g. as used in this Confidential VM Extension (CoVE) spec.
+| Attestation | The process by which a relying party can assess the
+security posture of the confidential workload based on verifying a set of
+HW-rooted cryptographically-protected evidence.
+
+| CDI | Compound device identifier (CDI) is the value that represents the hardware,
+software and firmware combination measured by the TCB elements transitively.
+A CDI is the output of a DICE <<R2>> and is passed to the entity which is
+measured by the previous TCB layer. The CDI is a secret that may be
+certified to use for attestation protocols.
 
-| Confidential Computing | The protection of data in use by performing
-computation in a Hardware-based and Attestable Trusted Execution Environment.
+| Confidential Computing | A computing paradigm that protects data in use by performing
+computation in a hardware-based, attested TEE.
 
-| Confidential VM Extension (CoVE)| The set of non-ISA RISC-V ABI extensions
+| CoVE | Confidential VM extension (CoVE) is the set of non-ISA RISC-V ABI extensions
 defined in this specification that enables confidential computing on RISC-V
 platforms. In some deployment models, the CoVE ABI leverages the RISC-V ISA
 extensions specified in the RISC-V Supervisor Domains specification <<R20>>.
-CoVE is a Trusted Execution Environment ABI for Application Processors. A
+CoVE is a Trusted Execution Environment (TEE) ABI for Application Processors (APs). A
 supervisor domain that provides HW-isolation for workload data assets when in
 use (user/supervisor code/data) and provides HW-attestable confidentiality and
 integrity protection against specific attack vectors per a specified
 adversary and threat model.
 
-| TVM | TEE or Confidential VM - A VM instantiation of an confidential workload
-
 | Confidential application or library | A user-mode application or
 library instantiation in a TVM. The user-mode application may be supported
 via a trusted runtime. The user-mode library may be hosted by a surrogate
 process runtime.
 
-| Attestation | The process by which a relying party can assess the
-security posture of the confidential workload based on verifying a set of
-HW-rooted cryptographically-protected evidence.
+| Confidential memory | Memory that is subject to access-control,
+confidentiality and integrity mechanisms per the threat model for use in the
+CoVE system. Confidential memory may also be used by non-TCB/
+hosting software with appropriate TCB controls on the configuration,
+e.g., a separate key used for TCB and non-TCB elements.
 
-| TEE Security Manager (TSM) | HS-mode software module that acts as
-the trusted (in TCB) intermediary between the VMM and the TVM. This
-module extends the TCB chain on the CoVE platform.
+| Host software | All software elements including type-1 or type-2 HS-mode VMM
+and OS; U-mode user-space VMM tools; ordinary VMs hosted by the VMM that
+emulate devices. The hosting platform is typically a multi-tenant platform
+that hosts multiple mutually distrusting software owned by different tenants.
+
+| Hypervisor | is software running in HS-mode that manages virtual machines (VMs) by virtualizing hart, guest physical memory and input/output (IO) resources. 
+
+| IMSIC | Incoming message signaled interrupt controller (IMSIC).
+
+| MMIO | Memory mapped I/O (MMIO).
+
+| MMU | Memory management unit (MMU).
+
+| MTT | Memory Tracking Table (MTT).
+
+| RISC-V Supervisor Domains | RISC-V privileged architecture <<R0>> defines
+the S-mode for execution of supervisor software. S-mode software may optionally
+enable the Hypervisor extension to host virtual machines. Typically, there is a
+single supervisor domain of execution with access to all physical memory.
+*Supervisor Domains* <<R20>> is a RISC-V privileged architecture extension to
+support physical address space (memory and devices) isolation for more than one
+supervisor domain. Supervisor domains enable the reduction of the supervisor
+Trusted Computing Base (TCB), with differential access to memory and other
+platform resources, e.g., as used in this specification.
 
-| RoT | Isolated HW/SW subsystem with an immutable ROM firmware and
-isolated compute and memory elements that form the Trusted Compute Base
+| RoT | Root of trust (RoT) is the isolated hardware/software subsystem with an immutable ROM firmware and
+isolated compute and memory elements that form the Trusted Compute Base (TCB)
 of a TEE system. The RoT manages cryptographic keys and other security
 critical functions such as system lifecycle and debug authorization.
 The RoT provides trusted services to other software on the platform such
@@ -81,31 +83,33 @@ attestation etc. The RoT may be an integrated or discrete element <<R7>>,
 and may take on the role of a Device Identification Composition Engine
 (DICE) as defined in <<R2>>.
 
-| Confidential memory | Memory that is subject to access-control,
-confidentiality and integrity mechanisms per the threat model for use in the
-CoVE system. Confidential memory may also be used by non-TCB/
-hosting software with appropriate TCB controls on the configuration,
-e.g a separate key used for TCB and non-TCB elements.
-
-| SVN | Security Version Number - Meta-data about the TCB components
+| SVN | Security version number (SVN) is the meta-data about the Trusted Compute Base (TCB) components
 that conveys the security posture of the TCB. The SVN is a monotonically
-increasing version number updated when security changes must be reflected in
-the attestation. The SVN is hence provided as part of the attestation
+increasing number that represents TCB's version. It gets increased with TCB updates, causing these updates to be reflected in the attestation. The SVN is hence provided as part of the attestation
 information as part of the evidence of the TCB in use. The SVN is typically
 combined with other meta-data elements when evaluating the attestation
 information.
 
-| CDI | Compound Device Identifier - This value represents the hardware,
-software and firmware combination measured by the TCB elements transitively.
-A CDI is the output of a DICE <<R2>> and is passed to the entity which is
-measured by the previous TCB layer. The CDI is a secret that may be
-certified to use for attestation protocols.
+| TSM | TEE security manager (TSM) is a software module that enforces TEE security guarantees on a platform. It acts as
+the trusted intermediary between the VMM and the TVM. TSM extends the TCB chain on the CoVE platform and is therefore subject to attestation. 
+
+| Tenant software | All software elements owned and deployed by a tenant in a multi-tenant hosting environment. These elements include VS-mode guest kernel and VU-mode guest user-space software.
+
+| TCB; Also, System/Platform TCB | Trusted computing base (TCB) is the hardware,
+software, and firmware elements that are trusted by a relying party to
+protect the confidentiality and integrity of the relying parties' workload
+data and execution against a defined adversary model. In a system with
+separate processing elements within a package on a socket, the TCB
+boundary is the package. In a multi-socket system the TCB extends across
+the socket-to-socket interface, and is managed as one system TCB.
+
+| TEE | Trusted execution environment (TEE) is a set of hardware and software mechanisms that allow creating attestable and isolated execution environment.
 
-| AIA | Advanced Interrupt Architecture
+| TVM | TEE VM (TVM) also known as Confidential VM. It is a VM instantiation of an confidential workload.
 
-| IMSIC | Incoming Message Signaled Interrupt Controller
+| Virtual Machine (VM) | Guest operating system hosted by a VMM.
 
-| MMIO | Memory Mapped I/O
+| VMM | Virtual machine monitor (VMM) is used interchangeably with the term hypervisor in this document.
 
 |===
 

specification/intro.adoc

@@ -3,10 +3,13 @@
 == Introduction
 
 This document describes the Confidential VM Extension (CoVE) interface for
-a scalable Trusted Execution Environment(TEE) for hardware virtual-machine-based
+a scalable Trusted Execution Environment (TEE) for hardware virtual-machine-based
 workloads on RISC-V-based platforms. This CoVE interface specification enables
 application workloads that require confidentiality to reduce the Trusted
-Computing Base (TCB) to a minimal TCB, specifically, keeping the host OS/VMM
-and other software outside the TCB. The proposed specification supports an
+Computing Base (TCB) to a minimal TCB, specifically, keeping the host OS/VMM,
+devices and other software outside the TCB.  Admitting devices into the TCB of CoVE
+TEE VMs is outside the scope of this specification and is described in the CoVE-IO
+specification.
+The proposed specification supports an
 architecture that can be used for Application and Virtual Machine workloads,
-while minimizing changes to the RISC-V ISA and privilege modes.
+while minimizing changes to the RISC-V ISA and privilege modes.

specification/overview.adoc

@@ -4,12 +4,12 @@
 == Architecture Overview and Threat Model
 
 Virtualization platforms are typically comprised of several components including
-platform firmware, host OS, VMM, and the actual payloads that run on them
-(typically in a VM). A monolith Supervisor Domain exists with the host OS/VMM
-including device drivers and services forming the TCB. This model is well
+platform firmware, host OS, VMM, and the actual workload (typically in a VM) that run on them. 
+A monolith Supervisor Domain exists with the host OS/VMM
+including device drivers and services forming the Trusted Computing Base (TCB). This model is well
 established, but the downside is that most platform components are in the TCB.
-This aspect is ill-suited for Confidential Computing workloads that rely on
-HW-Attested Trusted Execution Environments, and strive to minimize the software
+This aspect is ill-suited for confidential computing workloads that rely on
+hardware-attested Trusted Execution Environments (TEEs), and strive to minimize the software
 and hardware TCB.
 
 This specification describes the CoVE architecture which enables a new class
@@ -25,7 +25,7 @@ role as the resource manager (for both legacy VMs and TVMs). The resources
 managed by the hosting supervisor domain (OS/VMM) include memory, CPU, I/O
 resources and platform capabilities to host the TVM workload. The terms
 hosting supervisor domain and OS/VMM are used interchangeably in this
-specification. The underlying isolation mechanisms for supervisor domains
+specification. The underlying memory isolation mechanisms for supervisor domains
 (Smmtt) is agnostic of the number of supervisor domains.
 
 [id=dep1]
@@ -38,8 +38,8 @@ that operates in HS-mode and manages resources granted to it by the Hosting
 Supervisor Domain Manager (the OS/VMM). The Confidential Supervisor Domain
 Manager is called the " *TEE Security Manager* " or *(TSM)* - it acts as the
 trusted intermediary between TEE and non-TEE workloads on the same platform.
-The TSM should have a minimal HW-attested footprint. The TCB (which includes
-the TSM and HW) enforces strict confidentiality and integrity security
+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
 is an M-mode software module (called the " *TSM-driver* ") which isolates the
 Confidential Supervisor Domain from all other Supervisor domains and other
@@ -48,12 +48,12 @@ confidential). The responsibility of the TSM is to enforce the security
 objectives accorded to TEE workloads assigned to that supervisor domain. The
 VMM is expected to continue to manage the security for non-confidential
 workloads, and importantly the resource-assignment and scheduling management
-functions for all workloads (confidential and non-confidential).
+functions for all confidential and non-confidential workloads.
 
-In this scheme, compute resources like memory start off as traditional
+In this scheme, compute resources, such as memory, start off as traditional
 untrusted resources owned by the non-confidential/hosting supervisor domain, and
 are expected to be donated/transitioned to the confidential supervisor domain
-via ABI supported by the TSM. Once the conversion process is complete,
+via application binary interface (ABI) supported by the TSM. Once the conversion process is complete,
 confidential memory may be assigned to one or more TVMs by the TSM.
 A converted confidential resource may be freely assigned to another TVM within
 the same supervisor domain when it is no longer in use. However, an
@@ -71,7 +71,7 @@ are pages that are demand-paged in and are expected to be zero'ed by the TSM to
 prevent attacks from the host software on the TVM. The TSM also enforces that
 the host does not overlap them with existing (present) G-stage mappings for the
 TVM. The non-confidential TVM-defined regions include those for shared-pages and
-MMIO.
+memory-mapped I/O (MMIO).
 
 The TSM implements ABI that are accessed by the OS/VMM in the Hosting Supervisor
 Domain Manager via a *Trusted Execution Environment Interface (TEEI)*. This ABI
@@ -112,25 +112,25 @@ as *COVH* that includes functions to manage the lifecycle of the TVM, such as
 creating, adding pages to a TVM, scheduling a TVM for execution, etc., in an
 OS/platform agnostic manner. The TSM also provides an ABI to the TVM contexts:
 A set of guest ABIs known as *COVG* that enables the TVM workload to request
-attestation functions, memory management functions or paravirtualized IO.
+attestation functions, memory management functions, or paravirtualized IO.
 
 In order to isolate the TVMs from the host OS/VMM and non-confidential VMs,
 the supervisor domains (that contain the TSM state) must be isolated first -
 this is achieved by enforcing isolation for memory assigned to the supervisor
 domain that the TSM occupies - this is called the *TSM-memory-region.* The
 TSM-memory-region is expected to be a static region of memory that holds the TSM
 code and data. This region must be access-controlled from all software outside
-the TCB (e.g. using Smmtt), and may be additionally protected against physical
+the TCB (e.g., using Smmtt), and may be additionally protected against physical
 access via cryptographic mechanisms.
 
-Access to the TSM- memory-region and execution of code from the
+Access to the TSM-memory-region and execution of code from the
 TSM-memory-region (for the TSM ABIs) is enforced in hardware via the maintenance
 of the execution context (ASID, VMID and SDID) maintained per hart. This context
 is enabled per-hart via the TEECALL interface to context switch into the
 confidential supervisor domain context via the TSM-driver and disabled
 via the TEERET interface to context restore to the hosting supervisor domain.
 Access to TEE-assigned memory is allowed for the hart when the access is
-permitted as per the active permissions enforced by the MMU for the supervisor
+permitted as per the active permissions enforced by the memory management unit (MMU) for the supervisor
 domain active on the hart (enforced through Sv and Smmtt for CoVE). This
 per-hart execution context is used by the processor to enforce access-control
 properties on memory accessed by TEE workloads managed by the TSM. The
@@ -141,18 +141,17 @@ TSM functionality should be explicitly limited to support only the security
 primitives to ensure that the OS/VMM and non-confidential VMs do not violate
 the security of the TVMs through the resource management actions of the
 OS/VMM. These security primitives require the TSM to enforce TVM virtual-hart
-state save and restore,  as well as enforcing invariants for memory assigned
-to the TVM (including G-stage translation). The host OS/VMM provides the
-typical VM resource management functionality for memory, IO etc.
+state save and restore, as well as enforcing invariants for memory assigned
+to the TVM, including G-stage translation. The host OS/VMM provides the
+typical VM resource management functionality for memory, IO, etc.
 
-Confidential VMs (managed by a VMM) are shown in figure 1 and Confidential
-applications (managed by an untrusted host OS) are shown in the
-architecture <<dep1a>>. As evident from the architecture, the difference
+<<dep1>> shows Confidential VMs managed by a VMM and <<dep1a>> shows Confidential
+applications managed by an untrusted host OS. 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 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 SW models that map to the VU/VS
-modes of operation are also possible as TEE workloads. Importantly, the HW
+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. Importantly, the hardware
 mechanisms needed for both cases are identical, and can be supported with the
 CoVE ABI.