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

[Markus Armbruster]

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.

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

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