We don't want to be blocked from doing releases in the meantime. Revert
this commit when ready.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The cross issues that were previously addressed by our fork are no
longer an issue since p11-kit migrated to Meson.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
p11-kit is a dependency of azure-keyvault-pkcs11, but we will also use
it directly to fetch the certificate from Azure Key Vault.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
This option used to install build dependencies to ROOT instead of /.
This never made much sense, so the option was rendered ineffective from
EAPI 7. The number of ebuilds with older EAPIs has since dwindled to
nothing.
A recent Portage change has made this option now install build
dependencies to ROOT as well as / because this can actually be useful
and doesn't cause breakage.
However, it does make us more prone to cyclic dependencies when
initially populating the board roots. There is no reason for us to use
this option though because its main purpose is to ensure the target
environment has everything it needs to rebuild itself. Given that the
option didn't do anything recently, we evidently don't even require this
for the developer container.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
These are only needed when you are going to ship DB updates to existing
systems, which we are not going to do. Our EFI variables are only for
testing. End users are expected to use EFI variables provided by their
hosts or hardware vendors. We presumably provided these before because
some PK and KEK does need to be provided, but we can now use the
Microsoft and Red Hat ones provided via Gentoo's edk2 package.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Rather than starting with a blank image, reuse the image that already
has the Microsoft certificates and the latest DBX revocation list
applied. Gentoo also applies the Red Hat certificates, which we don't
need, but this is okay.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
edk2-bin now supports multiple platforms, including QEMU on arm64, so we
no longer need to use Fedora's build. Note that the Secure Boot
implementation is currently insecure as it lacks SMM, which is needed to
protect the EFI variable store.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The new arm64 firmware supporting Secure Boot (see next commit) is in
QCOW2 format only, avoiding the extra space taken up by the 64MB
padding. Supporting both raw and QCOW2 images would be messy, so switch
entirely to QCOW2.
Only the 4MB images are in QCOW2 format on amd64, so also switch away
from the 2MB images. 4MB images are now the default for most
distributions as they are needed to apply certain Windows updates.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Kola's logic for choosing BIOS vs EFI isn't too smart, and not
specifying --qemu-ovmf-vars leads to it passing -bios to QEMU. This
doesn't make sense for arm64, but it did work anyway with the old
firmware in raw format. The new firmware in QCOW2 format doesn't work
this way.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Without configdrive the instance is failing to boot - this patch is
currently under review on PR#1128 (coreos/afterburn)
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
We initially thought we would need Red Hat's patch set. Then it looked
like we wouldn't because the TPM Event Log appeared to work without it.
We later discovered that on amd64, it only works with Secure Boot
disabled. The patch set also fixes Secure Boot on arm64, which would
have otherwise needed a couple of patches from Canonical.
We have to drop Gentoo's patches because they conflict, but they don't
affect Flatcar anyway.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
virt-fw-vars handles X.509 conversion and QCOW2 conversion transparently
and can update all the variables in a single invocation.
Bonus: Asking it to list the variables doesn't cause a segfault due to
the feature not really being implemented. :D
The 00000000-0000-0000-0000-000000000000 owner GUID is what flash-var
used to set, as we didn't specify the -g argument. We don't need to set
a meaningful value as this file is only for testing.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
