Skip to content

Conversation

@jakecorrenti
Copy link
Member

@jakecorrenti jakecorrenti commented Oct 21, 2024

This PR adds support for the Intel Trust Domain Extensions (TDX) Confidential Computing architecture.

This is currently a draft as the following issues are present:

  • The guest is failing to complete the boot sequence. I suspect this is due to firmware issues, such as a lack of proper IDT setup and #VE handling
  • https://www.github.com/virtee/tdx needs to get published to crates.io before this can get merged

Before merging there are some commits that will be squashed and/or re-ordered.

There is also additional functionality that I would like to add such as:

  • Comprehensive CPUID configuration based off of the TDX capabilities reported by KVM_TDX_CAPABILITIES
  • Handle the following VMCALLs
    • TDG.VP.VMCALL<SetupEventNotifyInterrupt>
    • TDG.VP.VMCALL<GetQuote>
    • TDG.VP.VMCALL<MapGPA>
    • TDG.VP.VMCALL<REPORT_FATAL_ERROR>
  • Validate TDX Attributes when reported by KVM_TDX_CAPABILITIES
  • Update README.md and other docs
  • Make sure guests work with varying memory and vCPU configurations

Any early reviews are welcome.

@jakecorrenti jakecorrenti mentioned this pull request Oct 21, 2024
@jakecorrenti
Copy link
Member Author

Temporarily pushing a mess of commits so that it can get cleaned up...

Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
In `memory_init` we need to use `kvm_userspace_memory_region2`,
`kvm_create_guest_memfd`, and `kvm_memory_attributes` for the TDX
architecture, otherwise it will fail.

Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
TDX does not use the `KVM_CREATE_IRQCHIP` ioctl, rather it enables the
`KVM_SPLIT_IRQCHIP` capability, which is handled by virtee/tdx.

Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Registers are confidential for TDX, so configuring them through the KVM
API is not allowed.

Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Adds a new `inteltdx` module and implements a feature-flagged `new`
method for `VM to create a VM with the TDX architecure.

Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Implements the `tdx_secure_virt_prepare` method which
in turn calls the `KVM_TDX_INIT_VM` TDX ioctl which does VM specific
initialization.

Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
…rt the memory page accordingly

Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
jakecorrenti and others added 11 commits March 6, 2025 09:00
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Instead of linking statically against libkrunfw, load it as a dynamic
library. This will enable us to make its presence optional, which will
come handy when we support loading external payloads.

Signed-off-by: Sergio Lopez <slp@redhat.com>
Introduce initial support for external kernels by dealing with the
easier case: raw images on aarch64.

This commit adds a new function, "krun_set_kernel", which receives a
path to the external kernel.

Future commits will add support for more image formats and x86_64.

Signed-off-by: Sergio Lopez <slp@redhat.com>
In the previous commit we added support for the simplest type of
external kernel, a raw image that can be directly copied into the
VM's memory.

This commit builds on that to add support for multiple kernel
formats. The ones currently implemented are:

 - ELF: A kernel binary in ELF format (vmlinux).
 - PeGz: A PE binary embedding a kernel image compressed with GZIP.
 - ImageBz2: An Image file embedding a kernel compressed with BZIP2.
 - ImageGz: An Image file embedding a kernel compressed with GZIP.
 - ImageZstd: An Image file embedding a kernel compressed with ZSTD.

Adding new kernel formats should be quite straightforward.

Please note this change doesn't implement support for loading an
external initramfs. The main reason is that we can't guarantee to
maintain the control of the VM boot when using an arbitrary
initramfs.

This means that the external kernel must be built with, at least,
the following driver built-in:

- virtio-mmio
- virtio-console
- virtio-fs

Depending on the use case, more drivers might be required.

Signed-off-by: Sergio Lopez <slp@redhat.com>
Complement the external kernel support added in the previous commits
with support for external initramfs and a custom kernel command line.

We don't have an immediate use case for this, as loading an external
initramfs may imply losing control of what's happening in the
guest, but it's a low-hanging fruit and may be useful for debugging or
a future use case.

Signed-off-by: Sergio Lopez <slp@redhat.com>
Add an example for loading an external kernel, initramfs and
custom kernel command line.

Signed-off-by: Sergio Lopez <slp@redhat.com>
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
So far we didn't have a general way for creating an managing IRQ chips.
On KVM systems, the in-kernel chip was implicitly created by vstate,
while on HVF the userspace gicv3 was created explicitly.

In this change we generalize IRQ management behind IrqChip, and we  make
the creation of the IRQ chip explicit for every platform.

This is a pretty large commit, but all these changes must be done in an
atomic way.

Signed-off-by: Sergio Lopez <slp@redhat.com>
With HVF, we generate MPIDR by taking Vcpu.id and setting Aff1 to
that value by doing a left-shift, as this is what the GIC expects
to be found in the distributor.

But, in vstate::Vcpu::configure_aarch64, we were using the Vcpu.id
without left-shifting it.

For consistency, let's generate MPIDR for the Vcpu once and use it
everywhere.

Signed-off-by: Sergio Lopez <slp@redhat.com>
Re-generate them from SDK 15.0.

Signed-off-by: Sergio Lopez <slp@redhat.com>
macOS 15 extended Hypervisor.framework with an in-kernel HVF GICv3
device. Using it reduces the cost of GIC operations and enables us to
use nested virt.

Add support for it and enable it automatically when the functions are
found in HVF.

Signed-off-by: Sergio Lopez <slp@redhat.com>
@jakecorrenti
Copy link
Member Author

closing in favor of #313

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants