Re: [PATCH v3 31/70] i386/tdx: Allows mrconfigid/mrowner/mrownerconfig for TDX_INIT_VM

[Xiaoyao Li]

On 12/18/2023 9:46 PM, Markus Armbruster wrote:
> Xiaoyao Li <xiaoyao.li@intel.com> writes:
>
> > On 12/1/2023 7:00 PM, Markus Armbruster wrote:
> > > Xiaoyao Li <xiaoyao.li@intel.com> writes:
> > >
> > > > From: Isaku Yamahata <isaku.yamahata@intel.com>
> > > >
> > > > Three sha384 hash values, mrconfigid, mrowner and mrownerconfig, of a TD
> > > > can be provided for TDX attestation.
> > > >
> > > > So far they were hard coded as 0. Now allow user to specify those values
> > > > via property mrconfigid, mrowner and mrownerconfig. They are all in
> > > > base64 format.
> > > >
> > > > example
> > > > -object tdx-guest, \
> > > >     
> > > > mrconfigid=ASNFZ4mrze8BI0VniavN7wEjRWeJq83vASNFZ4mrze8BI0VniavN7wEjRWeJq83v,\
> > > >     mrowner=ASNFZ4mrze8BI0VniavN7wEjRWeJq83vASNFZ4mrze8BI0VniavN7wEjRWeJq83v,\
> > > >     
> > > > mrownerconfig=ASNFZ4mrze8BI0VniavN7wEjRWeJq83vASNFZ4mrze8BI0VniavN7wEjRWeJq83v
> > > >
> > > > Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
> > > > Co-developed-by: Xiaoyao Li <xiaoyao.li@intel.com>
> > > > Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
> > > > ---
> > > > Changes in v3:
> > > >    - use base64 encoding instread of hex-string;
> > > > ---
> > > >    qapi/qom.json         | 11 +++++-
> > > >    target/i386/kvm/tdx.c | 85 +++++++++++++++++++++++++++++++++++++++++++
> > > >    target/i386/kvm/tdx.h |  3 ++
> > > >    3 files changed, 98 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/qapi/qom.json b/qapi/qom.json
> > > > index 3a29659e0155..fd99aa1ff8cc 100644
> > > > --- a/qapi/qom.json
> > > > +++ b/qapi/qom.json
> > > > @@ -888,10 +888,19 @@
> > > >   #     pages.  Some guest OS (e.g., Linux TD guest) may require this to
> > > >   #     be set, otherwise they refuse to boot.
> > > >   #
> > > > +# @mrconfigid: base64 encoded MRCONFIGID SHA384 digest
> > > > +#
> > > > +# @mrowner: base64 encoded MROWNER SHA384 digest
> > > > +#
> > > > +# @mrownerconfig: base64 MROWNERCONFIG SHA384 digest
> > >
> > > Can we come up with a description that tells the user a bit more clearly
> > > what we're talking about?  Perhaps starting with this question could
> > > lead us there: what's an MRCONFIGID, and why should I care?
> >
> > Below are the definition from TDX spec:
> >
> > MRCONFIGID: Software-defined ID for non-owner-defined configuration of the 
> > guest TD – e.g., run-time or OS configuration.
> >
> > MROWNER: Software-defined ID for the guest TD’s owner
> >
> > MROWNERCONFIG: Software-defined ID for owner-defined configuration of the guest 
> > TD – e.g., specific to the workload rather than the run-time or OS
>
> Have you considered using this for the doc comments?  I'd omit
> "software-defined" in this context.

sure. I will use them in the next version.

> > They are all attestation related, and input by users who launches the TD . 
> > Software inside TD can retrieve them with TDREPORT and verify if it is the 
> > expected value.
> >
> > MROWNER is to identify the owner of the TD, MROWNERCONFIG is to pass OWNER's 
> > configuration. And MRCONFIGID contains configuration specific to OS level 
> > instead of OWNER.
> >
> > Below is the explanation from Intel inside, hope it can get you more clear:
> >
> > "These are primarily intended for general purpose, configurable software in a 
> > minimal TD. So, not a legacy VM image cloud customer wanting to move their VM out 
> > into the cloud. Also it’s not necessarily the case that any workload will use them 
> > all.
> >
> > MROWNER is for declaring the owner of the TD. An example use case would be an 
> > vHSM TD. HSMs need to know who their administrative contact is. You could 
> > customize the HSM image and measurements, but then people can’t recognize that 
> > this is the vHSM product from XYZ. So you put the unmodified vHSM stack in the 
> > TD, which will include MRTD/RTMRs that reflect the vHSM, and the owner’s public 
> > key in MROWNER. Now, when the vHSM starts up, to determine who is authorized to 
> > send commands, it does a TDREPORT, and looks at MROWNER.
> >
> > Extending this model, there could be important configuration information from 
> > the owner. In that case, MROWNERCONFIG is set to the hash of the config file 
> > that the vHSM should accept.
> >
> > This results in an attestable environment that explicitly indicates that it’s a 
> > well recognized vHSM TD, being administered by MROWNER and loading the 
> > configuration information that matches MROWNERCONFIG.
> >
> > Extending this idea of configuration of generally recognized software, it could be 
> > that there is a shim OS under the vHSM that itself is configurable. So MRCONFIGID, 
> > which isn’t a great name, can include configuration information intended for the OS 
> > level. The ID is confusing, but MRCONFIGID was the name we used for this register 
> > for SGX, so we kept the name."
>
> Include a reference to this document?

That was the email reply from internal attestation folks.

but I can add the link to this mail in the version.

> > > > +#
> > > >   # Since: 8.2
> > > >   ##
> > > >   { 'struct': 'TdxGuestProperties',
> > > > -  'data': { '*sept-ve-disable': 'bool' } }
> > > > +  'data': { '*sept-ve-disable': 'bool',
> > > > +            '*mrconfigid': 'str',
> > > > +            '*mrowner': 'str',
> > > > +            '*mrownerconfig': 'str' } }
> > > >    ##
> > > >    # @ThreadContextProperties:
> > > [...]