[[threatmodel]]
=== Adversary Model

_Unprivileged Software adversary -_ This includes software executing in
U-mode managed by S/HS/M-mode system software. This adversary can access
U-mode CSRs, process/task memory, CPU registers in the process context
managed by system software. With user space I/O an Unprivileged software
adversary may also have ability to submit requests to I/O devices made
available by system software for U-mode access.

_System Software adversary_ - This includes system software executing in
S/HS/VS modes. Such an adversary can access S/HS/VS privileged CSRs,
assigned system memory, CPU registers, IOMMU(s) and IO devices.

_Startup Software adversary_ - This includes system software executing in
early/boot phases of the system (in M-mode), including BIOS, memory
configuration code, device option ROM/firmware that can access system
memory, CPU registers, IOMMU(s), IO devices and platform configuration
registers (e.g., address range decoders, SoC fabric configuration, etc.).

_Non-invasive Hardware adversary_ - This includes adversaries that can use
non-invasive (requiring no physical change to the target hardware) attacks
such as bus interposers to snoop on memory and/or device interfaces,
voltage and/or clock glitching, observe electromagnetic and other radiation,
analyze power usage through instrumentation/tapping of power rails, etc.
which may then give the adversary the ability to tamper with data in use.

_Invasive Hardware adversary_ - This includes adversaries that can use
invasive hardware attacks, with unlimited physical access to the devices,
and use mechanisms to tamper-with/reverse-engineer the hardware TCB e.g.,
extract keys from hardware, using capabilities such as scanning electron
microscopes, fib attacks etc.

_Side/Covert Channel Adversary_ - This includes adversaries that may
leverage any explicit/implicit shared state (architectural or
micro-architectural) to leak information across privilege boundaries via
inference of characteristics from the shared resources (e.g. caches, branch
prediction state, internal micro-architectural buffers, queues). Some
attacks may require use of high-precision timers to leak information. A
combination of system software and hardware adversarial approaches may be
utilized by this adversary.

=== Threat Model

T1: Loss of confidentiality of TVMs and TSM memory via in-scope adversaries
that may read TSM/TVM memory via CPU accesses

T2: Tamper/content-injection to TVM and TSM memory from in-scope
adversaries that may modify TSM/TVM memory via CPU side accesses

T3: Tamper of TVM/TSM memory from in-scope adversaries via software-induced
row-hammer attacks on memory

T4: Malicious injection of content into TSM/TVM execution context using
physical memory aliasing attacks via system firmware adversary

T5: Information leakage of workload data via CPU registers, CSRs via
in-scope adversaries

T6: Incorrect execution of workload via runtime modification of CPU
registers, CSRs, mode switches via in-scope adversaries

T7: Invalid code execution or data injection/replacement via G-stage
paging remap attacks via system software adversary

T8: Malicious asynchronous interrupt injection or dropped leading to
information leakage or incorrect execution of the TEE

T9: Malicious manipulation of time read from the virtualized time CSRs
causing invalid execution of TVM workload

T10: Loss of Confidentiality via DMA access from devices under adversary
control e.g. via manipulation of IOMMU programming

T11: Loss of Confidentiality from devices assigned to a TVM. Devices bound
to a TVM must enforce similar properties as the TEE hosted on the platform.

T12: Content injection, exfiltration or replay (within and across TEE
memory) via hardware approaches, including via exposed interface/links to
other CPU sockets, memory and/or devices assigned to a TVM

T13: Downgrading TEE TCB elements (example TSM-driver, TSM) to older
versions or loading Invalid TEE TCB elements on the platform to enable
confidentiality, integrity attacks

T14: Leveraging transient execution side-channel attacks in TSM-driver,
TSM, TVM, host OS/VMM or non-confidential workloads to leak confidential
data e.g. via shared caches, branch predictor poisoning, page-faults.

T15: Leveraging architectural side-channel attacks due to shared cache and
other shared resources e.g. via prime/probe, flush/reload approaches

T16: Malicious access to ciphertext with known plaintext to launch a
dictionary attack on TCB components to extract confidential data.

T17: Tamper of TVM state during migration of a TEE workload assets within
the platform or from one platform to another.

T18: Forging of attestation evidence and sealed data associated with a TVM.

T19: Stale TLB translations (for U/HS mode or for VU/VS) created during TSM
or TVM operations are used to execute non-TCB code in the TVM (or consume
stale/invalid data)

T20: Isolation of performance monitoring and/or debug state for a TVM
leading to information loss via performance monitoring events/counters and
debug mode accessible information.

T21: A TVM causes a denial of service on the platform

[NOTE]
====
This threat model is not an exhaustive list and will be updated (via the RISC-V
Security Model specification <<R21>>) on a regular basis as attacks evolve.
====

=== Scope

This specification describes the threats that a system implementing CoVE should
address, however, it does not prescribe the scope of mitigations; instead it
focusses on mitigations enabled via the COVH/G interface and the use
of the RISC-V ISA (and extensions such as Smmtt). This specification also
provides recommendations that implementations of this reference CoVE
architecture must address per their chosen scope of adversaries from the list of
adversaries discussed above, and what performance/security trade-offs they
accept. For threats from any adversaries, implementations may choose to mitigate
threats using additional platform capabilities as needed. For all scenarios
though, denial of service by TVMs must be prevented. At the same time, denial of
service by non-TCB software (e.g. in a hosting supervisor domain) is considered
out of scope.

[[design_survey]]
=== TVM Security Requirements to address threat model

|===
| *Category*  |  *Security Criteria*  |  *CoVE Requirement* |  *Example methods
 to meet requirement* | *Description / Example* | *RVI normative or
non-normative Reference*

| Memory Assignment | Ability to make memory confidential or non-confidential |
Required | MMU, MPU, MTT | Confidential memory should be dynamically allocated/
unallocated as required | RISC-V Priv. ISA, Supervisor Domains (Sdid, Smmtt)

| TEE CPU State Protection | State Isolation | Required | Priv. levels (M,S,HS,
U) and Execution context (ASID, VMID, SDID) | Prevent non-TCB components from
arbitrarily accessing/modifying TEE CPU state | Priv ISA w/ virtual memory
system, Supervisor Domains (Sdid, Smmtt)

| Memory Confidentiality | Memory isolation (read) | Required | cryptography
 and/or MMU, MPU, MTT extension | Prevent non-TCB components from reading
TEE memory | Priv ISA w/ virtual memory system, Supervisor Domains (Smmtt)

| Memory Confidentiality | Cipher text read prevention | Required | cryptography
 and/or MMU, MPU, MTT extension | Prevent non-TCB components from accessing
encrypted TEE memory | Svpams (Supervisor Domains)

| Memory Confidentiality | TEE encryption | Implementation-specific |
Cryptography and/or MMU, MPU, MTT extension | TEE memory confidentiality
against logical attacks via MMU; additionally address physical attacks via
cryptography. If cryptography used, TEE should have a unique encryption key;
each TEE VM may may also have one or more unique keys. Also see related
requirements around ciphertext disclosure and memory integrity  | Svpams
(Supervisor Domains)

| Memory Confidentiality | Memory encryption strength | Implementation-specific
| cryptography  | Encryption algorithm and key strength | Security Model

| Memory Confidentiality | Number of encryption keys | Implementation-specific |
cryptography | Number of TEE keys supported | Security Model

| Memory Integrity | Memory integrity against SW attacks | Required | MMU, MPU,
MTT | Prevent SW attacks such as remapping aliasing replay corruption etc. |
CoVE ABI

| Memory Integrity | Memory integrity against HW attacks | Implementation
specific | cryptography and/or MMU, MPU, MTT extension | Prevent HW attacks
DRAM-bus attacks and physical attacks that replace TEE memory with tampered /
old data | Security Model

| Memory Integrity | Memory isolation (Write exec) | Required | cryptography
and/or MMU, MPU, MTT | Prevent TEE from executing from normal memory; Enforce
integrity of TEE data on writes | Supervisor Domains (Sdid, Smmtt)

| Memory Integrity | Rowhammer attack prevention | Implementation-specific |
cryptography and/or memory-specific extension | Prevent non-TCB components from
flipping bits of TEE memory | Security Model

| Shared Memory | TEE controls data shared with non-TCB components | Required |
cryptography and/or MMU, MPU, MTT | Prevent non-TCB code from exfiltrating
information without TEE consent/opt-in | Supervisor Domains (Sdid, Smmtt)

| Shared Memory | TEE controls data shared with another TEE | Implementation
specific | cryptography and/or MMU, MPU, MTT | Ability to securely share memory
with another TEE | Supervisor Domains (Sdid, Smmtt, Svpams)

| I/O Protection | DMA protection from non-TCB-admitted devices | Required | DMA
access-control e.g. IOPMP, IOMTT, IOMMU | Prevent non-TCB peripheral devices
from accessing TEE memory | See CoVE-IO <<R22>>, IOMMU, Supervisor Domains
(IOMTT)

| I/O Protection | Trusted I/O from devices admitted into the TCB of a TVM |
Implementation-specific | Device attestation, Link protection, IOMMU |
Admission control to bind devices to TEEs | See CoVE-IO <<R22>>, IOMMU,
Supervisor Domains (IOMTT)

| Interrupts | Trusted (no spoofing/tampering/dropped) Interrupts | Required |
Secure interrupt files, MMU, MPU, MTT | Prevent IRQ injections that violate
priority or masking | Supervisor Domains (Smsdia) w/ AIA

| Secure Timetamp | Trusted timestamps | Required | Confidential supervisor
domain qualifier for CSR accesses | Ensure TEE have consistent timestamp view |
Supervisor Domains (Sdid)

| Debug & Profile | Trusted performance monitoring unit data | Required |
Confidential supervisor domain context switch of perf. mon. counters  |
Ensure TEEs get correct PMU info; prevent data leakage due to PMU information
(fingerprint attacks) | Supervisor Domains (Secure Debug)

| Debug & Profile | Secure External Debug support | Required | Confidential
supervisor domain qualifier for External debug controls | Support debug trigger
registers for TVM | Supervisor Domains (Secure Debug)

| Debug & Profile | Authenticated debug (Production device) | Required |
Authorize debug via TEE RoT | Ensure hardware debug prob (e.g., JTAG SWD) is
disabled in production | Supervisor Domains (Secure Debug)

| Availability | TVM DoS Protection | Required | VMM retains ability to
interrupt TVM | Prevent TVM from refusing to exit | Supervisor Domains

| Availability | VMM DoS Protection | Implementation-specific | Not in scope
for CoVE | Prevent non-TCB hosting components from denying service to a TVM |
Not in scope

| Side Channel | Address mapping caches (controlled side channel) | Required
| Supervisor domain Id, MMU/MPU, MTT | HW/SW TCB should use
tagging/ partitioning/ flushing techniques to address those types of side
channels due to temporal/spatial shared resources | Supervisor Domains,
Security Model

| Side Channel | Transient-execution attack (TEA) side channels |
Implementation-specific | * Bounds check bypass TEA and variants - should be
addressed by TVM software using apropos synchronization. TCB SW should use
synchronization to isolate TCB code from non-TCB code.
* Branch target injection TEA and variants - should be addressed by TCB SW via
flushing across privilege boundaries to remove untrusted state injected by
non-TCB software
* Speculative store bypass TEA and variants - should be addressed by TCB HW
via synchronization/barriers to prevent speculative execution of memory reads
which may allow unauthorized disclosure of information.
| Implementations should mitigate attacks such as these spectre variants (In
practice, it is difficult to defend against such attacks in advance) |
Supervisor Domain Id, Addtl. Recommendations in Security Model

| Side Channel | Control channels, single-step/zero-step attacks | Required |
leverage HW/SW TCB mechanisms to enforce restrictions on single-stepping
or zero-stepping via use of state flushing/barriers, entropy defenses and
detection mechanisms. | Prevent interrupt/exception injection
(combined with cache side channel to leak sensitive data) | Security Model

| Side Channel | Architectural cache side channel | Implementation-specific  |
cache partitioning-based defenses | Prevent shared resource contention,
e.g. attacks such as prime probe | Security Model

| Side Channel | Architectural timing side channel | Implementation-specific  |
data independent execution latency (DIEL) operations, uArch state flushing |
Leveraging data dependency timing channels | Security Model

| Secure and measured boot | Establishes root of trust in support of attestation
| Required | RoT unique trust chain for TEE TCB | Enforcing initial firmware
authorization and versioning | CoVE ABI, Security Model

| Attestation | Remote attestation | Required | HW-RoT-rooted PKI (trust
assertions) via Internet | Prevent fake hardware and software TCB; Prevent
non-TCB hardware debugging in production. | CoVE ABI, Security Model

| Attestation | Mutual attestation | Implementation-specific | S/U mode  |
Attestation to another TEE on the same platform | CoVE ABI, Security Model

| Attestation | Remote mutual attestation | Required | Internet |  Attestation
to a relying party on a different platform. Requires provisioning of the TEEs
to act as delegated relying parties | CoVE ABI, Security Model

| Attestation | Local attestation | Implementation-specific | Sealing |
Verification of attestation by TCB | Future CoVE ABI, Security Model

| Attestation | TCB versioning (and updates) | Required | Mutable firmware where
 TVM has to opt-in at startup if TCB updates are allowed while the TVM is
 executing - HW TCB then enforces lower TCB elements are updatable
 (with apropos controls like security version enforced) to enforce the
 opt-in policy. | Allow TCB updates - Prevent TCB rollback | CoVE ABI,
 Security Model

| Attestation | TCB composition for confidential computing | Required |  Single
root of trust for measurement and reporting | Malicious components introduced in
the TCB | CoVE ABI, Security Model

| Attestation | Dynamic vs Static Attestation interop (between platform TCB and
TEE TCB) - enforce isolation of the entire trust chain | Required | TEE TCB
should not be affected by other TCB reporting chains. TEE TCB is separately
reportable and recoverable. | Malicious host tampers with TEE TCB or reporting
chain | CoVE ABI, Security Model

| Attestation | TCB transparency (and auditability) | Implementation-specific |
Mutable firmware | TCB elements reviewable | CoVE ABI, Security Model

| Attestation | Sealing | Implementation-specific | HW Rot sealing keys per TVM
| Binding of secrets to TEEs | CoVE ABI, Security Model

| Operational Features | TVM Migration | Implementation-specific | Secure
migration of TEEs | Malicious host tampers with TVM assets during migration |
Future CoVE ABI

| Operational Features | TVM Nesting | Implementation-specific |  Nested TEE
Workloads | Malicious host tampers with nested VMM policies | Future CoVE ABI

| Operational Features | Memory introspection | Implementation-specific |
Interoperability with security features for TVM workload | Unauthorised security
 TVM | Future CoVE ABI

| Operational Features | QOS interoperability | Implementation-specific |
Interoperability with QoS features for TVM workload | Malicious host uses QoS
capabilities as a side-channel | Security Model

| Operational Features | RAS interoperability | Implementation-specific |
Interoperability with RAS features for TVM workload | Malicious host uses RAS
capabilities as a side-channel or to cause integrity violations | Security Model
|===
