[PATCH 0/4] SEV Encrypted Boot for Ovmf


James Bottomley <jejb@...>
 

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/

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
 

* Ashish Kalra (ashish.kalra@amd.com) wrote:
On Wed, Nov 11, 2020 at 04:13:12PM -0800, 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.
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&amp;sdata=TwcpYSl10ePPfomMIQQjjxcOufjlxkzDkR8H7BxKZtw%3D&amp;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@redhat.com / Manchester, UK


Dr. David Alan Gilbert
 

* Brijesh Singh (brijesh.singh@amd.com) wrote:
Hi James,

Thanks for series, I glanced at it, the changes looks okay to me. I have
one questions.

How does the grub locate the disk decryption key ? Am I correct in
assuming that the gurb is iterating through a configuration table
entries and comparing the Secret GUID to locate the secret key. As per
the SEV spec, its possible that a guest owner can call the secret
injection more than once. I don't see the patch consider that case,
should we support this or limit to one inject?  Maybe Qemu can enforce
this property.
That's interesting, I hadn't realised that was possible - however,
I can't see a way to use it - for it to be useful, you would have to
have a way for the guest to communicate to the owner that it had
finished with the first injection and would like the next; but if you
already have a way to communicate from the guest to the owner to request
stuff, then you could pass a new secret by that comms route?

Do you see any need for the Linux kernel needing to access the secret?
Since the secret blob is available through configuration table, I
believe we can have a platform driver that can read the configuration
table and retrieve the secret blob.
I guess it depends if you get the Grub to pass the fs secret down to the
kernel or let it pick it up itself from the same place.

Dave


thanks

On 11/11/20 6:13 PM, 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fsev-tool%2F&;data=04%7C01%7Cbrijesh.singh%40amd.com%7Ceb007b21e05c4e9c05cf08d8869fc874%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407368116062086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BbCtv37bH0%2B6JDLM3afAubVN6K0Y%2FdO4TRz4ZkP1AKg%3D&amp;reserved=0

Where you able to use the sev-tool as-is to generate a secret blob that
can be injected through the Qemu QMP interface? The reason why I am
asking this is because the last time when I looked at the sev-tool I
found that it did not generated the blob which was in the correct format.



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
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK


Ashish Kalra <ashish.kalra@...>
 

On Wed, Nov 11, 2020 at 04:13:12PM -0800, 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.
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 ?

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&amp;sdata=TwcpYSl10ePPfomMIQQjjxcOufjlxkzDkR8H7BxKZtw%3D&amp;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


James Bottomley <jejb@...>
 

On Thu, 2020-11-12 at 16:34 +0000, Dr. David Alan Gilbert wrote:
* Ashish Kalra (ashish.kalra@amd.com) wrote:
On Wed, Nov 11, 2020 at 04:13:12PM -0800, 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.
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.
Right, the specific problem is our current linux boot sequence goes

OVMF->grub->linux

But OVMF can only execute things on an unencrypted vFAT filesytem, so
if grub is on vFAT there's no way to prevent a cloud admin substituting
the grub binary after attestation is done and the key released if we
only attest OVMF, so the bogus grub binary could simply capture the key
and transmit it to a hacker.

Pulling grub inside OVMF allows us to attest both OVMF and grub as one
entity and also prevents the boot going via the unencrypted vFAT
filesystem, eliminating the potential interception point.

James


Ashish Kalra <ashish.kalra@...>
 

On Thu, Nov 12, 2020 at 09:07:11AM -0800, James Bottomley wrote:
On Thu, 2020-11-12 at 16:34 +0000, Dr. David Alan Gilbert wrote:
* Ashish Kalra (ashish.kalra@amd.com) wrote:
On Wed, Nov 11, 2020 at 04:13:12PM -0800, 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.
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.
Right, the specific problem is our current linux boot sequence goes

OVMF->grub->linux

But OVMF can only execute things on an unencrypted vFAT filesytem, so
if grub is on vFAT there's no way to prevent a cloud admin substituting
the grub binary after attestation is done and the key released if we
only attest OVMF, so the bogus grub binary could simply capture the key
and transmit it to a hacker.

Pulling grub inside OVMF allows us to attest both OVMF and grub as one
entity and also prevents the boot going via the unencrypted vFAT
filesystem, eliminating the potential interception point.

James

Thanks James and Dave for the detailed explanations, i get the picture.

Also after discussion with Brijesh, i understand that this is fixing a
known gap in the SEV s/w stack.

Ashish


Brijesh Singh <brijesh.singh@...>
 

Hi James,

Thanks for series, I glanced at it, the changes looks okay to me. I have
one questions.

How does the grub locate the disk decryption key ? Am I correct in
assuming that the gurb is iterating through a configuration table
entries and comparing the Secret GUID to locate the secret key. As per
the SEV spec, its possible that a guest owner can call the secret
injection more than once. I don't see the patch consider that case,
should we support this or limit to one inject?  Maybe Qemu can enforce
this property.

Do you see any need for the Linux kernel needing to access the secret?
Since the secret blob is available through configuration table, I
believe we can have a platform driver that can read the configuration
table and retrieve the secret blob.

thanks

On 11/11/20 6:13 PM, 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fsev-tool%2F&;data=04%7C01%7Cbrijesh.singh%40amd.com%7Ceb007b21e05c4e9c05cf08d8869fc874%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407368116062086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BbCtv37bH0%2B6JDLM3afAubVN6K0Y%2FdO4TRz4ZkP1AKg%3D&amp;reserved=0

Where you able to use the sev-tool as-is to generate a secret blob that
can be injected through the Qemu QMP interface? The reason why I am
asking this is because the last time when I looked at the sev-tool I
found that it did not generated the blob which was in the correct format.



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


James Bottomley <jejb@...>
 

On Thu, 2020-11-12 at 11:32 -0600, Brijesh Singh wrote:
Hi James,

Thanks for series, I glanced at it, the changes looks okay to me. I
have
one questions.

How does the grub locate the disk decryption key ? Am I correct in
assuming that the gurb is iterating through a configuration table
entries and comparing the Secret GUID to locate the secret key. As
per the SEV spec, its possible that a guest owner can call the secret
injection more than once. I don't see the patch consider that case,
should we support this or limit to one inject? Maybe Qemu can
enforce this property.
Well in the original patch, grub recognized the secret in the area by
the prefix "PASSWORD:". I think that's a bit fragile, so I was
planning to rework the grub patch to do everything by guid, so the
secrets table itself would have its own guid which would be followed by
the entire table length. Then the entries in the table would have the
format

|guid|len|data|

So every consumer first of all validates the table by the initial guid
and gets the total length then iterates over the entries to see if its
interested in any of them. The format of |data| would be up to the
consumer.

Do you see any need for the Linux kernel needing to access the
secret? Since the secret blob is available through configuration
table, I believe we can have a platform driver that can read the
configuration table and retrieve the secret blob.
I've only been really concentrating on the grub use case. However, as
you saw in my reply about migration, we likely also need an entry so
that the migration helper can pick up its ECDH identity. The scheme
would definitely cover passing a secret to the kernel as well. The one
caveat there is that the HOB that covers the secret is boot time, so
the secret would have to be extracted in the kernel EFI stub before
ExitBootServices() is called. I suppose nothing really prevent the HOB
from becoming runtime except the security maxim that you want all
secret lifetimes to be as short as possible.

James


Brijesh Singh <brijesh.singh@...>
 

On 11/12/20 1:38 PM, Dr. David Alan Gilbert wrote:
* Brijesh Singh (brijesh.singh@amd.com) wrote:
Hi James,

Thanks for series, I glanced at it, the changes looks okay to me. I have
one questions.

How does the grub locate the disk decryption key ? Am I correct in
assuming that the gurb is iterating through a configuration table
entries and comparing the Secret GUID to locate the secret key. As per
the SEV spec, its possible that a guest owner can call the secret
injection more than once. I don't see the patch consider that case,
should we support this or limit to one inject?  Maybe Qemu can enforce
this property.
That's interesting, I hadn't realised that was possible - however,
I can't see a way to use it - for it to be useful, you would have to
have a way for the guest to communicate to the owner that it had
finished with the first injection and would like the next; but if you
already have a way to communicate from the guest to the owner to request
stuff, then you could pass a new secret by that comms route?

The main reason for its existence was to allow guest owner to inject
multiple blocks of the data if they need to do so, e.g IIRC, Enarx folks
use this to inject the keep which is much bigger than 128K. I am not
sure if we really need it for the VM boot flow but we probably need to
define the secret page layout such that it contains multiple entries in
it. In our case the Secret can't be more than a page, so, we can define
a secret page layout such that it can contain more than one disk key. I
was thinking about something like this

typedef enum {

   DISK_KEY_AES_128,

   SSH_PRIVATE_KEY,

   ...

} data_type;

struct secret_data {

   u8 entries;

   struct {

      data_type type;

      u16 len;

      u8 name[16];

      u8 data[];

   } entry[];

}

This should allow us to package multiple secrets in one inject.


Do you see any need for the Linux kernel needing to access the secret?
Since the secret blob is available through configuration table, I
believe we can have a platform driver that can read the configuration
table and retrieve the secret blob.
I guess it depends if you get the Grub to pass the fs secret down to the
kernel or let it pick it up itself from the same place.

I guess the main reason why I was asking this is, what if guest owner
provides more than one disk keys in the secret injection blob. Grub can
use the boot disk key to access the Linux images and other disk keys may
later be used by Linux.

Dave

thanks

On 11/11/20 6:13 PM, 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fsev-tool%2F&;data=04%7C01%7Cbrijesh.singh%40amd.com%7Cc5b99bba03c74eb5bc2308d887428054%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637408066981024287%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SSmQZgDWx4P5a2hOJZRnhrM0n5ExpqzjLGolv0f0CC8%3D&amp;reserved=0
Where you able to use the sev-tool as-is to generate a secret blob that
can be injected through the Qemu QMP interface? The reason why I am
asking this is because the last time when I looked at the sev-tool I
found that it did not generated the blob which was in the correct format.


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


James Bottomley <jejb@...>
 

On Thu, 2020-11-12 at 15:56 -0600, Brijesh Singh wrote:
On 11/12/20 1:38 PM, Dr. David Alan Gilbert wrote:
* Brijesh Singh (brijesh.singh@amd.com) wrote:
Hi James,

Thanks for series, I glanced at it, the changes looks okay to me.
I have one questions.

How does the grub locate the disk decryption key ? Am I correct
in assuming that the gurb is iterating through a configuration
table entries and comparing the Secret GUID to locate the secret
key. As per the SEV spec, its possible that a guest owner can
call the secret injection more than once. I don't see the patch
consider that case, should we support this or limit to one
inject? Maybe Qemu can enforce this property.
That's interesting, I hadn't realised that was possible - however,
I can't see a way to use it - for it to be useful, you would have
to have a way for the guest to communicate to the owner that it had
finished with the first injection and would like the next; but if
you already have a way to communicate from the guest to the owner
to request stuff, then you could pass a new secret by that comms
route?
The main reason for its existence was to allow guest owner to inject
multiple blocks of the data if they need to do so, e.g IIRC, Enarx
folks use this to inject the keep which is much bigger than 128K.
In some ways this sounds like the wrong approach. I mean we could use
injection to inject the entire VM image as well, but we don't, we
inject the key and decrypt the image ... it does rather sound like
that's what should be happening for other bulk data, like the keep. If
you do it this way you can use the main CPU and bulk memory encryption
to pull the data into the secure memory rather than using the PSP,
which is a lot slower.

Also one of the problems with having OVMF define the secret location is
that we have to find space in the MEMFD. For a single page like the
current implementation uses, that's easy, but for tens to hundreds of
pages it would be impossible. Even if we guid describe everything,
standard aes keys are 16-32 bytes, so even in the worst case we can fit
85 guid described decryption keys in a page, which should be more than
enough for anyone, provided we inject the key to the bulk data, not the
bulk data itself.

I am not sure if we really need it for the VM boot flow but we
probably need to define the secret page layout such that it contains
multiple entries in it. In our case the Secret can't be more than a
page, so, we can define a secret page layout such that it can contain
more than one disk key. I was thinking about something like this

typedef enum {

DISK_KEY_AES_128,

SSH_PRIVATE_KEY,

...

} data_type;

struct secret_data {

u8 entries;

struct {

data_type type;

u16 len;

u8 name[16];

u8 data[];

} entry[];

}

This should allow us to package multiple secrets in one inject.
I proposed something slightly different in a prior email. If we use
the guid approach, we don't have to define the data structure a-priori
... just the producer and consumer have to agree on what it is.

Do you see any need for the Linux kernel needing to access the
secret? Since the secret blob is available through configuration
table, I believe we can have a platform driver that can read the
configuration table and retrieve the secret blob.
I guess it depends if you get the Grub to pass the fs secret down
to the kernel or let it pick it up itself from the same place.
I guess the main reason why I was asking this is, what if guest owner
provides more than one disk keys in the secret injection blob. Grub
can use the boot disk key to access the Linux images and other disk
keys may later be used by Linux.
Right, see other email for limitations.

James


James Bottomley <jejb@...>
 

On Wed, 2020-11-11 at 16:13 -0800, James Bottomley wrote:
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.
The necessary patches to grub to allow it to retrieve the SEV secret
are now posted on the grub development list:

https://lists.gnu.org/archive/html/grub-devel/2020-11/msg00078.html

This includes the sevsecret module which is required to build the
embedded grub.

Regards,

James


Laszlo Ersek
 

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/

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
queued this thread for review


Brijesh Singh <brijesh.singh@...>
 

On 11/12/20 4:50 PM, James Bottomley wrote:
On Thu, 2020-11-12 at 15:56 -0600, Brijesh Singh wrote:
On 11/12/20 1:38 PM, Dr. David Alan Gilbert wrote:
* Brijesh Singh (brijesh.singh@amd.com) wrote:
Hi James,

Thanks for series, I glanced at it, the changes looks okay to me.
I have one questions.

How does the grub locate the disk decryption key ? Am I correct
in assuming that the gurb is iterating through a configuration
table entries and comparing the Secret GUID to locate the secret
key. As per the SEV spec, its possible that a guest owner can
call the secret injection more than once. I don't see the patch
consider that case, should we support this or limit to one
inject? Maybe Qemu can enforce this property.
That's interesting, I hadn't realised that was possible - however,
I can't see a way to use it - for it to be useful, you would have
to have a way for the guest to communicate to the owner that it had
finished with the first injection and would like the next; but if
you already have a way to communicate from the guest to the owner
to request stuff, then you could pass a new secret by that comms
route?
The main reason for its existence was to allow guest owner to inject
multiple blocks of the data if they need to do so, e.g IIRC, Enarx
folks use this to inject the keep which is much bigger than 128K.
In some ways this sounds like the wrong approach. I mean we could use
injection to inject the entire VM image as well, but we don't, we
inject the key and decrypt the image ... it does rather sound like
that's what should be happening for other bulk data, like the keep. If
you do it this way you can use the main CPU and bulk memory encryption
to pull the data into the secure memory rather than using the PSP,
which is a lot slower.
I wanted to highlight spec. I agree that in our VM launch I don't see a
need to provide a multiple LAUNCH_SECRET as long as we define producer
and consumer format to package the multiple secrets in one inject.



Also one of the problems with having OVMF define the secret location is
that we have to find space in the MEMFD. For a single page like the
current implementation uses, that's easy, but for tens to hundreds of
pages it would be impossible. Even if we guid describe everything,
standard aes keys are 16-32 bytes, so even in the worst case we can fit
85 guid described decryption keys in a page, which should be more than
enough for anyone, provided we inject the key to the bulk data, not the
bulk data itself.
I am not sure if we really need it for the VM boot flow but we
probably need to define the secret page layout such that it contains
multiple entries in it. In our case the Secret can't be more than a
page, so, we can define a secret page layout such that it can contain
more than one disk key. I was thinking about something like this

typedef enum {

DISK_KEY_AES_128,

SSH_PRIVATE_KEY,

...

} data_type;

struct secret_data {

u8 entries;

struct {

data_type type;

u16 len;

u8 name[16];

u8 data[];

} entry[];

}

This should allow us to package multiple secrets in one inject.
I proposed something slightly different in a prior email. If we use
the guid approach, we don't have to define the data structure a-priori
... just the producer and consumer have to agree on what it is.

Yes, your guid approach is much preferred. thanks


Do you see any need for the Linux kernel needing to access the
secret? Since the secret blob is available through configuration
table, I believe we can have a platform driver that can read the
configuration table and retrieve the secret blob.
I guess it depends if you get the Grub to pass the fs secret down
to the kernel or let it pick it up itself from the same place.
I guess the main reason why I was asking this is, what if guest owner
provides more than one disk keys in the secret injection blob. Grub
can use the boot disk key to access the Linux images and other disk
keys may later be used by Linux.
Right, see other email for limitations.

James


Laszlo Ersek
 

Hi James,

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.
I've opened a feture request BZ at
<https://bugzilla.tianocore.org/show_bug.cgi?id=3077>.

Can you please register in the TianoCore Bugzilla, and assign the bug to
yourself?

I'll post more comments under the individual patches.

Thanks,
Laszlo


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/

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


Laszlo Ersek
 

On 11/16/20 19:50, Laszlo Ersek wrote:
Hi James,

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.
I've opened a feture request BZ at
<https://bugzilla.tianocore.org/show_bug.cgi?id=3077>.

Can you please register in the TianoCore Bugzilla, and assign the bug to
yourself?

I'll post more comments under the individual patches.
(1) There are a number of git settings that are useful with edk2 clones.
Most of them are described at

<https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05>

but for convenience, the edk2 repo provides the
"BaseTools/Scripts/SetupGit.py" script. Can you please run it in your
git repo?


(2) Every commit message should reference TianoCore#3077 like this:

"""
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077
"""

just above the S-o-b.

Thanks
Laszlo


James Bottomley <jejb@...>
 

On Mon, 2020-11-16 at 19:50 +0100, Laszlo Ersek wrote:
Hi James,

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.
I've opened a feture request BZ at
<https://bugzilla.tianocore.org/show_bug.cgi?id=3077>;.

Can you please register in the TianoCore Bugzilla, and assign the bug
to yourself?
OK, done.

I'll post more comments under the individual patches.
Great, thanks!

James