On 12/1/2023 7:00 PM, Markus Armbruster wrote:
Xiaoyao Li <xiaoyao.li@xxxxxxxxx> writes:
From: Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
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@xxxxxxxxx>
Co-developed-by: Xiaoyao Li <xiaoyao.li@xxxxxxxxx>
Signed-off-by: Xiaoyao Li <xiaoyao.li@xxxxxxxxx>
---
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
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."
+#
# Since: 8.2
##
{ 'struct': 'TdxGuestProperties',
- 'data': { '*sept-ve-disable': 'bool' } }
+ 'data': { '*sept-ve-disable': 'bool',
+ '*mrconfigid': 'str',
+ '*mrowner': 'str',
+ '*mrownerconfig': 'str' } }
##
# @ThreadContextProperties:
[...]
