On 11/12/20 01:13, James Bottomley wrote:
>| From: James Bottomley <James.Bottomley@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.  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://github.com/AMDESE/sev-tool/