Support loading external kernels #256
Conversation
slp
force-pushed
the
external-kernel
branch
7 times, most recently
from
9e362bd to
95e72d6
Compare
|
Funny, I was trying (very much in the background) to do something like this, but making libkrunfw load kernel images instead. My use case is testing kernels and especially userspace tools (passt, seitan, nft) against different kernels/kernel changes. This looks way simpler and it looks like you're almost done (or at least much closer than I was), so I'm relieved. :) |
Please note that we don't intend to support an external initramfs, at least for the moment. This implies you still need a custom kernel config that has, at least, |
Yeah, I would actually like to get rid of the initramfs in my current workflow (based on mbuto), for simplicity.
Custom configuration, sure, but not patched, right? |
Nope, no downstream patches are required, unless you want to use TSI, which I'm pretty sure you don't ;-P |
slp
force-pushed
the
external-kernel
branch
5 times, most recently
from
d62666b to
c242bfd
Compare
| #[allow(clippy::missing_safety_doc)] | ||
| #[no_mangle] | ||
| pub unsafe extern "C" fn krun_set_kernel(_ctx_id: u32, _c_kernel_path: *const c_char) -> i32 { | ||
| -libc::EOPNOTSUPP |
There was a problem hiding this comment.
What's holding us back from supporting krun_set_kernel with the tee feature?
There was a problem hiding this comment.
We still need custom kernel (at least for SEV/SNP, not so sure about TDX), a custom qboot (for the initial memory initialization), and a custom init (for bundling an agent and opening the LUKS volume).
We should get rid of those custom components. A possible plan for that could be:
- Adopt OVMF/EDK2 as FW. It would need to be a custom built, since we aren't 100% compatible with QEMU, but would have the facilities required to boot an unmodified kernel in a TEE.
- Find a way to generate an initramfs on the fly in a reproducible way, so it can be part of the attestation envelope.
Both tasks seem doable, but require a significant amount of effort. Once we get there, we'll be able to support external kernels with the TEE flavor.
There was a problem hiding this comment.
- Find a way to generate an initramfs on the fly in a reproducible way, so it can be part of the attestation envelope.
Can you expand on this a bit more?
There was a problem hiding this comment.
By the way, while it's most likely not the right tool for this, I tried to keep the initramfs bureaucracy as simple as possible in mbuto, so it might be helpful if you're trying to sketch stuff quickly.
There was a problem hiding this comment.
By the way, while it's most likely not the right tool for this, I tried to keep the initramfs bureaucracy as simple as possible in mbuto, so it might be helpful if you're trying to sketch stuff quickly.
Hm... this may come handy for building initramfs to TEEs, thanks.
slp
force-pushed
the
external-kernel
branch
4 times, most recently
from
beb5379 to
fce4f1e
Compare
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]>
|
I've also added support for loading an external initramfs and setting a custom kernel command line. We don't have an immediate use case for it, but it was a low-hanging fruit and may come handy for future use cases. |
slp
force-pushed
the
external-kernel
branch
3 times, most recently
from
67f19fc to
127ba51
Compare
|
@slp Is this ready for review? |
Yup, took some iterations, but should be ready now. |
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]>
|
The last force-push caught a crazy clippy update that's throwing dozens of new warnings. I'll fix it next week. |
This PR makes libkrunfw optional (by dynamically loading it) and adds
support for loading external kernels from multiple image formats. The
ones currently implemented are:
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:
Depending on the use case, more drivers might be required.