Support for CoVE's deployment model 3

[wojciechozga]

This PR adds support for the deployment model 3 of the RISC-V CoVE spec. It adds the missing API call in COVH ABI and implementation of single-step TEE VM (TVM) creation. It modifies the architecture-dependent KVM code to support deployment models in which: (1) host runs in HS mode, (2) TEE security monitor (TSM) or hardware do not support RISC-V AIA, (3) TSM or hardware do not support dynamic page conversion.

Promotion to TVM (guest side)
At the guest side, request isolation against the hypervisor early in the kernel boot process only if the kernel was built with the CONFIG_RISCV_COVE_GUEST_PROMOTE command-line kernel parameter. CoVE guest images created in the multi-step creation process should not use this parameter.

Promotion to TVM (host side)
At the host side, preload VM pages into memory, fill the NACL shared memory with boot vcpu state, and reflect the promote_to_tvm() call to the TSM. Support CoVE implementations that do not support dynamic page conversion. A TSM that does not support dynamic page conversion does not require the donation of pages to store VCPU state in confidential memory.

Support sharing pages with a hypervisor in an environment where dynamic page conversion is not supported.
When a single share_memory_region() call for a memory region that contains multiple 4KiB pages fails, execute multiple 4KiB share_memory_region() calls until the request is completed. (See deployment model 3 in the CoVE spec.)

Support the use of NACL in CoVE for KVM running in HS mode.
Utilize the correct NACL features by testing whether a feature required for NACL exploitation in nested virtualized environments is present. If nested virtualization is not present, use only the NACL setup_shared_memory() ABI otherwise use the entire NACL ABI.Mandatory NACL support for CoVE This commit mandates presence of NACL extension for KVM's CoVE support. To support deployments running host in HS or VS mode, KVM checks presence of specific NACL features. Specifically, CoVE deployments with host running in HS mode must implement only NACL setup_shared_memory() and no NACL feature. CoVE deployments with host running in VS mode must, however, implement all required NACL features.

Enable CoVE guests to run in an environment that does not have AIA.
Detect AIA presence by discovering that the TEE security monitor (TSM) implements the SBI COVI extension. If AIA is not present, inject external interrupts using the HVIP register when resuming execution of a virtual processor via the COVH tvm_vcpu_run() call.

TSM Capabilities
Discover TSM capabilities introduced as part of the GetTsmInfo call with the version 0.7 of the CoVE spec.

Local attestation
Support placement of TEE attestation payload inside the Linux kernel image and exposing its address during promotion to TVM.

[wojciechozga]

As discussed on last Monday, we should expose TSM's capabilities to the host. Based on them, the host can provide different behavior when creating and managing TVMs. In this PR, the host recognizes TSM's capabilities based on, for example, presence of COVI extension. Once capabilities become part of the tsm_info structure in the CoVE spec, KVM CoVE implementation should be modified accordingly.

[atishp04]

@wojciechozga : Anup agreed to host the staging repo in kvm-riscv. I think it would better to merge these patches directly there once you update these with the items discussed last time. Wdyt ?

[wojciechozga]

yes, we can do it that way!

[atishp04]

Can you invoke it after sbi_init and riscv_cove_sbi_init so that this can be called only if is_cove_guest is true

[wojciechozga]

The promote call might actually move to different place, i.e., head.S in _start_kernel. Like this, the kernel requests the promotion before it touches the stack or heap, so there is no runtime state associated with the execution. Consequently the TVM's memory at the time of promotion equals the linux kernel image, so integrity measurements are easier to calculate.

The approach presented in this patch was intended to match what OpenPower PEF did. But in such a case we would need to do a few additional tricks (like PEF in powerpc part of Linux kernel) that would unnecessarily complicate the implementation. My team believes that we might try a simpler solution, but I am interested in learning your opinion and the opinion of the community. Guerney and I will present details on local attestation during RV CoVE TG on November 5th.

[wojciechozga]

The commit #fb1b6080a118b70305be6bb1e0243a5e1b119e05 implements the simpler approach to VM promotion, which I mentioned above.

[atishp04]

If you want to convert so early, why not just invoke it from the VMM if the kernel supports it ? The VMM can create a single step or multi-step TVM. It should be even simpler and you don't have to bounce the PROMOTE_TVM ecalls from the TVM->TSM->HOST.

[wojciechozga]

Thank you for your comments and suggestions.

There are a few advantages of implementing promotion inside the kernel that early. (1) TSM can move just kernel+initrd+fdt to confidential memory, keeping entire boot firmware / rom etc out of TCB, (2) proposed solution is then VMM-independent, (3) implementation is relatively simple even though not rich in features, (4) reference measurements are easy to calculate since there is no runtime state we have to care about.

There are alternatives and every solution comes with its own tradeoffs. Doing promotion before the proposed point of time (e.g., in VMM or early firmware) will include firmware in TCB and will be vmm- or firmware-specific. Doing promotion after the proposed time will result in inclusion of runtime state in TCB and will require calculating the measurements of a VM's snapshot at given point of time when promotion occurs.

In OpenPOWER PEF (see powerpc arch code in Linux kernel) we did it also that early in the kernel boot. Specifically inside PROM. The _start procedure (in arch/powerpc/kernel/head_book3s_32.S) calls prom_init, which calls setup_secure_guest (arch/powerpc/kernel/prom_init.c) if the correct boot arg param is set. I am not aware of any PROM-like code in Riscv-dependent code, that is why I placed it directly in arch/riscv/kernel/head.S.

In Secure Execution for IBM Z (see s390 arch code in Linux kernel) we did it differently since the business requirements were different. We wanted to provide confidentiality and integrity of the TVM's Linux kernel and initrd.

[gdhh]

Deployment model 3 is primarily aimed at embedded systems although it can also be used by cloud or other systems. Putting the execution in the kernel as proposed is a minimal code approach. This approach will fit better into the development cycles for embedded systems. The tooling to generate the Attestation Payload will be simpler. There is no need to actually run the VM prior to generating the payload. If the VMM does not support confidential computing the call will fail which is not a problem because no secrets will be exposed because VM will not have access to the key that unlocks its disk. This approach gives the VM creator the ability to lock their TVM to a specific set of hardware. To do this requires that each platform have unique information, such as a serial number, that is incorporated into the attestation. The TVM can be locked to a single platform or a set of platforms, depending on the hardware environment. This is also important for embedded systems.

[atishp04]

@wojciechozga Thanks for sharing the slides for the Nov 5th meeting. I understand the local attestation requirement. I have couple of questions:

1. However, I wanted to understand what type of guest firmware you typically run on an embedded systems ? It can just boot directly similar to what we do it in kvm ?
2. Why it is a problematic to make VMM aware of TAP and pass the TAP to the VMM ? It can be part of the guest image that vmm can load it.

We can discuss the details in Nov 5th call if you like as well.

[wojciechozga]

Guest content is system-specific. It may be a guest-level "bare-metal" application, a directly booted kernel, a full-fledged OS, or a single-tasking system with or without boot firmware. It is the TVM creator's decision on how to structure the TVM, depending on system design requirements. It is important for RISC-V CoVE to enable different use cases, also because of legacy processes to build and certify systems. The TVM owner should decide when and what type of attestation to perform—whether promotion should happen in firmware, kernel, or operating system, and whether it should be local or remote attestation.

Leaving the decision on when to execute the promotion call allows a TVM creator to decide if firmware should be part of the TCB and whether the guest kernel's code should be confidential, among other considerations. For example, if a VM requests promotion during kernel execution, the TSM can exclude rom reset vec and firmware from the TCB. Conversely, if the initial firmware is intended to be part of the TCB and to retrieve a key to decrypt the kernel, promotion occurs in firmware.

Implementing this level of granularity within a VMM presents challenges, as it would require trapping the VM’s execution at specific instructions based on some policy. Moreover, making a VMM aware of the TAP would necessitate modifications to the VMM itself, potentially reducing the solution's portability across various VMM implementations. The proposed separation of concerns simplifies the VMM's role, enabling more flexible development and evolution of the attestation mechanisms within the TVM.

@atishp04, let me know what you think.

[atishp04]

Just to clarify: I was not suggesting to trap any VM's execution at any certain stage and promote it to TVM.
I was suggesting to start the TVM in the single step boot mode at the beginning itself. No change in promote_to_tvm API.

Instead of this path
VM->(promote_to_tvm)->TSM traps and forward ->Host->promote_to_tvm (COVH)->TSM

We can just simply start the TVM. Are there any issue with this execution model ?
VMM->host (start TVM in single_step_mode)

The flexibility you mentioned still exists for anybody to implement in a different way. I was mainly concerned about the odd boot flow for a Linux based TVM. My earlier assumption was a Linux VM can be promoted to TVM at any point during the boot. If it is supposed to promoted right after the boot, VMM may as well tell the host to start a single step TVM. I understand that the firmware needs to be part of the TCB in this case but I am not sure if we need that for this use case.

We will anyways have have VMM modification for CoVE for other models. So adding another ABI for single step booting shouldn't be a issue.

[wojciechozga]

@atishp04 thanks for the explanation.

The current path is different that what you described. The VM traps into Host, which reflects the call to TSM:
VM->(promote_to_tvm VM>KVM ABI)->Host->promote_to_tvm (COVH)->TSM

If I understood correctly, you propose that VMM+Host do the promotion of a Linux VM that hasn't executed yet, right?
VMM->(single_step_mode VMM>KVM ABI)->Host->promote_to_tvm (COVH)->TSM

My understanding is that your motivation to shift promotion call from VM to VMM is that it sounds odd to call promote_to_tvm ABI early in Linux kernel while the same effect could be achieved by doing promotion before the VM execution, right? In Linux kernel's powerpc (Openpower PEF) we promote TVMs the same way as proposed now for risc-v, so within first instructions after entering the Linux kernel code.

I agree that we can call promote_to_tvm before kernel execution (what you propose) but we can also do it during early kernel boot (current proposal) or later during runtime (this will be more like a snapshots of a running system). Starting a TVM in a single-step-mode would be ok for directly boot Linux kernel but would not support use cases with firmware that is not intended to be in TCB. Also, this approach would require modification of every VMM. These are some tradeoffs we can discuss today during the call. Do you know what are the plans for VMM modifications? Do you know which VMMs are expected to get support for CoVE (qemu, kvmtool, firecracker)?

Some other question I have is how could we make a VMM aware of TAP? Should we pass it as an extra argument or should VMM somehow extract TAP address from the VM image? Current approach embeds TAP inside the Linux kernel image and Linux kernel is aware about the TAP's address so it can expose it during the promote call.

[wojciechozga]

@atishp04 thank you for valuable comments and hints. I addressed the comments and pushed the improved version of these patches.

[atishp04]

We can't invoke SBI calls like this without checks. It will just fail if the higher privilege mode system doesn't support it.

[wojciechozga]

Thanks for your comment. This piece of code is compiled only for non-M mode system (HS/VS mode) compiled with dedicated kernel build flag CONFIG_RISCV_COVE_GUEST_PROMOTE, so won't execute for a M-mode kernel or a regular COVE guest created in a multi-step fashion. If the more privileged mode doesn't support promote_to_tvm call, then it will return an SBI error reflected in a0/a1 gprs. We can ignore the SBI result here the same as we would do it at any later guest's execution stage. This is because the result of promotion is reflected via attestation. The VM that failed the promotion will continue as a regular VM and won't retrieve secrets from attestation.

[wojciechozga]

I close this PR because I opened PR4, which comes with support for single-step TVM creation initiated from VMM.