Feature: Confidential guest support

[mhartmay]

What do you think about the idea of having confidential guest [1] support in virtme-ng?
I already have a working PoC to support Secure Execution [2] (protected virtualization), but wanted to have some feedback before polishing the patches and sending a PR. There are, of course, method/architecture specific parts, for which I plan to use something like the following:

vng --confidential-guest --confidential-guest-args host-key-document=... --confidential-guest-args another-option=3

And to make it easier to use, you can set the args in the virtme-ng.conf as they do not change that frequently e.g.

{
    "default_opts": {
        "confidential_guest_args": ["host-key-document=...", "another-option=3"]
    }
}

So this would reduce the command line for vng to:

vng --confidential-guest

What do you think? Note: I've only tested the feasibility for Secure Execution.

The implementation for Secure Execution does the following:

1. QEMU needs to opt-in [3]

-object s390-pv-guest,id=pv0 \
-machine confidential-guest-support=pv0

2. A Secure Execution boot image consisting of kernel, cmdline, and ramdisk must be prepared, similar to a unified kernel image (UKI).
3. Use this image as kernel to boot.

[1] https://www.qemu.org/docs/master/system/confidential-guest-support.html
[2] https://www.ibm.com/docs/en/linux-on-systems?topic=management-secure-execution
[3] https://www.qemu.org/docs/master/system/s390x/protvirt.html

[matttbe]

Hi @mhartmay,

Interesting feature. What is your motivation to add it in virtme-ng?

In my view, virtme-ng is a dev tool for the Linux kernel. I don't think the objective is to run secure VMs when these VMs generally mount the host FS. Then I'm not sure people will use such option, no? Except if it can help debugging issues? Supporting a UKI seems interesting, but might cause a lot of changes in vng, no?

Personally, I'm using a wrapper script to launch vng (or even virtme-run) for my specific need, e.g. using --qemu-opts and --append options.

[arighi]

Hi @mhartmay from a testing perspective that would be really interesting! As correctly pointed out by @matttbe the primary focus of vng is for kernel testing. But in this perspective, having a way to test confidential computing with vng sounds great. If you have any ideas that don't disrupt too much the main goal of the project (kernel testing), feel free to share them.

Also from a selfish perspective this would be useful for me, since I've been involved in some confidential computing stuff recently :)

[mhartmay]

Hi @mhartmay,

Interesting feature. What is your motivation to add it in virtme-ng?

It's good for testing the Linux kernel running in protected/confidential mode. It's also very useful to quickly have a Confidential guest setup on s390x, e.g. to test pvattest/pvsecret/etc. [1] [2]. It's NOT intended to be used in production!

In my view, virtme-ng is a dev tool for the Linux kernel. I don't think the objective is to run secure VMs when these VMs generally mount the host FS. Then I'm not sure people will use such option, no?

I see multiple use cases as mentioned above, even to debug confidential guests. On s390x, for example, we have hypervisor initiated guest dump support.

Except if it can help debugging issues? Supporting a UKI seems interesting, but might cause a lot of changes in vng, no?

Not sure about UKI as s390x does not support UKI :/

Personally, I'm using a wrapper script to launch vng (or even virtme-run) for my specific need, e.g. using --qemu-opts and --append options.

[1] https://manpages.ubuntu.com/manpages/noble/man1/pvattest.1.html
[2] https://manpages.ubuntu.com/manpages/noble/man1/pvsecret.1.html

[mhartmay]

Hi @mhartmay from a testing perspective that would be really interesting! As correctly pointed out by @matttbe the primary focus of vng is for kernel testing. But in this perspective, having a way to test confidential computing with vng sounds great. If you have any ideas that don't disrupt too much the main goal of the project (kernel testing), feel free to share them.

Also from a selfish perspective this would be useful for me, since I've been involved in some confidential computing stuff recently :)

As mentioned in the issue, I already have a working PoC on s390x for this and it uses the following vng command line:

vng --confidential-guest --confidential-guest-args host-key-document=... --confidential-guest-args another-option=3

With a pre-configured virtme-ng.conf the command line is reduced to a simple opt-in flag:

vng --confidential-guest

In case of s390x, I would/could also add support for the hypervisor initiated dump support and that would also be really great to debug kernel problems related to protected/confidential mode.

[mhartmay]

See mhartmay@bbe6268 for a PoC.

What currently is missing:

• QEMU feautre probing?
• Kernel feature probing?
  (+ AMD64 support)

[mhartmay]

See #290 for a RFC.