Re: [PATCH v3 0/6] SEV Encrypted Boot for Ovmf

["Laszlo Ersek" <lersek@redhat.com>]

On 12/01/20 09:05, 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@arm.com>

Thanks for reviewing this! I'll go through v3 later.

And, indeed, it was my request / suggestion (off-list, earlier) that the
feature please be implemented as a separate platform under OvmfPkg. This
new platform has very different goals from the earlier ones; in
particular their attitude about integration with the host side is
entirely different.

> 
> Is there any point to keeping the TPM bits in the AmdSev platform?

I wondered that myself, when I was suggesting the removal of multiple
feature flags (such as SMM_REQUIRE, SECURE_BOOT_ENABLE, etc). TPM_ENABLE
didn't look immediately wrong or unsupportable in the new platform, so I
didn't suggest removing it.

> 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.

It's certainly good to trim this platform to the bare minimum, I'm just
generally unsure about TPM (swtpm / vTPM) use cases with OVMF (I never
use that feature, personally). I wouldn't want to regress an otherwise
valid use case.

Thanks
Laszlo