Me neither, but we already maintain some exceptions like the logic to break the X509 chain for UEFI, so if we had to tinker around the edges, I think it's feasible. https://github.com/wolfSSL/wolfssl

Perhaps as a first step, we should look at our options. I would say missing functionality is problematic, but not necessarily a killer: we'd have to help the chosen project develop the capability and

On Mon, 2022-05-09 at 13:27 +0200, Gerd Hoffmann wrote: [...] > > 1) Please keep the good work to enable OPENSSL3.0 in your personal > > branch. > > 2) If you have some way to control the size, then d

I'm using a SEC phase which has a TPM driver to experiment with sorting out measured boot, which is how I noticed (usually SEC doesn't do MMIO) . What I'm seeing is after commit b6b2de884864 ("MdePkg:

I've identified a serious performance regression in recent edk2, so I've been trying to identify it by bisection, but it seems that the TDX patches have broken bisection in edk2. You can see this by t

When I do a measured boot of OVMF, I get a load of records including the two EV_EFI_PLATFORM_FIRMWARE_BLOB events, which, according to the code in Tcg2Pei.c are supposed to be measuring PEIFV and DXEF

I think the scenario in question was someone hacking into github. They can bypass your ssh login requirement without needing your key, because that's enforced by github but they can't sign your commit

They do? The gpgsig header is eaten by modern versions of git ... it only shows up as the verified decoration on github, which most people likely don't notice, because github has a huge amount of comm

I suspect the problem is that it no longer creates default devices if you don't specify them. If I look at my working version of a command line boot, it's this: qemu-kvm \ -drive if=pflash,format=raw,

There's no definition of a disk device in here. Which looks like why this failed. Where's the vmm supposed to get /dev/sda from? It sort of seems like the CD rom boot script thinks it was mounted as a

This raises a couple of issues: 1. Since OVMF is for all x86 virtual platforms not just the PC ones, should it be following the PC client spec for everything? I notice you left out Xen and Bhyve ... s

I'm with Ard on this one: -kernel is working just fine for me and the team at IBM working on Kata containers. It sounds like this might be a problem local to your environment, so we need to debug it t

Actually, there's another possibility, which is that you're not booting via the efi stub. This is somewhat tricky to get right in grub, so you can rule this out by booting ovmf to a shell and then exe

This is actually pretty much exactly what I see in the working OVMF TPM2 @ 0x0000000000000000 0000: 54 50 4D 32 4C 00 00 00 04 DB 42 4F 43 48 53 20 TPM2L.....BOCHS 0010: 42 58 50 43 54 50 4D 32 01 00

You only need that if you want the TPM configuration option for the bios menu. Without it the TPM should self configure ... I tried it without and it still works for me (produces the bios log). James

I don't confirm this. I have Linux version 5.12.0-rc5+ installed and I see the attached in my binary_bios_measurements (I've run it through tpm2-eventlog so you can see the actual events). What that c

I think I found the source of the problem: nasm is generating this assembly sequence (disassembled by objdump): 14: 48 ff 2c 24 rex.W ljmp *(%rsp) However, on AMD the rex.W prefix to a ljmp can be ine

I found this trying to test out the upstream SEV secret injection on an AMD rome system. However, I rebuilt the OvmfPkgX64 (still on a rome system) just to check. I get a boot loop here if I leave thi

The TCG Spec says the contents of this event are up to the platform manufacturer (i.e. they could contain anything) but that the hash extended into PCR 1 for EV_TABLE_OF_DEVICES *must* be that of the

commit c035e37335ae43229d7e68de74a65f2c01ebc0af Author: Zhang Lubo <lubo.zhang@...> Date: Thu Jan 5 14:58:05 2017 +0800 SecurityPkg: enhance secure boot Config Dxe & Time Based AuthVariable. Add