Merge pull request #75 from gdhh/main

Broaden the specification's scope to embedded systems with simpler hardware and reduced functionalities

specification/appendix_d.adoc

@@ -0,0 +1,86 @@
+[[appendix_d]]
+== Appendix D: M-mode TSM based deployment model
+
+This deployment model targets high-assurance systems whose design might be constrained 
+by real-time and formal verification requirements. It trade offs a feature-rich design supporting 
+dynamic resource allocation, for simpler implementation, where the correctness can be formally verified.
+
+[id=dep3]
+[caption="Figure {counter:image}"]
+[title= ": M-mode TSM based deployment model for CoVE"]
+image::img_11.png[align=center]
+
+=== Overview
+<<dep3>> shows that the deployment model supports a single confidential supervisor domain in which 
+the TSM runs along with the TSM driver in the M-mode. This single confidential supervisor domain can run multiple 
+TVMs that are isolated from each other using the MMU, i.e., G-stage page tables managed by TSM. TSM isolates the 
+hosting supervisor domain (i.e., OS/VMM and non-confidential applications and VMs) from the confidential supervisor 
+domain (TSM and TVMs) using a hardware memory isolation mechanism, like PMP. 
+The Supervisor Domain Access Protection (Smmtt) extension is therefore not required in this model but not precluded. 
+IO accesses to confidential memory must be prevented, for example, with IOPMP.
+
+[NOTE]
+====
+Since the TSM is not required to run in the HS-mode, this deployment model supports systems that emulate the 
+hypervisor extension or run TVMs and OS/VMM in S-mode. The latter requires use of a hardware memory isolation mechanism
+that enforces memory accesses to confidential memory while being only controlled by the TSM, e.g., PMP. 
+====
+
+=== Static memory partitioning
+The deployment model proposes static partitioning of memory into confidential and non-confidential to simplify 
+formal reasoning about the correctness of the TVM execution and isolation. TSM performs this paritioning early 
+during the boot of the platform, resulting in the following advantages: (1) simplified formal reasoning about the 
+ownership of memory, (2) attestation that covers static system configuration (e.g., values of PMP registers), 
+(3) reduced attack surface between OS/VMM and TSM due to narrower ABI. A possible negative consequence of 
+static partitioning is underutilization of resources. Specifically, confidential memory created at platform
+initialization might be larger than the required amount of memory utilized by TVMs and the TSM during runtime. 
+Lack of the conversion mechanism of confidential memory pages to non-confidential memory (enabled for example by Smmtt) 
+prevents the hosting supervisor domain (OS/VMM, applications, and VMs) from using the memory over-provisioned by 
+the confidential supervisor domain (TSM, TVMs).
+
+=== TVM creation
+To reduce the complexity of the TSM implementation, the TSM creates a TVM as a result of a single operation triggered with 
+the `sbi_covh_promote_to_tvm()` call. Specifically, OS/VMM initializes and starts a regular VM, which early during the 
+boot process requests to be promoted to a TVM. This call traps in the OS/VMM and is reflected to the TSM, which copies 
+VM's data, the page table configuration, and the vCPU state into confidential memory. If the request fails, the promotion 
+of a VM to a TVM fails and error is returned to the VM. When the request succeeds, OS/VMM marks the VM as a TVM, 
+so that it can then properly resume its execution via TSM.
+
+=== Local attestation
+Embedded systems might operate without access to a network, which prevents use of remote attestation. For this 
+reason, this deployment model also supports local attestation, in which the TSM attests to the integrity of the TVM image 
+during its creation and allows its creation only when it contains a specfic `TVM attestation payload` (TAP). This 
+payload carries a cryptographic proof issued with the expected attestation key specific to the TSM integrity 
+and platform configuration. The pointer to TAP is passed in a call to promote a VM to a TVM. If it is zero, 
+then remote attestation is used, otherwise local attestation is used. Local attestation is strongest when it is hardware enforced.  
+
+Attestation for embedded systems utilizes one or both of the following properties:
+
+. The embedded platform must be able to verify that the TVM is authorized to run on the platform. 
+. The TVM must be able to verify that the configuration of the hardware platform is acceptable/correct.
+
+Separate mechanisms may be used to achieve these goals.
+
+==== TVM Authorization
+The TSM must have a list of public keys of those authorized to sign VMs (TVMs) for execution on the platform. The attestation payload associated with the TVM will be
+signed with a private key. When the VM is being promoted to a TVM, TSM checks the signature inside the TAP. 
+If the signature is not valid, the TSM will not convert the VM and will terminate execution of the
+VM. The method for provisioning these public keys into the TSM is outside the scope of this specification.
+
+==== Verifying Platform configuration
+When the creator of the (authorized) TVM does not want it to execute on improperly configured or unauthorized hardware, there should be a mechanism supported by hardware (and firmware) for verification. 
+Assuming presence of the hardware root-of-trust for measurement and hardware root-of-trust for storage, the VM can be created with an encrypted disk and the key that is used to decrypt the disk can be sealed to the measurments of the platform. 
+The creator of the VM using the specifications for the platform decides what values are required in order for the key to be released. 
+When the request to promote VM to a TVM is called and local attestation is successful, the TSM unseals the key with help of the hardware root-of-trust. At the point when the TVM needs to decrypt its disk (e.g., for mounting the filesystem), the TVM utilizes an ABI call (`covg_retrieve_secret()`) to retrieve the decryption key from the TSM.
+
+=== Further recommendations
+Embedded systems with real-time requirements must have a fixed upper bounded execution time. This requires determining 
+the maximal number of instructions that can execute between TVM context switches. From this reason, this deployment model 
+recommends an uninterruptible TSM. <<depd2>> shows this operation mode, in which TSM running in M-mode exposes COVH and 
+COVG ABI to OS/VMM and TVM, respectively. VM ECALLs trap directly to TSM due to the `medeleg` configuration and all 
+interrupts during TVM execution trap in TSM due to the `mideleg` configuration. 
+
+[id=depd2]
+[caption="Figure {counter:image}"]
+[title= ": TSM operation"]
+image::img_12.png[align=center]

specification/attestation.adoc

@@ -3,16 +3,21 @@
 [[attestation]]
 == TVM Attestation and Measurements
 
-The CoVE TVM attestation framework allows for CoVE workload owners to assert
-the trustworthiness of the hardware and software environment their workload is
-running in.
+The CoVE TVM attestation framework allows CoVE workload owners to assert
+the trustworthiness of the hardware and software environment in which their workload is
+running. This framework allows for *remote* and *local attestation*.
 
-Attestation relies on the ability for the SoC to generate a cryptographic evidence
+Remote attestation relies on the ability for the system on chip (SoC) to generate a cryptographic evidence
 for a workload executing in a CoVE TVM. The workload executing in a TVM may
-request this cryptographic evidence to relay to a remote relying party which can
-then verify that the evidence is valid (per some appraisal policy), and thus attest
-to the trustworthiness of the TVM. The relying party can then accept to release
-secrets or attestation result tokens back to the trusted workload.
+request this cryptographic evidence to relay to a remote relying party which
+verifies that the evidence is valid (per some appraisal policy). If valid, the 
+evidence attests to the trustworthiness of the TVM, so that the relying party 
+can release secrets or attestation result tokens to the TVM.
+
+Local attestation is a model where the TVM presents cryptographic evidence to the TSM 
+that enables the TSM to release a secret to the TVM if it is authorized to
+run on the platform. This form of attestation meets the needs of systems that
+have limited or no access to the network.
 
 This section describes the CoVE attestation evidence content, format and
 generation interface.
@@ -65,7 +70,7 @@ The TCB elements for each of them is summarized in the following table:
 .4+.^|Platform
     <| HW RoT for boot, measurement and storage
  .4+<| All M-mode firmwares, including the TSM-driver
-    <| All CPU hardware logic, including MMU and caches
+    <| All CPU hardware logic
     <| All SoC subsystems, including memory confidentiality, integrity and replay-protection for volatile memory
     <| IOMMU and translation agents
 
@@ -88,7 +93,7 @@ measurements and a runtime one.
 TVM initial measurements are generated from the CoVE workload TCB elements
 involved in the TVM construction. Any TCB element that directly or indirectly
 supports a TVM must be measured into the TVM initial measurement registers. Once
-a TVM is finalized, i.e. after the `sbi_tee_host_finalize_tvm()` TH-ABI is
+a TVM is finalized, i.e., after the `sbi_tee_host_finalize_tvm()` TH-ABI is
 called, the TVM initial measurements must no longer be extended.
 
 Each TVM's initial measurements are stored in dedicated measurement registers and
@@ -141,7 +146,7 @@ CoVE implementation may look like the following table:
 
      | 5
      | TVM Configuration
-    <| TVM Entry Point and Initial Arguments
+    <| TVM Entry Point, Initial Arguments, and the vCPU state
      | TSM
 |===
 
@@ -162,7 +167,7 @@ The TVM measurement extension interface is exposed through the optional TG-ABI
 
 [NOTE]
 ====
-if an implementation uses UEFI firmware to initialize the CoVE TVM guest
+If an implementation uses UEFI firmware to initialize the CoVE TVM guest
 environment, then refer to UEFI specification <<R23>> chapter 38 on confidential
 computing for UEFI ABI related to runtime measurement extension and
 event log creation.
@@ -172,10 +177,10 @@ event log creation.
 
 All above described TCB elements measurements are added to an attestation
 evidence and then reported to relying parties. The attestation mechanism
-and protocol that take place between the attester (i.e. the TVM) and the
-remote attestation service are out of this document scope.
+and protocol that take place between the attester (i.e., the TVM) and the
+remote attestation service are out of the scope of this document.
 
-In this section we describe the high level attestation model for CoVE,
+In this section, we describe the high level model of remote attestation for CoVE,
 together with the attestation evidence content, format and generation process.
 
 ==== Model
@@ -222,13 +227,13 @@ TCB layer measurements:
 [.center]
 [stem]
 ++++
-CDI_{0} = KDF(UDS_{Len},\ UDS\ ||\ H_{alg}(Meas(TCB_{0}))
+CDI_{0} = KDF(UDS_{Len},\ UDS\ ||\ H_{alg}(Meas(TCB_{0})))
 ++++
 :stem: asciimath
 [.center]
 [stem]
 ++++
-CDI_{N} = KDF(CDI_{Len},\ CDI_{N-1}\ ||\ H_{alg}(Meas(TCB_{N}))
+CDI_{N} = KDF(CDI_{Len},\ CDI_{N-1}\ ||\ H_{alg}(Meas(TCB_{N})))
 ++++
 
 Asymmetric key pairs can be derived from a CDI in order to generate the
@@ -649,9 +654,9 @@ The TVM identity claim value is a `sbi_tee_host_finalize_tvm()` provided
 argument. It is an optional claim and is not included in the TVM token when
 the TVM identity argument is set to 0.
 
-It is used by the host TVM creator (e.g. the host VMM) to bind a TVM to an
+It is used by the host TVM creator (e.g., the host VMM) to bind a TVM to an
 identity or more generically a specific piece of data (e.g. an Attestation
-Service public key, a configuration blob, etc) through its hash value.
+Service public key, a configuration blob, etc.) through its hash value.
 
 TVM identity allows for untrusted hosts to provide a TVM with unmeasured but
 attestable pieces of data. A Relying Party can then verify the TVM measurements

specification/glossary.adoc

@@ -62,6 +62,8 @@ that hosts multiple mutually distrusting software owned by different tenants.
 
 | MTT | Memory Tracking Table (MTT).
 
+| Relying party | An entity that depends on the validity of information about another entity, typically for purposes of authorization cite:[RATS].
+
 | 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
@@ -90,6 +92,8 @@ 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.
 
+| TAP | TVM attestation payload (TAP) is a block of memory in a VM that TSM uses to perform local attestation as part of promoting a VM to a TVM.
+
 | 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. 
 
@@ -100,14 +104,15 @@ 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.
+boundary is the package. In a multi-socket system the Hardware TCB extends across
+the socket-to-socket interface, and is managed as one system TCB. The software TCB may  also extends
+across multiple sockets.
 
 | TEE | Trusted execution environment (TEE) is a set of hardware and software mechanisms that allow creating attestable and isolated execution environment.
 
-| TVM | TEE VM (TVM) also known as Confidential VM. It is a VM instantiation of an confidential workload.
+| TVM | TEE VM (TVM) also known as Confidential VM. It is a VM instantiation of a confidential workload.
 
-| Virtual Machine (VM) | Guest operating system hosted by a VMM.
+| VM | Virtual Machine (VM) is a guest operating system hosted by a VMM.
 
 | VMM | Virtual machine monitor (VMM) is used interchangeably with the term hypervisor in this document.
 

specification/header.adoc

@@ -72,4 +72,5 @@ include::sbi_cove.adoc[]
 include::appendix_a.adoc[]
 include::appendix_b.adoc[]
 include::appendix_c.adoc[]
+include::appendix_d.adoc[]
 include::bibliography.adoc[]

specification/intro.adoc

@@ -7,7 +7,7 @@ a scalable Trusted Execution Environment (TEE) for hardware virtual-machine-base
 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,
-devices and other software outside the TCB.  Admitting devices into the TCB of CoVE
+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