[edk2-devel] [PATCH 0/4] SEV Encrypted Boot for Ovmf
Dr. David Alan Gilbert
dgilbert at redhat.com
Thu Nov 12 16:34:34 UTC 2020
* Ashish Kalra (ashish.kalra at amd.com) wrote:
> On Wed, Nov 11, 2020 at 04:13:12PM -0800, James Bottomley wrote:
> > From: James Bottomley <James.Bottomley at HansenPartnership.com>
> >
> > This patch series is modelled on the structure of the Bhyve patches
> > for Ovmf, since it does somewhat similar things. This patch series
> > creates a separate build for an AmdSev OVMF.fd that does nothing
> > except combine with grub and boot straight through the internal grub
> > to try to mount an encrypted volume.
> >
> > Concept: SEV Secure Encrypted Images
> > ====================================
> >
> > The SEV patches in Linux and OVMF allow for the booting of SEV VMs in
> > an encrypted state, but don't really show how this could be done with
> > an encrypted image.
>
> A basic question here ... the SEV usage model in which the firmware is
> encrypted and loaded into VM using LAUNCH_UPDATA_DATA and then
> measurement is provided and attestation is done with the VM owner and
> after VM owner verifies measurement, the VM owner encrypts the disk
> encryption key and sends it to the guest and it is injected into the
> guest using the LAUNCH_SECRET API, which is then used to decrypt the
> OS encrypted image, won't this work to start the SEV VM
> with an encrypted image ?
That's still what James system does, but the problem is maintaining a
chain of trust from the set of measured binaries to the point at
which you can use the injected secret.
On the current OVMF world we end up measuring the OVMF binary, but not
the stored variable flash; but then what? Who would read the injected
secret?
Because SEV/SEV-ES has no way of performing a later attestation, or
updating the measurements, we have no way of following the path from
OVMF (possibly via variables) to a boot loader, to a filesystem.
Dave
> Thanks,
> Ashish
>
> >Since the key used to decrypt the image must be
> > maintained within the SEV encryption envelope, encrypted QCOW is not
> > an option because the key would then have to be known to QEMU which is
> > outside the encryption envelope. The proposal here is that an
> > encrypted image should be a QCOW image consisting of two partitions,
> > the normal unencrypted EFI partition (Identifying it as an OVMF
> > bootable image) and a luks encrypted root partition. The kernel would
> > be inside the encrypted root in the /boot directory. The secret
> > injected securely through QEMU is extracted by OVMF and passed to grub
> > which uses it to mount the encrypted root and boot the kernel
> > normally. The creator of the secret bundle must be satisfied with the
> > SEV attestation before the secret is constructed. Unfortunately, the
> > SEV attestation can only be on the first QEMU firmware volume and
> > nothing else, so this patch series builds grub itself into a firmware
> > volume and places it inside OVMF so that the entire boot system can be
> > attested. In a normal OVMF KVM system, the variable store is on the
> > second flash volume (which is read/write). Unfortunately, this
> > mutable configuration provided by the variables is outside the
> > attestation envelope and can significantly alter the boot path,
> > possibly leading to secret leak, so encrypted image boot should only
> > be done with the OVMF.fd that combines both the code and variables.
> > the OVMF.fd is constructed so that it becomes impossible to interrupt
> > the boot sequence after attestation and the system will either boot
> > the image or fail. The boot sequence runs the grub.efi embedded in the
> > OVMF firmware volume so the encrypted image owner knows their own
> > version of grub is the only one that will boot before injecting the
> > secret. Note this boot path actually ignores the unencrypted EFI
> > partition. However, as part of this design, the encrypted image may be
> > booted by a standard OVMF KVM boot and in that case, the user will
> > have to type the encryption password. This standard boot will be
> > insecure but it might be used by the constructor of the encrypted
> > images on their own private laptop, for instance. The standard boot
> > path will use the unencrypted EFI partition.
> >
> > Patches Required Outside of OVMF
> > ================================
> >
> > There is a patch set to grub which allows it to extract the SEV secret
> > area from the configuration table and use the secret as a password to
> > do a luks crypto mount of root (this is the sevsecret grub module).
> >
> > There is also a patch to qemu which allows it to search through the
> > OVMF.fd and find the SEV secret area which is now described inside the
> > Reset Vector using the existing SEV_ES reset block. This area is the
> > place QEMU will inject the encrypted SEV secret bundle.
> >
> > Security of the System
> > ======================
> >
> > Since Grub is now part of the attested OVMF.fd bundle, the VM owner
> > knows absolutely that it will proceed straight to partition decryption
> > inside the attested code and boot the kernel off the encrypted
> > partition. Even if a different QCOW image is substituted, the boot
> > will fail without revealing the secret because the system is designed
> > to fail hard in that case and because the secret is always contained
> > within the encrypted envelope it should be impossible for the cloud
> > operator to obtain it even if they can pause the boot and examine the
> > machine memory.
> >
> > Putting it All Together
> > =======================
> >
> > This is somewhat hard. You must first understand how to boot a QEMU
> > system so as to have the VM pause after firmware loading (-S option)
> > and use the qmp port to request an attestation. Only if the
> > attestation corresponds to the expected sha256sum of OVMF.fd should
> > the secret bundle be constructed and injected using qmp. The tools
> > for constructing the secret bundle are in
> >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fsev-tool%2F&data=04%7C01%7Cashish.kalra%40amd.com%7Ceb007b21e05c4e9c05cf08d8869fc874%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407368115912177%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TwcpYSl10ePPfomMIQQjjxcOufjlxkzDkR8H7BxKZtw%3D&reserved=0
> >
> > James
> >
> > ---
> >
> > James Bottomley (4):
> > OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF
> > OvmfPkg/AmdSev: add Grub Firmware Volume Package
> > OvmfPkg: create a SEV secret area in the AmdSev memfd
> > OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table
> >
> > OvmfPkg/OvmfPkg.dec | 6 +
> > OvmfPkg/AmdSev/AmdSevX64.dsc | 1035 +++++++++++
> > OvmfPkg/AmdSev/AmdSevX64.fdf | 515 ++++++
> > OvmfPkg/AmdSev/Grub/Grub.inf | 37 +
> > .../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 +
> > .../SevLaunchSecret/SecretPei/SecretPei.inf | 46 +
> > .../PlatformBootManagerLibGrub.inf | 84 +
> > OvmfPkg/ResetVector/ResetVector.inf | 4 +
> > .../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++
> > .../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 +
> > .../SevLaunchSecret/SecretPei/SecretPei.c | 26 +
> > .../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++
> > .../PlatformBootManagerLibGrub/PlatformData.c | 213 +++
> > OvmfPkg/AmdSev/Grub/.gitignore | 1 +
> > OvmfPkg/AmdSev/Grub/grub.cfg | 35 +
> > OvmfPkg/AmdSev/Grub/grub.sh | 54 +
> > OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 +
> > OvmfPkg/ResetVector/ResetVector.nasmb | 2 +
> > 18 files changed, 3846 insertions(+)
> > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc
> > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf
> > create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf
> > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf
> > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf
> > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf
> > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h
> > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c
> > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c
> > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
> > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c
> > create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore
> > create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg
> > create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh
> >
> > --
> > 2.26.2
> >
>
--
Dr. David Alan Gilbert / dgilbert at redhat.com / Manchester, UK
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#67395): https://edk2.groups.io/g/devel/message/67395
Mute This Topic: https://groups.io/mt/78198617/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list