Re: [RFC PATCH 2/6] i386/sev: extend sev-guest property to include SEV-SNP

[Brijesh Singh]

On 7/12/21 11:24 AM, Daniel P. Berrangé wrote:>>
> > policy: 8 bytes
> > flags: 8 bytes
> > id_block: 96 bytes
> > id_auth: 4096 bytes
> > host_data: 32 bytes
> > gosvw: 16 bytes
>
> Only the id_auth parameter is really considered large here.
>
> When you say "up to a page size", that implies that the size is
> actually variable.  Is that correct, and if so, what is a real
> world common size going to be ? Is the common size much smaller
> than this upper limit ? If so I'd just ignore the issue entirely.

Looking at the recent spec, it appears that id_auth is fixed to 4K.

> If not, then, 4k on the command line is certainly ugly, but isn't
> technically impossible. It would be similarly ugly to have this
> value stuffed into a libvirt XML configuration for that matter.
>
> One option is to supply only that one parameter via an external
> file, with the file being an opaque blob whose context is the
> parameter value thus avoiding inventing a custom file format
> parser.
>
> When "id_auth" is described as "authentication data", are there
> any secrecy requirements around this ?

Yes this sounds much better, we have been using the similar approach for 
the SEV in which we pass the PDH and session blob through the file.


> QEMU does have the '-object secret' framework for passing blobs
> of sensitive data to QEMU and can allow passing via a file:
>
>    
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fqemu-project.gitlab.io%2Fqemu%2Fsystem%2Fsecrets.html&data=04%7C01%7Cbrijesh.singh%40amd.com%7C891fdc1ab0d8483aecb808d945519054%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637617038899405482%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8AHUC3DeyauxT4Pd2ZkUJkDyu9XHtexybM0BgdRlego%3D&reserved=0
>
> Even if this doesn't actually need to be kept private, we
> could decide to simply (ab)use the 'secret' object anyway
> as a way to let it be passed in out of band via a file.

The content of the field does not need to be protected. It's a public 
information, so I am not sure the secrets object fits here.

thanks