[edk2-devel] [PATCH v3 0/6] SEV Encrypted Boot for Ovmf

James Bottomley jejb at linux.ibm.com
Tue Dec 1 15:26:42 UTC 2020


On Tue, 2020-12-01 at 09:05 +0100, Ard Biesheuvel wrote:
> On 11/30/20 9:28 PM, James Bottomley wrote:
> > v3:
> > 
> > - More grub and boot stripping (I think I got everything out, but
> >    there may be something that strayed in the boot panic
> > resolution).
> > - grub.sh tidy up with tabs->spaces.
> > - Move the reset vector GUIDisation patch to the front so it can be
> >    applied independently
> > - Update the .dsc and .fdf files for variable policy
> > 
> > v2:
> > 
> > - Strip more out of AmdSev image (networking, secure boot, smm)
> > - give sev reset block a generic table guid and use it for boot
> > secret area
> > - separate secret patches and make grub script more robust
> > - Add copyrights and fix formatting issues
> > 
> > v1:
> > 
> > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077
> > 
> > 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.
> > 
> 
> This all looks reasonable to me, although I defer to Laszlo when it 
> comes to assessing the impact on maintainability of other platforms 
> under OvmfPkg.
> 
> Acked-by: Ard Biesheuvel <ard.biesheuvel at arm.com>
> 
> Is there any point to keeping the TPM bits in the AmdSev platform?
> Or are these completely orthogonal? If there is no meaningful way
> [yet] to plumb these together, it might be better to just rip that
> out entirely so people don't make assumptions.

There is definitely a use case in the cloud for an attested VM boot and
run time whether that VM is encrypted or not.  Although the SEV
attestation covers OVMF/grub it would still be useful to get the
regular boot time attestation from them as well, so I think OVMF will
require a TPM device even in the SEV use case.

Obviously there is still a question of how you run a vtpm in this use
case, since it would have to be part of the trusted envelope as well,
so it can't simply run in the host like vtpms usually do.  However,
SEV-SNP is moving towards the concept of a trusted management VM, so I
do envisage that the vtpm would eventually be part of this or another
set up like it so it would be separate from the encrypted VM that's
running but part of the trusted envelope.

James




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#68131): https://edk2.groups.io/g/devel/message/68131
Mute This Topic: https://groups.io/mt/78617825/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