From: "James Bottomley" <jejb@linux.ibm.com>
To: Ard Biesheuvel <ard.biesheuvel@arm.com>, devel@edk2.groups.io
Cc: dovmurik@linux.vnet.ibm.com, Dov.Murik1@il.ibm.com,
ashish.kalra@amd.com, brijesh.singh@amd.com, tobin@ibm.com,
david.kaplan@amd.com, jon.grimm@amd.com, thomas.lendacky@amd.com,
frankeh@us.ibm.com,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
Laszlo Ersek <lersek@redhat.com>,
Jordan Justen <jordan.l.justen@intel.com>
Subject: Re: [PATCH v3 0/6] SEV Encrypted Boot for Ovmf
Date: Tue, 01 Dec 2020 07:26:42 -0800 [thread overview]
Message-ID: <2e64cf912acfe5aa7cc9c9b1303ccd910faaf6f8.camel@linux.ibm.com> (raw)
In-Reply-To: <2f0c10ac-d4b1-0873-0ef2-aeeea9b0d001@arm.com>
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@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
next prev parent reply other threads:[~2020-12-01 15:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 20:28 [PATCH v3 0/6] SEV Encrypted Boot for Ovmf James Bottomley
2020-11-30 20:28 ` [PATCH v3 1/6] OvmfPkg/ResetVector: convert SEV-ES Reset Block structure to be GUIDed James Bottomley
2020-12-03 8:10 ` [edk2-devel] " Laszlo Ersek
2020-11-30 20:28 ` [PATCH v3 2/6] OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF James Bottomley
2020-12-03 8:20 ` [edk2-devel] " Laszlo Ersek
2020-11-30 20:28 ` [PATCH v3 3/6] OvmfPkg/AmdSev: add Grub Firmware Volume Package James Bottomley
2020-12-03 8:39 ` [edk2-devel] " Laszlo Ersek
2020-11-30 20:28 ` [PATCH v3 4/6] OvmfPkg: create a SEV secret area in the AmdSev memfd James Bottomley
2020-12-03 8:42 ` [edk2-devel] " Laszlo Ersek
2020-11-30 20:28 ` [PATCH v3 5/6] OvmfPkg/AmdSev: assign and protect the Sev Secret area James Bottomley
2020-12-01 7:54 ` Ard Biesheuvel
2020-12-01 18:36 ` [edk2-devel] " James Bottomley
2020-11-30 20:28 ` [PATCH v3 6/6] OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table James Bottomley
2020-12-03 8:46 ` [edk2-devel] " Laszlo Ersek
2020-12-09 12:02 ` Yao, Jiewen
2020-12-09 15:46 ` James Bottomley
2020-12-09 15:54 ` James Bottomley
2020-12-09 16:33 ` Yao, Jiewen
2020-12-09 16:38 ` James Bottomley
2020-12-09 16:51 ` Yao, Jiewen
2020-12-09 17:04 ` James Bottomley
2020-12-10 9:12 ` Laszlo Ersek
2020-12-10 9:27 ` Yao, Jiewen
2020-12-01 8:05 ` [PATCH v3 0/6] SEV Encrypted Boot for Ovmf Ard Biesheuvel
2020-12-01 8:13 ` Laszlo Ersek
2020-12-01 15:26 ` James Bottomley [this message]
2020-12-01 8:05 ` Laszlo Ersek
2020-12-03 12:26 ` [edk2-devel] " Laszlo Ersek
2020-12-03 14:27 ` James Bottomley
2020-12-04 0:46 ` Laszlo Ersek
2020-12-04 1:05 ` James Bottomley
2020-12-04 1:55 ` Laszlo Ersek
2020-12-04 2:01 ` Laszlo Ersek
2020-12-14 19:57 ` Laszlo Ersek
2020-12-21 15:00 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2e64cf912acfe5aa7cc9c9b1303ccd910faaf6f8.camel@linux.ibm.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox