-
Notifications
You must be signed in to change notification settings - Fork 101
Add support for Intel Trust Domain Extensions (TDX) #228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Temporarily pushing a mess of commits so that it can get cleaned up... |
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
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 <[email protected]>
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 <[email protected]>
Registers are confidential for TDX, so configuring them through the KVM API is not allowed. Signed-off-by: Jake Correnti <[email protected]>
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 <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
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 <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
…rt the memory page accordingly Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
56547f1
to
f8b3c5d
Compare
Signed-off-by: Jake Correnti <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Add an example for loading an external kernel, initramfs and custom kernel command line. Signed-off-by: Sergio Lopez <[email protected]>
Signed-off-by: Jake Correnti <[email protected]>
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 <[email protected]>
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 <[email protected]>
Re-generate them from SDK 15.0. Signed-off-by: Sergio Lopez <[email protected]>
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 <[email protected]>
closing in favor of #313 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
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:
KVM_TDX_CAPABILITIES
KVM_TDX_CAPABILITIES
Any early reviews are welcome.