search

xcp-ng / xcp

Entry point for issues and wiki. Also contains some scripts and sources.
https://xcp-ng.org
1.31k stars 74 forks source link

Secure boot for XCP-ng platform #294

Open olivierlambert opened 5 years ago

olivierlambert commented 5 years ago

Context

Security starts on the hardware where the system boots. You need to "trust" your system, it's a "chain of trust". When XCP-ng boots, we should be able to boot it with secure boot enabled.

Suggestions

This is a complicated topic, but benefits are huge. A first step is xen.efi able to secure boot using Shim.

stormi commented 5 years ago

You mean support for Secure boot when installing XCP-ng, or for guests?

olivierlambert commented 5 years ago

For XCP-ng itself, on platform boot.

WSLUser commented 4 years ago

Any progress with this? It's a requirement to run UEFI + Secure Boot on some government systems. Currently you have to accept the risk if you use Xen. Can you boost priority?

olivierlambert commented 4 years ago

We have a dev coming in one month that will be dedicated to this feature.

Ceaus commented 3 years ago

Just to add: the ODROID-H2+ only supports secure boot, so currently can't install XCP-ng from bootable usb. I think I have no other option than to wait for XCP-ng secure boot support.

olivierlambert commented 3 years ago

Hmm there's a Xen bug on ODROID-H2 preventing it to boot. It's not related to secure boot IMHO.

edit: for the ODROID-H2+.

rjt commented 3 years ago

When secure boot is enabled, will XCP-ng then support the existing XEN vTPM virtual TPM virtual machine?

So when the hypervisor boots up on hardware with TPM, the vTPM machine is one of the first to boot afterwards and manages keys from the hardware TPM for each VM? So simpler encrypted drives for VMs.

On Wed, Dec 30, 2020 at 1:58 PM Olivier Lambert notifications@github.com wrote:

Hmm there's a Xen bug on ODROID-H2 preventing it to boot. It's not related to secure boot IMHO.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/xcp-ng/xcp/issues/294#issuecomment-752739854, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACX7F4SRN56QXJ7DNZXQNTSXOA6PANCNFSM4JBZOOWQ .

olivierlambert commented 3 years ago

It's a question for @beshleman

beshleman commented 3 years ago

@rjt That is something we can look into supporting, although the vTPM is orthogonal to UEFI Secure Boot, and could be accomplished without UEFI Secure Boot AFAIK.

I just created the this issue to record your request.

This issue (#294) involves changing the multiboot2 Xen binary to allow being measured and verified by grub / shim, as well as implementing in Xen verification of the dom0 kernel using the shim MOKList.

Ceaus commented 3 years ago

Hmm there's a Xen bug on ODROID-H2 preventing it to boot. It's not related to secure boot IMHO.

Perhaps I've searched the issues not good enough. I didn't see anything specific to the H2+.

In any case I've tried various bootable USB images today on the Odroid H2+. Secure boot images boot up straight away. Legacy BIOS images are halting immediately after turning on the H2+ with the cursor blinking at the left top corned. And that includes the images from XCP-ng.

Going into the BIOS setup the USB stick is listed as a bootable device if the image is an UEFI (?) image. If the image is a legacy boot image the USB stick is NOT listed as a bootable device. So I do think that this is about the XCP-ng image itself, not having the required security settings.

nagilum99 commented 3 years ago

That would require that autostart-function would need to learn startup priorities. Currently (unless I missed an update) it's started ~simultaneously/random. Via vApp you can set priorities and waiting times, though it doesn't automatically start the vApp list.

A solution here could be that XCP-ng would autostart a (maybe specially named) vApp group. I'm not aware that vApps are going to be depricated anytime soon, so it could be a solid way without too much code diff to CH. (If I'm right, enabling Autostart VMs in XCP changes something like a rc.local file, that runs last and thereby it could bump xapi to start a vApp instead of (direct) VMs.

...that would also help people using Windows AD to start their DC(s) first etc.

beshleman commented 3 years ago

It'll be important to build grub with the load/iorw/memrw modules disabled. We'll need to audit other modules for compromising functionality.

beshleman commented 3 years ago

Just an update here: the Xen patch set is complete and has passed (very) preliminary testing.

Putting some final touches on it before hitting the mailing list with it.

This is just for making Xen capable. Following acceptance upstream, we'll need to:

WSLUser commented 3 years ago

@beshleman Anything to report here?

beshleman commented 3 years ago

@beshleman Anything to report here?

For a basic chain-of-trust boot chain, I have a working PoC. The verification chain successfully extends from the firmware, through Xen, and into the dom0 kernel. I'm not expecting a production release until next year, though, because there is a significant amount of work needed in both the dom0 kernel and hypervisor in order to harden the system against runtime attacks that subvert secure boot protections.

If interested in the details, my Xen Summit talk goes into what we're looking at: https://youtu.be/A_IhKjK7EgA

rjt commented 3 years ago

I am a total noob and thank you for developing. Now that Windows 11 requires a TPM, would think Win11 VMs need a vTPM. Haven’t tested. Wasnt the case 6 months ago. Will follow up on the vTPM github issue.

https://github.com/xcp-ng/xcp/issues/471

On Fri, Jul 23, 2021 at 1:15 PM beshleman @.***> wrote:

@beshleman https://github.com/beshleman Anything to report here?

For a basic chain-of-trust boot chain, I have a working PoC. The verification chain successfully extends from the firmware, through Xen, and into the dom0 kernel. I'm not expecting a production release until next year, though, because there is a significant amount of work needed in both the dom0 kernel and hypervisor in order to harden the system against runtime attacks that subvert secure boot protections.

If interested in the details, my Xen Summit talk goes into what we're looking at: https://youtu.be/A_IhKjK7EgA

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xcp-ng/xcp/issues/294#issuecomment-885847330, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACX7F5WTFF3W5XVM7SHKN3TZG5VDANCNFSM4JBZOOWQ .

pietrushnic commented 3 years ago

On Tuesday as part of Qubes OS mini-summit we will sum up effort and complexity of S-RTM and Secure Boot for VMs and not only, feel free to join: https://www.qubes-os.org/news/2021/07/30/minisummit-agenda/

connorc0405 commented 2 years ago

@beshleman do you have any instructions for self-signing to enable secure boot?

beshleman commented 2 years ago

@beshleman do you have any instructions for self-signing to enable secure boot?

For what it is worth, that is probably just security theater until Xen + grub is secure boot capable.

But if you are just experimenting and aren't concerned with production-ready security, then I think you can do it with new versions of grub, the chainload command, and a signed Xen.efi... but it's been a while since I tried so could be leading you astray.