* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 05/02/21 12:37, Daniel P. Berrangé wrote:
> > On Fri, Feb 05, 2021 at 11:58:26AM +0100, Paolo Bonzini wrote:
> > > On 05/02/21 10:51, Daniel P. Berrangé wrote:
> > > > > + if (!pc_system_ovmf_table_find(SEV_SECRET_GUID, &data,
> > > > > NULL)) {
> > > > > + error_setg(errp, "SEV: no secret area found in OVMF,"
> > > > > + " gpa must be specified.");
> > > > > + return;
> > > > > + }
> > > > IIUC, historically QEMU has gone out of its way to avoid creating a
> > > > direct dependancy on specific firmware implementation details such
> > > > as this, so this whole approach makes me feel really uneasy.
> > >
> > > The problem here is that this secret must be measured and therefore cannot
> > > be extracted by the guest out of fw_cfg. Note that there's no reason why
> > > other firmware than OVMF could not adopt the same interface.
> >
> > I didn't mean to store the secret in fw_cfg. Rather to use fw_cfg as a
> > way for OVMF to tell QEMU where to store it
>
> I may be misunderstanding, but I think QEMU has to store it before OVMF
> runs, because the measurement is "sealed" when the VM starts.
Yes, that's correct, it's a feature of SEV and SEV-ES that the flow is:
* measure data
* attest
* insert some encrypted data
* Start execution
I would agree this code is pretty much tied to OVMF's weird GUID based
system when it's not needed; but there's no standard to follow here.
Dave
> Paolo
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
