Xiaoyao Li <xiaoyao...@intel.com> writes:
> On 12/1/2023 7:00 PM, Markus Armbruster wrote:
>> Xiaoyao Li <xiaoyao...@intel.com> writes:
>>
>>> From: Isaku Yamahata <isaku.yamah...@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.yamah...@intel.com>
>>> Co-developed-by: Xiaoyao Li <xiaoyao...@intel.com>
>>> Signed-off-by: Xiaoyao Li <xiaoyao...@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:
>> [...]
>>
