@olivierlambert Thanks Olivier, I'm excited to be on board!

@stormi The installer just checks for the existence of "/sys/firmware/efi/", which is created when the kernel EFI driver reads that EFI is enabled from the boot_params passed to it from GRUB2. This is how it detects the "Installer mode"

The "target boot mode" is UEFI if an EFI (ESP) partition is discovered on the target disk, otherwise it's determined to be legacy.

A mismatch between the two will cause this error. This system is a UEFI system, but doesn't appear to have a ESP on the target disk.

@adriangabura We're glad to hear your feedback and that XCP-ng is helping you with your goals! Your test feedback is very valuable, so the appreciation goes both ways. Stay tuned for the fix!

@Martín-Lorente Welcome!

@xcp-ng-justgreat thank you for the update/testing. Looks like our test machines already had python-requests-2.6.0-10.el7.noarch installed, and we need to add it as a dependency to the RPM. I'll float the idea of "no args" == "default default default latest". I am all for reducing the amount of typing necessary. Thank you for the feedback again.

A few other test ideas:

• Install onto your Linux guest the efitools package and set/modify/delete variables at random, or do the same via /sys/firmware/efi/efivars.

Note: PK/KEK/db/dbx variables should gracefully return an error or set successfully, but not actually be used on reboot. The next Secure Boot update will have these operational.

Hey @hani,

I assume you are looking to both support DRTM for guests (hence your vTPM interest), and for hosts (the Measured Boot Supplemental Pack), is that correct?

I believe you can get some form of DRTM up and running with tboot, Xen, and xentpm, although I say "some form" because the architecture of such a setup appears to be somewhat broken. If your boot chain contains a compromised component, you can no longer trust the state of subsequent components of the boot chain, which ultimately will include the OS in which xentpm is running, which eliminates any guarantees that the attestation received from xentpm is valid (xentpm itself could be modified to report that everything is okay or the PCR manifest could be spoofed, for instance).

There is a community effort called TrenchBoot which is attempting to tackle this and other problems related to launching Xen with DRTM. It is definitely worth taking a look at. TrenchBoot will include a tiny kernel as the measured launch environment, into which your attestation software can be incorporated.

I'm not entirely sure what is in the XenServer Supplemental Pack, and I can't really tell from the manual for it that they released. I suspect it is tboot and xentpm, which has the shortcomings above (please correct me if I am wrong).

As a part of the TrenchBoot effort, Grub now supports Intel TXT, so tboot may be redundant.

Regarding xentpm, I have not played with it. AFAIK, it is simply a tool to collect the TPM measurements produced at launch.

Regarding vTPM, it apparently works more-or-less, although there is some talk about replacing it. The issue with vTPM is that it is backed by a software emulator (I think QEMU's swtpm) and not the physical TPM. The only hardware protections for it lie in the fact that it exists in a separate domain, but this implies the domain and the hypervisor as attack vectors for retrieving TPM secrets, which is far too big of an attack surface to allow you to sleep well at night.

I hope some of this helps!

@xcp-ng-justgreat The issue I ran into was that bcdedit can't modify testsigning when secure boot is enabled, and setting testsigning before enabling secure boot resulted in an issue I can't quite recall, but I think it was a broken boot.

@xcp-ng-justgreat Thanks! Your feedback helped us make it better and again, it is much appreciated.

@xcp-ng-justgreat thank you for the update/testing. Looks like our test machines already had python-requests-2.6.0-10.el7.noarch installed, and we need to add it as a dependency to the RPM. I'll float the idea of "no args" == "default default default latest". I am all for reducing the amount of typing necessary. Thank you for the feedback again.

@stormi The installer just checks for the existence of "/sys/firmware/efi/", which is created when the kernel EFI driver reads that EFI is enabled from the boot_params passed to it from GRUB2. This is how it detects the "Installer mode"

The "target boot mode" is UEFI if an EFI (ESP) partition is discovered on the target disk, otherwise it's determined to be legacy.

A mismatch between the two will cause this error. This system is a UEFI system, but doesn't appear to have a ESP on the target disk.

Recompiling the kernel with kmemleak might be the fastest route to finding a solution here. Unfortunately, this obviously requires a reboot and will incur some performance hit while kmemleak is enabled (likely not an option for some systems).

https://www.kernel.org/doc/html/latest/dev-tools/kmemleak.html

A few other test ideas:

• Install onto your Linux guest the efitools package and set/modify/delete variables at random, or do the same via /sys/firmware/efi/efivars.

Note: PK/KEK/db/dbx variables should gracefully return an error or set successfully, but not actually be used on reboot. The next Secure Boot update will have these operational.

@adriangabura We're glad to hear your feedback and that XCP-ng is helping you with your goals! Your test feedback is very valuable, so the appreciation goes both ways. Stay tuned for the fix!

Seconding Olivier -- this has been fixed and will be released for test shortly! (I think the update will roll out in the next week or two)

@Martín-Lorente Welcome!

@hani sounds great, keep us posted on your progress and findings!