Hi All,
Intel's Trust Domain Extensions (TDX) protect guest VMs from malicious hosts and some physical attacks. VM guest with TDX support is called as a TDX Guest.
In TDX guest, attestation process is used to verify the TDX guest trustworthiness to other entities before provisioning secrets to the guest. For example, a key server may request for attestation before releasing the encryption keys to mount the encrypted rootfs or secondary drive.
This patch set adds attestation support for the TDX guest. Details about the TDX attestation process and the steps involved are explained in the commit log of Patch 1/3 or in Documentation/x86/tdx.rst (added by patch 3/3).
Following are the details of the patch set:
Patch 1/3 -> Adds TDREPORT support. Patch 2/3 -> Adds selftest support for TDREPORT feature. Patch 3/3 -> Add attestation related documentation.
Commit log history is maintained in the individual patches.
Kuppuswamy Sathyanarayanan (3): x86/tdx: Add TDX Guest attestation interface driver selftests: tdx: Test TDX attestation GetReport support Documentation/x86: Document TDX attestation process
Documentation/x86/tdx.rst | 75 +++++++++ arch/x86/coco/tdx/tdx.c | 115 +++++++++++++ arch/x86/include/uapi/asm/tdx.h | 56 +++++++ tools/arch/x86/include/uapi/asm/tdx.h | 56 +++++++ tools/testing/selftests/Makefile | 1 + tools/testing/selftests/tdx/Makefile | 11 ++ tools/testing/selftests/tdx/config | 1 + tools/testing/selftests/tdx/tdx_attest_test.c | 157 ++++++++++++++++++ 8 files changed, 472 insertions(+) create mode 100644 arch/x86/include/uapi/asm/tdx.h create mode 100644 tools/arch/x86/include/uapi/asm/tdx.h create mode 100644 tools/testing/selftests/tdx/Makefile create mode 100644 tools/testing/selftests/tdx/config create mode 100644 tools/testing/selftests/tdx/tdx_attest_test.c
Attestation is used to verify the TDX guest trustworthiness to other entities before provisioning secrets to the guest. For example, a key server may request for attestation before releasing the encryption keys to mount the encrypted rootfs or secondary drive.
During the TDX guest launch, the initial contents (including the firmware image) and configuration of the guest are recorded by the Intel TDX module in build time measurement register (MRTD). After TDX guest is created, run-time measurement registers (RTMRs) can be used by the guest software to extend the measurements. TDX supports 4 RTMR registers, and TDG.MR.RTMR.EXTEND TDCALL is used to update the RTMR registers securely. RTMRs are mainly used to record measurements related to sections like the kernel image, command line parameters, initrd, ACPI tables, firmware data, configuration firmware volume (CFV) of TDVF, etc. For complete details, please refer to TDX Virtual Firmware design specification, sec titled "TD Measurement".
At TDX guest runtime, the Intel TDX module reuses the Intel SGX attestation infrastructure to provide support for attesting to these measurements as described below.
The attestation process consists of two steps: TDREPORT generation and Quote generation.
TDREPORT (TDREPORT_STRUCT) is a fixed-size data structure generated by the TDX module which contains guest-specific information (such as build and boot measurements), platform security version, and the MAC to protect the integrity of the TDREPORT. The guest kernel uses TDCALL[TDG.MR.REPORT] to get the TDREPORT from the TDX module. A user-provided 64-Byte REPORTDATA is used as input and included in the TDREPORT. Typically it can be some nonce provided by attestation service so the TDREPORT can be verified uniquely. More details about the TDREPORT can be found in Intel TDX Module specification, section titled "TDG.MR.REPORT Leaf".
TDREPORT by design can only be verified on the local platform as the MAC key is bound to the platform. To support remote verification of the TDREPORT, TDX leverages Intel SGX Quote Enclave (QE) to verify the TDREPORT locally and convert it to a remote verifiable Quote.
After getting the TDREPORT, the second step of the attestation process is to send it to the QE to generate the Quote. TDX doesn't support SGX inside the guest, so the QE can be deployed in the host, or in another legacy VM with SGX support. QE checks the integrity of TDREPORT and if it is valid, a certified quote signing key is used to sign the Quote. How to send the TDREPORT to QE and receive the Quote is implementation and deployment specific.
Implement a basic guest misc driver to allow userspace to get the TDREPORT. After getting TDREPORT, the userspace attestation software can choose whatever communication channel available (i.e. vsock or hypercall) to send the TDREPORT to QE and receive the Quote.
Also note that explicit access permissions are not enforced in this driver because the quote and measurements are not a secret. However the access permissions of the device node can be used to set any desired access policy. The udev default is usually root access only.
Operations like getting TDREPORT or Quote generation involves sending a blob of data as input and getting another blob of data as output. It was considered to use a sysfs interface for this, but it doesn't fit well into the standard sysfs model for configuring values. It would be possible to do read/write on files, but it would need multiple file descriptors, which would be somewhat messy. IOCTLs seems to be the best fitting and simplest model for this use case. This is similar to AMD SEV platform, which also uses IOCTL interface to support attestation.
Any distribution enabling TDX is also expected to need attestation. So enable it by default with TDX guest support.
Reviewed-by: Tony Luck tony.luck@intel.com Reviewed-by: Andi Kleen ak@linux.intel.com Acked-by: Kirill A. Shutemov kirill.shutemov@linux.intel.com Acked-by: Kai Huang kai.huang@intel.com Acked-by: Wander Lairson Costa wander@redhat.com Signed-off-by: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppuswamy@linux.intel.com ---
Changes since v12: * Added check to ensure reserved entries are set as 0.
Changes since v11: * Renamed DRIVER_NAME to TDX_GUEST_DEVICE and moved it to arch/x86/include/uapi/asm/tdx.h. * Fixed default error number in tdx_guest_ioctl(). * Moved tdx_misc_dev definition out of tdx_guest_init() as per Greg's suggestion. * Reordered struct tdx_report_req to avoid holes and added required padding.
Changes since v10: * Replaced TD/TD Guest usage with TDX Guest or Guest. * Removed unnecessary comments. * Added more validation to user input in tdx_get_report(). * Used u64_to_user_ptr when reading user u64 pointers. * Fixed commit log as per review comments.
Changes since v9: * Dropped the cover letter. Since this patch set only adds TDREPORT support, the commit log itself has all the required details. * Dropped the Quote support and event IRQ support as per Dave's review suggestion. * Dropped attest.c and moved its contents to tdx.c * Updated commit log and comments to reflect latest changes.
Changes since v8: * Please refer to https://lore.kernel.org/all/ \ 20220728034420.648314-1-sathyanarayanan.kuppuswamy@linux.intel.com/
arch/x86/coco/tdx/tdx.c | 115 ++++++++++++++++++++++++++++++++ arch/x86/include/uapi/asm/tdx.h | 56 ++++++++++++++++ 2 files changed, 171 insertions(+) create mode 100644 arch/x86/include/uapi/asm/tdx.h
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 928dcf7a20d9..8b5c59110321 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -5,16 +5,21 @@ #define pr_fmt(fmt) "tdx: " fmt
#include <linux/cpufeature.h> +#include <linux/miscdevice.h> +#include <linux/mm.h> +#include <linux/io.h> #include <asm/coco.h> #include <asm/tdx.h> #include <asm/vmx.h> #include <asm/insn.h> #include <asm/insn-eval.h> #include <asm/pgtable.h> +#include <uapi/asm/tdx.h>
/* TDX module Call Leaf IDs */ #define TDX_GET_INFO 1 #define TDX_GET_VEINFO 3 +#define TDX_GET_REPORT 4 #define TDX_ACCEPT_PAGE 6
/* TDX hypercall Leaf IDs */ @@ -775,3 +780,113 @@ void __init tdx_early_init(void)
pr_info("Guest detected\n"); } + +static long tdx_get_report(void __user *argp) +{ + u8 *reportdata, *tdreport; + struct tdx_report_req req; + u8 reserved[7] = {0}; + long ret; + + if (copy_from_user(&req, argp, sizeof(req))) + return -EFAULT; + + /* + * Per TDX Module 1.0 specification, section titled + * "TDG.MR.REPORT", REPORTDATA length is fixed as + * TDX_REPORTDATA_LEN, TDREPORT length is fixed as + * TDX_REPORT_LEN, and TDREPORT subtype is fixed as + * 0. Also check for valid user pointers and make sure + * reserved entries values are zero. + */ + if (!req.reportdata || !req.tdreport || req.subtype || + req.rpd_len != TDX_REPORTDATA_LEN || + req.tdr_len != TDX_REPORT_LEN || + memcmp(req.reserved, reserved, 7)) + return -EINVAL; + + reportdata = kmalloc(req.rpd_len, GFP_KERNEL); + if (!reportdata) + return -ENOMEM; + + tdreport = kzalloc(req.tdr_len, GFP_KERNEL); + if (!tdreport) { + kfree(reportdata); + return -ENOMEM; + } + + if (copy_from_user(reportdata, u64_to_user_ptr(req.reportdata), + req.rpd_len)) { + ret = -EFAULT; + goto out; + } + + /* + * Generate TDREPORT using "TDG.MR.REPORT" TDCALL. + * + * Get the TDREPORT using REPORTDATA as input. Refer to + * section 22.3.3 TDG.MR.REPORT leaf in the TDX Module 1.0 + * Specification for detailed information. + */ + ret = __tdx_module_call(TDX_GET_REPORT, virt_to_phys(tdreport), + virt_to_phys(reportdata), req.subtype, + 0, NULL); + if (ret) { + ret = -EIO; + goto out; + } + + if (copy_to_user(u64_to_user_ptr(req.tdreport), tdreport, req.tdr_len)) + ret = -EFAULT; + +out: + kfree(reportdata); + kfree(tdreport); + return ret; +} +static long tdx_guest_ioctl(struct file *file, unsigned int cmd, + unsigned long arg) +{ + void __user *argp = (void __user *)arg; + long ret = -ENOTTY; + + switch (cmd) { + case TDX_CMD_GET_REPORT: + ret = tdx_get_report(argp); + break; + default: + pr_debug("cmd %d not supported\n", cmd); + break; + } + + return ret; +} + +static const struct file_operations tdx_guest_fops = { + .owner = THIS_MODULE, + .unlocked_ioctl = tdx_guest_ioctl, + .llseek = no_llseek, +}; + +static struct miscdevice tdx_misc_dev = { + .name = TDX_GUEST_DEVICE, + .minor = MISC_DYNAMIC_MINOR, + .fops = &tdx_guest_fops, +}; + +static int __init tdx_guest_init(void) +{ + int ret; + + if (!cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) + return -EIO; + + ret = misc_register(&tdx_misc_dev); + if (ret) { + pr_err("misc device registration failed\n"); + return ret; + } + + return 0; +} +device_initcall(tdx_guest_init) diff --git a/arch/x86/include/uapi/asm/tdx.h b/arch/x86/include/uapi/asm/tdx.h new file mode 100644 index 000000000000..687c86c9e3fb --- /dev/null +++ b/arch/x86/include/uapi/asm/tdx.h @@ -0,0 +1,56 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef _UAPI_ASM_X86_TDX_H +#define _UAPI_ASM_X86_TDX_H + +#include <linux/types.h> +#include <linux/ioctl.h> + +#define TDX_GUEST_DEVICE "tdx-guest" + +/* Length of the REPORTDATA used in TDG.MR.REPORT TDCALL */ +#define TDX_REPORTDATA_LEN 64 + +/* Length of TDREPORT used in TDG.MR.REPORT TDCALL */ +#define TDX_REPORT_LEN 1024 + +/** + * struct tdx_report_req: Get TDREPORT using REPORTDATA as input. + * + * @reportdata : User-defined REPORTDATA to be included into + * TDREPORT. Typically it can be some nonce + * provided by attestation service, so the + * generated TDREPORT can be uniquely verified. + * @tdreport : TDREPORT output from TDCALL[TDG.MR.REPORT]. + * @rpd_len : Length of the REPORTDATA (fixed as 64 bytes by + * the TDX Module specification, but parameter is + * added to handle future extension). + * @tdr_len : Length of the TDREPORT (fixed as 1024 bytes by + * the TDX Module specification, but a parameter + * is added to accommodate future extension). + * @subtype : Subtype of TDREPORT (fixed as 0 by TDX Module + * specification, but added a parameter to handle + * future extension). + * @reserved : Reserved entries to handle future requirements. + * Default acceptable value is 0. + * + * Used in TDX_CMD_GET_REPORT IOCTL request. + */ +struct tdx_report_req { + __u64 reportdata; + __u64 tdreport; + __u32 rpd_len; + __u32 tdr_len; + __u8 subtype; + __u8 reserved[7]; +}; + +/* + * TDX_CMD_GET_REPORT - Get TDREPORT using TDCALL[TDG.MR.REPORT] + * + * Return 0 on success, -EIO on TDCALL execution failure, and + * standard errno on other general error cases. + * + */ +#define TDX_CMD_GET_REPORT _IOWR('T', 0x01, __u64) + +#endif /* _UAPI_ASM_X86_TDX_H */
On Fri, Sep 09, 2022 at 12:27:06PM -0700, Kuppuswamy Sathyanarayanan wrote:
Attestation is used to verify the TDX guest trustworthiness to other entities before provisioning secrets to the guest. For example, a key server may request for attestation before releasing the encryption keys to mount the encrypted rootfs or secondary drive.
During the TDX guest launch, the initial contents (including the firmware image) and configuration of the guest are recorded by the Intel TDX module in build time measurement register (MRTD). After TDX guest is created, run-time measurement registers (RTMRs) can be used by the guest software to extend the measurements. TDX supports 4 RTMR registers, and TDG.MR.RTMR.EXTEND TDCALL is used to update the RTMR registers securely. RTMRs are mainly used to record measurements related to sections like the kernel image, command line parameters, initrd, ACPI tables, firmware data, configuration firmware volume (CFV) of TDVF, etc. For complete details, please refer to TDX Virtual Firmware design specification, sec titled "TD Measurement".
At TDX guest runtime, the Intel TDX module reuses the Intel SGX attestation infrastructure to provide support for attesting to these measurements as described below.
The attestation process consists of two steps: TDREPORT generation and Quote generation.
TDREPORT (TDREPORT_STRUCT) is a fixed-size data structure generated by the TDX module which contains guest-specific information (such as build and boot measurements), platform security version, and the MAC to protect the integrity of the TDREPORT. The guest kernel uses TDCALL[TDG.MR.REPORT] to get the TDREPORT from the TDX module. A user-provided 64-Byte REPORTDATA is used as input and included in the TDREPORT. Typically it can be some nonce provided by attestation service so the TDREPORT can be verified uniquely. More details about the TDREPORT can be found in Intel TDX Module specification, section titled "TDG.MR.REPORT Leaf".
TDREPORT by design can only be verified on the local platform as the MAC key is bound to the platform. To support remote verification of the TDREPORT, TDX leverages Intel SGX Quote Enclave (QE) to verify the TDREPORT locally and convert it to a remote verifiable Quote.
After getting the TDREPORT, the second step of the attestation process is to send it to the QE to generate the Quote. TDX doesn't support SGX inside the guest, so the QE can be deployed in the host, or in another legacy VM with SGX support. QE checks the integrity of TDREPORT and if it is valid, a certified quote signing key is used to sign the Quote. How to send the TDREPORT to QE and receive the Quote is implementation and deployment specific.
Implement a basic guest misc driver to allow userspace to get the TDREPORT. After getting TDREPORT, the userspace attestation software can choose whatever communication channel available (i.e. vsock or hypercall) to send the TDREPORT to QE and receive the Quote.
Also note that explicit access permissions are not enforced in this driver because the quote and measurements are not a secret. However the access permissions of the device node can be used to set any desired access policy. The udev default is usually root access only.
Operations like getting TDREPORT or Quote generation involves sending a blob of data as input and getting another blob of data as output. It was considered to use a sysfs interface for this, but it doesn't fit well into the standard sysfs model for configuring values. It would be possible to do read/write on files, but it would need multiple file descriptors, which would be somewhat messy. IOCTLs seems to be the best fitting and simplest model for this use case. This is similar to AMD SEV platform, which also uses IOCTL interface to support attestation.
Any distribution enabling TDX is also expected to need attestation. So enable it by default with TDX guest support.
Reviewed-by: Tony Luck tony.luck@intel.com Reviewed-by: Andi Kleen ak@linux.intel.com Acked-by: Kirill A. Shutemov kirill.shutemov@linux.intel.com Acked-by: Kai Huang kai.huang@intel.com Acked-by: Wander Lairson Costa wander@redhat.com Signed-off-by: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppuswamy@linux.intel.com
Changes since v12:
- Added check to ensure reserved entries are set as 0.
Changes since v11:
- Renamed DRIVER_NAME to TDX_GUEST_DEVICE and moved it to arch/x86/include/uapi/asm/tdx.h.
- Fixed default error number in tdx_guest_ioctl().
- Moved tdx_misc_dev definition out of tdx_guest_init() as per Greg's suggestion.
- Reordered struct tdx_report_req to avoid holes and added required padding.
Changes since v10:
- Replaced TD/TD Guest usage with TDX Guest or Guest.
- Removed unnecessary comments.
- Added more validation to user input in tdx_get_report().
- Used u64_to_user_ptr when reading user u64 pointers.
- Fixed commit log as per review comments.
Changes since v9:
- Dropped the cover letter. Since this patch set only adds TDREPORT support, the commit log itself has all the required details.
- Dropped the Quote support and event IRQ support as per Dave's review suggestion.
- Dropped attest.c and moved its contents to tdx.c
- Updated commit log and comments to reflect latest changes.
Changes since v8:
- Please refer to https://lore.kernel.org/all/ \ 20220728034420.648314-1-sathyanarayanan.kuppuswamy@linux.intel.com/
arch/x86/coco/tdx/tdx.c | 115 ++++++++++++++++++++++++++++++++ arch/x86/include/uapi/asm/tdx.h | 56 ++++++++++++++++ 2 files changed, 171 insertions(+) create mode 100644 arch/x86/include/uapi/asm/tdx.h
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 928dcf7a20d9..8b5c59110321 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -5,16 +5,21 @@ #define pr_fmt(fmt) "tdx: " fmt #include <linux/cpufeature.h> +#include <linux/miscdevice.h> +#include <linux/mm.h> +#include <linux/io.h> #include <asm/coco.h> #include <asm/tdx.h> #include <asm/vmx.h> #include <asm/insn.h> #include <asm/insn-eval.h> #include <asm/pgtable.h> +#include <uapi/asm/tdx.h> /* TDX module Call Leaf IDs */ #define TDX_GET_INFO 1 #define TDX_GET_VEINFO 3 +#define TDX_GET_REPORT 4 #define TDX_ACCEPT_PAGE 6 /* TDX hypercall Leaf IDs */ @@ -775,3 +780,113 @@ void __init tdx_early_init(void) pr_info("Guest detected\n"); }
+static long tdx_get_report(void __user *argp) +{
- u8 *reportdata, *tdreport;
- struct tdx_report_req req;
- u8 reserved[7] = {0};
Where is the magic "7" coming from?
- long ret;
- if (copy_from_user(&req, argp, sizeof(req)))
return -EFAULT;- /*
* Per TDX Module 1.0 specification, section titled* "TDG.MR.REPORT", REPORTDATA length is fixed as* TDX_REPORTDATA_LEN, TDREPORT length is fixed as* TDX_REPORT_LEN, and TDREPORT subtype is fixed as* 0. Also check for valid user pointers and make sure* reserved entries values are zero.*/- if (!req.reportdata || !req.tdreport || req.subtype ||
req.rpd_len != TDX_REPORTDATA_LEN ||req.tdr_len != TDX_REPORT_LEN ||memcmp(req.reserved, reserved, 7))
Again, magic number?
thanks,
greg k-h
On 9/9/22 12:27, Kuppuswamy Sathyanarayanan wrote:
- u8 reserved[7] = {0};
...
- if (!req.reportdata || !req.tdreport || req.subtype ||
req.rpd_len != TDX_REPORTDATA_LEN ||req.tdr_len != TDX_REPORT_LEN ||memcmp(req.reserved, reserved, 7))return -EINVAL;
Huh, so to look for 0's, you:
1. Declare an on-stack structure with a hard coded, magic numbered field that has to be zeroed. 2. memcmp() that structure 3. Feed memcmp() with another hard coded magic number
I've gotta ask: did you have any reservations writing this code? Were there any alarm bells going off saying that something might be wrong?
Using memcmp() itself is probably forgivable. But, the two magic numbers are pretty mortal sins in my book. What's going to happen the first moment someone wants to repurpose a reserved byte? They're going to do:
- __u8 reserved[7]; + __u8 my_new_byte; + __u8 reserved[6];
What's going to happen to the code you wrote? Will it continue to work? Or will the memcmp() silently start doing crazy stuff as it overruns the structure into garbage land?
What's wrong with:
memchr_inv(&req.reserved, sizeof(req.reserved), 0)
On 9/9/22 12:41 PM, Dave Hansen wrote:
On 9/9/22 12:27, Kuppuswamy Sathyanarayanan wrote:
- u8 reserved[7] = {0};
...
- if (!req.reportdata || !req.tdreport || req.subtype ||
req.rpd_len != TDX_REPORTDATA_LEN ||req.tdr_len != TDX_REPORT_LEN ||memcmp(req.reserved, reserved, 7))return -EINVAL;Huh, so to look for 0's, you:
- Declare an on-stack structure with a hard coded, magic numbered field that has to be zeroed.
- memcmp() that structure
- Feed memcmp() with another hard coded magic number
I've gotta ask: did you have any reservations writing this code? Were there any alarm bells going off saying that something might be wrong?
Using memcmp() itself is probably forgivable. But, the two magic numbers are pretty mortal sins in my book. What's going to happen the first moment someone wants to repurpose a reserved byte? They're going to do:
- __u8 reserved[7];
- __u8 my_new_byte;
- __u8 reserved[6];
What's going to happen to the code you wrote? Will it continue to work? Or will the memcmp() silently start doing crazy stuff as it overruns the structure into garbage land?
What's wrong with:
memchr_inv(&req.reserved, sizeof(req.reserved), 0)
I did not consider the hard coding issue. It is a mistake. Your suggestion looks better. I will use it.
On 9/9/22 13:07, Sathyanarayanan Kuppuswamy wrote:
What's wrong with:
memchr_inv(&req.reserved, sizeof(req.reserved), 0)
I did not consider the hard coding issue. It is a mistake. Your suggestion looks better. I will use it.
BTW... Please look at how memchr_inv() gets used in the kernel. Don't copy my nonsense too exactly.
On Fri, Sep 09, 2022 at 12:27:06PM -0700, Kuppuswamy Sathyanarayanan wrote:
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 928dcf7a20d9..8b5c59110321 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -5,16 +5,21 @@ #define pr_fmt(fmt) "tdx: " fmt #include <linux/cpufeature.h> +#include <linux/miscdevice.h> +#include <linux/mm.h> +#include <linux/io.h> #include <asm/coco.h> #include <asm/tdx.h> #include <asm/vmx.h> #include <asm/insn.h> #include <asm/insn-eval.h> #include <asm/pgtable.h> +#include <uapi/asm/tdx.h> /* TDX module Call Leaf IDs */ #define TDX_GET_INFO 1 #define TDX_GET_VEINFO 3 +#define TDX_GET_REPORT 4 #define TDX_ACCEPT_PAGE 6 /* TDX hypercall Leaf IDs */ @@ -775,3 +780,113 @@ void __init tdx_early_init(void) pr_info("Guest detected\n"); }
+static long tdx_get_report(void __user *argp) +{
- u8 *reportdata, *tdreport;
- struct tdx_report_req req;
- u8 reserved[7] = {0};
- long ret;
- if (copy_from_user(&req, argp, sizeof(req)))
return -EFAULT;- /*
* Per TDX Module 1.0 specification, section titled* "TDG.MR.REPORT", REPORTDATA length is fixed as* TDX_REPORTDATA_LEN, TDREPORT length is fixed as* TDX_REPORT_LEN, and TDREPORT subtype is fixed as* 0. Also check for valid user pointers and make sure* reserved entries values are zero.*/- if (!req.reportdata || !req.tdreport || req.subtype ||
req.rpd_len != TDX_REPORTDATA_LEN ||req.tdr_len != TDX_REPORT_LEN ||memcmp(req.reserved, reserved, 7))return -EINVAL;
Maybe make several checks instead of the monstrous one?
!req.reportdata and !req.tdreport look redundant. copy_from/to_user() will catch them (and other bad address cases). And -EFAULT is more appropriate in this case.
- reportdata = kmalloc(req.rpd_len, GFP_KERNEL);
- if (!reportdata)
return -ENOMEM;- tdreport = kzalloc(req.tdr_len, GFP_KERNEL);
- if (!tdreport) {
kfree(reportdata);return -ENOMEM;- }
- if (copy_from_user(reportdata, u64_to_user_ptr(req.reportdata),
req.rpd_len)) {ret = -EFAULT;goto out;- }
- /*
* Generate TDREPORT using "TDG.MR.REPORT" TDCALL.** Get the TDREPORT using REPORTDATA as input. Refer to* section 22.3.3 TDG.MR.REPORT leaf in the TDX Module 1.0* Specification for detailed information.*/- ret = __tdx_module_call(TDX_GET_REPORT, virt_to_phys(tdreport),
virt_to_phys(reportdata), req.subtype,0, NULL);- if (ret) {
ret = -EIO;
The spec says that it generate an error if invalid operand or busy. Maybe translate the TDX error codes to errnos?
BTW, regarding busy case: do we want to protect against two parallel TDX_GET_REPORT? What happens if we run the second TDX_GET_REPORT when the first hasn't complete?
goto out;- }
- if (copy_to_user(u64_to_user_ptr(req.tdreport), tdreport, req.tdr_len))
ret = -EFAULT;+out:
- kfree(reportdata);
- kfree(tdreport);
- return ret;
+} +static long tdx_guest_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)+{
- void __user *argp = (void __user *)arg;
- long ret = -ENOTTY;
Not a typewriter? Huh?
- switch (cmd) {
- case TDX_CMD_GET_REPORT:
ret = tdx_get_report(argp);break;- default:
pr_debug("cmd %d not supported\n", cmd);break;- }
- return ret;
+}
On 9/12/22 3:22 PM, Kirill A . Shutemov wrote:
On Fri, Sep 09, 2022 at 12:27:06PM -0700, Kuppuswamy Sathyanarayanan wrote:
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 928dcf7a20d9..8b5c59110321 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -5,16 +5,21 @@ #define pr_fmt(fmt) "tdx: " fmt #include <linux/cpufeature.h> +#include <linux/miscdevice.h> +#include <linux/mm.h> +#include <linux/io.h> #include <asm/coco.h> #include <asm/tdx.h> #include <asm/vmx.h> #include <asm/insn.h> #include <asm/insn-eval.h> #include <asm/pgtable.h> +#include <uapi/asm/tdx.h> /* TDX module Call Leaf IDs */ #define TDX_GET_INFO 1 #define TDX_GET_VEINFO 3 +#define TDX_GET_REPORT 4 #define TDX_ACCEPT_PAGE 6 /* TDX hypercall Leaf IDs */ @@ -775,3 +780,113 @@ void __init tdx_early_init(void) pr_info("Guest detected\n"); }
+static long tdx_get_report(void __user *argp) +{
- u8 *reportdata, *tdreport;
- struct tdx_report_req req;
- u8 reserved[7] = {0};
- long ret;
- if (copy_from_user(&req, argp, sizeof(req)))
return -EFAULT;- /*
* Per TDX Module 1.0 specification, section titled* "TDG.MR.REPORT", REPORTDATA length is fixed as* TDX_REPORTDATA_LEN, TDREPORT length is fixed as* TDX_REPORT_LEN, and TDREPORT subtype is fixed as* 0. Also check for valid user pointers and make sure* reserved entries values are zero.*/- if (!req.reportdata || !req.tdreport || req.subtype ||
req.rpd_len != TDX_REPORTDATA_LEN ||req.tdr_len != TDX_REPORT_LEN ||memcmp(req.reserved, reserved, 7))return -EINVAL;Maybe make several checks instead of the monstrous one?
Agree. I will split it into two checks. One for spec related checks and another for ABI validation.
!req.reportdata and !req.tdreport look redundant. copy_from/to_user() will catch them (and other bad address cases). And -EFAULT is more appropriate in this case.
We don't have to allocate kernel memory if we check it here. But I am not against letting copy_from/to_user() handle it. I will remove the NULL check.
- reportdata = kmalloc(req.rpd_len, GFP_KERNEL);
- if (!reportdata)
return -ENOMEM;- tdreport = kzalloc(req.tdr_len, GFP_KERNEL);
- if (!tdreport) {
kfree(reportdata);return -ENOMEM;- }
- if (copy_from_user(reportdata, u64_to_user_ptr(req.reportdata),
req.rpd_len)) {ret = -EFAULT;goto out;- }
- /*
* Generate TDREPORT using "TDG.MR.REPORT" TDCALL.** Get the TDREPORT using REPORTDATA as input. Refer to* section 22.3.3 TDG.MR.REPORT leaf in the TDX Module 1.0* Specification for detailed information.*/- ret = __tdx_module_call(TDX_GET_REPORT, virt_to_phys(tdreport),
virt_to_phys(reportdata), req.subtype,0, NULL);- if (ret) {
ret = -EIO;The spec says that it generate an error if invalid operand or busy. Maybe translate the TDX error codes to errnos?
User space has no need to know about the error code. In both error cases, if user wants report, request has to re-submitted. So there is no use in translating the error codes.
BTW, regarding busy case: do we want to protect against two parallel TDX_GET_REPORT? What happens if we run the second TDX_GET_REPORT when the first hasn't complete?
We don't have to protect against it here. It is a blocking call. So if user makes a parallel request, we will wait for TDX Module to service them in sequence.
goto out;- }
- if (copy_to_user(u64_to_user_ptr(req.tdreport), tdreport, req.tdr_len))
ret = -EFAULT;+out:
- kfree(reportdata);
- kfree(tdreport);
- return ret;
+} +static long tdx_guest_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)+{
- void __user *argp = (void __user *)arg;
- long ret = -ENOTTY;
Not a typewriter? Huh?
It is the recommended return code for invalid IOCTL commands.
https://www.kernel.org/doc/html/latest/driver-api/ioctl.html
- switch (cmd) {
- case TDX_CMD_GET_REPORT:
ret = tdx_get_report(argp);break;- default:
pr_debug("cmd %d not supported\n", cmd);break;- }
- return ret;
+}
On Fri, 2022-09-09 at 12:27 -0700, Kuppuswamy Sathyanarayanan wrote:
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 928dcf7a20d9..8b5c59110321 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -5,16 +5,21 @@  #define pr_fmt(fmt)    "tdx: " fmt   #include <linux/cpufeature.h> +#include <linux/miscdevice.h> +#include <linux/mm.h> +#include <linux/io.h>
Sorry perhaps I am missing something, but what is the reason to include <linux/mm.h>?
<linux/io.h> is for virt_to_phys()?
And should we explicitly include <linux/uaccess.h> for copy_{from|to}_user(), and include the header (<linux/string.h> ?) for memchr_inv()?
On 9/12/22 6:25 PM, Huang, Kai wrote:
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 928dcf7a20d9..8b5c59110321 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -5,16 +5,21 @@  #define pr_fmt(fmt)    "tdx: " fmt   #include <linux/cpufeature.h> +#include <linux/miscdevice.h> +#include <linux/mm.h> +#include <linux/io.h>
Sorry perhaps I am missing something, but what is the reason to include <linux/mm.h>?
It is included for kmalloc/kfree, file related structs and copy_{from|to}_user().
<linux/io.h> is for virt_to_phys()?
Yes
And should we explicitly include <linux/uaccess.h> for copy_{from|to}_user(),
mm.h covers it. So I don't think we should explicitly include it.
and include the header (<linux/string.h> ?) for memchr_inv()?
One of the previous headers includes linux/string.h (I am not sure which one). So why include it explicitly?
On Mon, 2022-09-12 at 19:44 -0700, Sathyanarayanan Kuppuswamy wrote:
On 9/12/22 6:25 PM, Huang, Kai wrote:
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 928dcf7a20d9..8b5c59110321 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -5,16 +5,21 @@  #define pr_fmt(fmt)    "tdx: " fmt   #include <linux/cpufeature.h> +#include <linux/miscdevice.h> +#include <linux/mm.h> +#include <linux/io.h>
Sorry perhaps I am missing something, but what is the reason to include <linux/mm.h>?
It is included for kmalloc/kfree, file related structs and copy_{from|to}_user().
<linux/io.h> is for virt_to_phys()?
Yes
And should we explicitly include <linux/uaccess.h> for copy_{from|to}_user(),
mm.h covers it. So I don't think we should explicitly include it.
and include the header (<linux/string.h> ?) for memchr_inv()?
One of the previous headers includes linux/string.h (I am not sure which one). So why include it explicitly?
OK.
On 9/12/22 19:44, Sathyanarayanan Kuppuswamy wrote:
and include the header (<linux/string.h> ?) for memchr_inv()?
One of the previous headers includes linux/string.h (I am not sure which one). So why include it explicitly?
Because it's a best practice. What happens is that you ride along on the coat tails of another #include, someone sees that include is no longer used and removes it. Then, your code is busted on some weird .config.
*OR*, the header itself changes and doesn't #include the dependency you need.
I guess you can go add this advice to Documentation/ if it's not there already somewhere.
Hi,
On 9/13/22 2:01 AM, Dave Hansen wrote:
On 9/12/22 19:44, Sathyanarayanan Kuppuswamy wrote:
and include the header (<linux/string.h> ?) for memchr_inv()?
One of the previous headers includes linux/string.h (I am not sure which one). So why include it explicitly?
Because it's a best practice. What happens is that you ride along on the coat tails of another #include, someone sees that include is no longer used and removes it. Then, your code is busted on some weird .config.
*OR*, the header itself changes and doesn't #include the dependency you need.
I guess you can go add this advice to Documentation/ if it's not there already somewhere.
Ok. I will include it explicitly.
On 9/9/22 12:27, Kuppuswamy Sathyanarayanan wrote:
arch/x86/coco/tdx/tdx.c | 115 ++++++++++++++++++++++++++++++++ arch/x86/include/uapi/asm/tdx.h | 56 ++++++++++++++++ 2 files changed, 171 insertions(+) create mode 100644 arch/x86/include/uapi/asm/tdx.h
The SEV equivalent of this in in:
drivers/virt/coco/sev-guest/sev-guest.c
right?
Why did you choose a different location? Also, can you please study the SEV implementation a bit? It might help you find problems like the ioctl() return code issue. The SEV driver appears to have gotten that right.
On 9/14/22 4:36 AM, Dave Hansen wrote:
On 9/9/22 12:27, Kuppuswamy Sathyanarayanan wrote:
arch/x86/coco/tdx/tdx.c | 115 ++++++++++++++++++++++++++++++++ arch/x86/include/uapi/asm/tdx.h | 56 ++++++++++++++++ 2 files changed, 171 insertions(+) create mode 100644 arch/x86/include/uapi/asm/tdx.h
The SEV equivalent of this in in:
drivers/virt/coco/sev-guest/sev-guest.c
right?
Why did you choose a different location? Also, can you please study the
When we initially submitted the attestation patches, virt/coco folder was not created. I initially kept this driver in platform/x86/, but later moved to arch/x86/coco based on the review comments in v4. There was a discussion about the need for a new config and the location of the driver. The outcome of that discussion is, since this is not a traditional driver, but a basic TDX feature, we don't need a special config and the code can be maintained in the arch/x86/coco folder.
https://lore.kernel.org/lkml/YmEfgn7fMcZ2oCnr@zn.tnic/
SEV implementation a bit? It might help you find problems like the ioctl() return code issue. The SEV driver appears to have gotten that right.
Ok.
On 9/14/22 08:36, Sathyanarayanan Kuppuswamy wrote:
When we initially submitted the attestation patches, virt/coco folder was not created. I initially kept this driver in platform/x86/, but later moved to arch/x86/coco based on the review comments in v4. There was a discussion about the need for a new config and the location of the driver. The outcome of that discussion is, since this is not a traditional driver, but a basic TDX feature, we don't need a special config and the code can be maintained in the arch/x86/coco folder.
Could you please include the following in this set somewhere:
"The code to do the SEV analog of this TDX functionality is in ___insert_path_here____. This code is different from that because ______reason______ so it is instead placed in ____other_path____."
?
On 9/14/22 9:12 AM, Dave Hansen wrote:
On 9/14/22 08:36, Sathyanarayanan Kuppuswamy wrote:
When we initially submitted the attestation patches, virt/coco folder was not created. I initially kept this driver in platform/x86/, but later moved to arch/x86/coco based on the review comments in v4. There was a discussion about the need for a new config and the location of the driver. The outcome of that discussion is, since this is not a traditional driver, but a basic TDX feature, we don't need a special config and the code can be maintained in the arch/x86/coco folder.
Could you please include the following in this set somewhere:
"The code to do the SEV analog of this TDX functionality is in ___insert_path_here____. This code is different from that because ______reason______ so it is instead placed in ____other_path____."
?
Ok. I will include it in the cover letter.
On 9/14/22 9:12 AM, Dave Hansen wrote:
On 9/14/22 08:36, Sathyanarayanan Kuppuswamy wrote:
When we initially submitted the attestation patches, virt/coco folder was not created. I initially kept this driver in platform/x86/, but later moved to arch/x86/coco based on the review comments in v4. There was a discussion about the need for a new config and the location of the driver. The outcome of that discussion is, since this is not a traditional driver, but a basic TDX feature, we don't need a special config and the code can be maintained in the arch/x86/coco folder.
Could you please include the following in this set somewhere:
"The code to do the SEV analog of this TDX functionality is in ___insert_path_here____. This code is different from that because ______reason______ so it is instead placed in ____other_path____."
?
I have also included info about why we don't use a separate config option for it.
The code for the SEV equivalent of this TDX attestation functionality can be found in drivers/virt/coco/sev-guest/. It is implemented as a platform module driver, and it can be enabled using the CONFIG_SEV_GUEST config option. However, in the case of TDX, it is implemented as a built-in driver in the arch/x86/coco/tdx/tdx.c because of the following reasons:
1. Attestation is expected to be needed by all distributions that support TDX. Therefore, using a separate configuration option is not necessary. With TDX support, it can be enabled by default, and a built-in driver model will work better in this use case. 2. Since it is not a conventional device driver and the code is very simple, creating an individual driver for it may be an overkill.
On Wed, Sep 14, 2022 at 05:30:45PM -0700, Sathyanarayanan Kuppuswamy wrote:
I have also included info about why we don't use a separate config option for it.
The code for the SEV equivalent of this TDX attestation functionality can be found in drivers/virt/coco/sev-guest/. It is implemented as a platform module driver, and it can be enabled using the CONFIG_SEV_GUEST config option. However, in the case of TDX, it is implemented as a built-in driver in the arch/x86/coco/tdx/tdx.c because of the following reasons:
- Attestation is expected to be needed by all distributions that support TDX. Therefore, using a separate configuration option is not necessary. With TDX support, it can be enabled by default, and a built-in driver model will work better in this use case.
No, that's not valid. Distros want to enable everything, but only load stuff that is only present. You don't allow this for this code, which isn't ok.
- Since it is not a conventional device driver and the code is very simple, creating an individual driver for it may be an overkill.
"simple" is not the issue, again, this should be a "normal" driver that autoloads when the hardware is present and not load when the hardware is not present. This is not "special" to avoid the normal functionality of all other drivers.
So again, no, this is not ok, fix this properly, don't be lazy.
thanks,
greg k-h
On Fri, Sep 09, 2022 at 12:27:06PM -0700, Kuppuswamy Sathyanarayanan wrote:
+static int __init tdx_guest_init(void) +{
- int ret;
- if (!cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
return -EIO;- ret = misc_register(&tdx_misc_dev);
- if (ret) {
pr_err("misc device registration failed\n");return ret;- }
- return 0;
+} +device_initcall(tdx_guest_init)
As mentioned elsewhere, make this a normal module_init() format and only load the module if the hardware is present. Don't just always be built/loaded, that's not ok.
thanks,
greg k-h
Hi,
On 9/15/22 4:09 AM, Greg Kroah-Hartman wrote:
On Fri, Sep 09, 2022 at 12:27:06PM -0700, Kuppuswamy Sathyanarayanan wrote:
+static int __init tdx_guest_init(void) +{
- int ret;
- if (!cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
return -EIO;- ret = misc_register(&tdx_misc_dev);
- if (ret) {
pr_err("misc device registration failed\n");return ret;- }
- return 0;
+} +device_initcall(tdx_guest_init)
As mentioned elsewhere, make this a normal module_init() format and only load the module if the hardware is present. Don't just always be
This feature needs to be enabled by default for all valid TDX guests.
If TDX support is enabled and the guest is a valid TDX guest, the "X86 FEATURE TDX GUEST" feature flag will be set. So looking for "if(!cpu feature enabled(X86 FEATURE TDX GUEST))" will ensure that the interface is only created in a valid TDX guest.
Even if we make it into a separate driver and use module init(), we'll have to use the same "if(!cpu feature enabled(X86 FEATURE TDX GUEST))" check to create and load the device. This approach was used in earlier versions of this driver. We later changed it to initcall because it appeared to be a roundabout approach.
Let me know if you still suggest to use module_init() model.
Following is the sample implementation with module_init() and this code will be compiled with CONFIG_INTEL_TDX_GUEST=y.
+static struct platform_driver tdx_attest_driver = { + .probe = tdx_attest_probe, + .remove = tdx_attest_remove, + .driver = { + .name = DRIVER_NAME, + }, +}; + +static int __init tdx_attest_init(void) +{ + int ret; + + /* Make sure we are in a valid TDX platform */ + if (!cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) + return -EIO; + + ret = platform_driver_register(&tdx_attest_driver); + if (ret) { + pr_err("failed to register driver, err=%d\n", ret); + return ret; + } + + pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0); + if (IS_ERR(pdev)) { + ret = PTR_ERR(pdev); + pr_err("failed to allocate device, err=%d\n", ret); + platform_driver_unregister(&tdx_attest_driver); + return ret; + } + + return 0; +} + +static void __exit tdx_attest_exit(void) +{ + platform_device_unregister(pdev); + platform_driver_unregister(&tdx_attest_driver); +} + +module_init(tdx_attest_init); +module_exit(tdx_attest_exit);
built/loaded, that's not ok.
thanks,
greg k-h
On Thu, Sep 15, 2022 at 08:22:37AM -0700, Sathyanarayanan Kuppuswamy wrote:
Hi,
On 9/15/22 4:09 AM, Greg Kroah-Hartman wrote:
On Fri, Sep 09, 2022 at 12:27:06PM -0700, Kuppuswamy Sathyanarayanan wrote:
+static int __init tdx_guest_init(void) +{
- int ret;
- if (!cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
return -EIO;- ret = misc_register(&tdx_misc_dev);
- if (ret) {
pr_err("misc device registration failed\n");return ret;- }
- return 0;
+} +device_initcall(tdx_guest_init)
As mentioned elsewhere, make this a normal module_init() format and only load the module if the hardware is present. Don't just always be
This feature needs to be enabled by default for all valid TDX guests.
Why? What is so needed by userspace to require this brand new char device node just to use TDX?
If TDX support is enabled and the guest is a valid TDX guest, the "X86 FEATURE TDX GUEST" feature flag will be set. So looking for "if(!cpu feature enabled(X86 FEATURE TDX GUEST))" will ensure that the interface is only created in a valid TDX guest.
Yes, but that's not the point. We don't just "build all drivers into the kernel and only bind to hardware we actually have". That's not how Linux works, sorry.
Even if we make it into a separate driver and use module init(), we'll have to use the same "if(!cpu feature enabled(X86 FEATURE TDX GUEST))" check to create and load the device. This approach was used in earlier versions of this driver. We later changed it to initcall because it appeared to be a roundabout approach.
Sorry, no, do it properly, have it be autoloaded only on the systems that have the cpu feature.
Let me know if you still suggest to use module_init() model.
Yes, it is a requirement. Do you want every driver to try to copy what you are doing here?
Following is the sample implementation with module_init() and this code will be compiled with CONFIG_INTEL_TDX_GUEST=y.
+static struct platform_driver tdx_attest_driver = {
- .probe = tdx_attest_probe,
- .remove = tdx_attest_remove,
- .driver = {
.name = DRIVER_NAME,- },
+};
+static int __init tdx_attest_init(void) +{
- int ret;
- /* Make sure we are in a valid TDX platform */
- if (!cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
return -EIO;- ret = platform_driver_register(&tdx_attest_driver);
- if (ret) {
pr_err("failed to register driver, err=%d\n", ret);return ret;- }
- pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
- if (IS_ERR(pdev)) {
ret = PTR_ERR(pdev);pr_err("failed to allocate device, err=%d\n", ret);platform_driver_unregister(&tdx_attest_driver);return ret;- }
- return 0;
+}
+static void __exit tdx_attest_exit(void) +{
- platform_device_unregister(pdev);
- platform_driver_unregister(&tdx_attest_driver);
+}
+module_init(tdx_attest_init); +module_exit(tdx_attest_exit);
Sorry, no, this too is not ok as you are not telling userspace if it needs to load your driver or not automatically. Please do this properly.
Basic issues like this shouldn't be showing up in v13 of a patch series. Please take the time and start over and go and get a lot of internal review before sending anything out again.
thanks,
greg k-h
Attestation is used to verify the trustworthiness of a TDX guest. During the guest bring-up, Intel TDX module measures and records the initial contents and configuration of the guest, and at runtime, guest software uses runtime measurement registers (RMTRs) to measure and record details related to kernel image, command line params, ACPI tables, initrd, etc. At TDX guest runtime, Intel SGX attestation infrastructure is re-used to attest to these measurement data.
First step in the TDX attestation process is to get the TDREPORT data. It is a fixed size data structure generated by the TDX module which includes the above mentioned measurements data, a MAC to protect the integerity of the TDREPORT, and a 64-Byte of user specified data passed during TDREPORT request which can uniquely identify the TDREPORT.
Intel's TDX guest driver exposes TDX_CMD_GET_REPORT IOCTL interface to get the TDREPORT from the user space.
Add a kernel selftest module to test this ABI and verify the validity of generated TDREPORT.
Reviewed-by: Tony Luck tony.luck@intel.com Reviewed-by: Andi Kleen ak@linux.intel.com Acked-by: Kirill A. Shutemov kirill.shutemov@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppuswamy@linux.intel.com ---
Changes since v12: * Changed #ifdef DEBUG usage with if (DEBUG). * Initialized reserved entries values to zero.
Changes since v11: * Renamed devname with TDX_GUEST_DEVNAME.
Changes since v10: * Replaced TD/TD Guest usage with guest or TDX guest. * Reworded the subject line.
Changes since v9: * Copied arch/x86/include/uapi/asm/tdx.h to tools/arch/x86/include to decouple header dependency between kernel source and tools dir. * Fixed Makefile to adapt to above change. * Fixed commit log and comments. * Added __packed to hardware structs.
Changes since v8: * Please refer to https://lore.kernel.org/all/ \ 20220728034420.648314-1-sathyanarayanan.kuppuswamy@linux.intel.com/
tools/arch/x86/include/uapi/asm/tdx.h | 56 +++++++ tools/testing/selftests/Makefile | 1 + tools/testing/selftests/tdx/Makefile | 11 ++ tools/testing/selftests/tdx/config | 1 + tools/testing/selftests/tdx/tdx_attest_test.c | 157 ++++++++++++++++++ 5 files changed, 226 insertions(+) create mode 100644 tools/arch/x86/include/uapi/asm/tdx.h create mode 100644 tools/testing/selftests/tdx/Makefile create mode 100644 tools/testing/selftests/tdx/config create mode 100644 tools/testing/selftests/tdx/tdx_attest_test.c
diff --git a/tools/arch/x86/include/uapi/asm/tdx.h b/tools/arch/x86/include/uapi/asm/tdx.h new file mode 100644 index 000000000000..687c86c9e3fb --- /dev/null +++ b/tools/arch/x86/include/uapi/asm/tdx.h @@ -0,0 +1,56 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef _UAPI_ASM_X86_TDX_H +#define _UAPI_ASM_X86_TDX_H + +#include <linux/types.h> +#include <linux/ioctl.h> + +#define TDX_GUEST_DEVICE "tdx-guest" + +/* Length of the REPORTDATA used in TDG.MR.REPORT TDCALL */ +#define TDX_REPORTDATA_LEN 64 + +/* Length of TDREPORT used in TDG.MR.REPORT TDCALL */ +#define TDX_REPORT_LEN 1024 + +/** + * struct tdx_report_req: Get TDREPORT using REPORTDATA as input. + * + * @reportdata : User-defined REPORTDATA to be included into + * TDREPORT. Typically it can be some nonce + * provided by attestation service, so the + * generated TDREPORT can be uniquely verified. + * @tdreport : TDREPORT output from TDCALL[TDG.MR.REPORT]. + * @rpd_len : Length of the REPORTDATA (fixed as 64 bytes by + * the TDX Module specification, but parameter is + * added to handle future extension). + * @tdr_len : Length of the TDREPORT (fixed as 1024 bytes by + * the TDX Module specification, but a parameter + * is added to accommodate future extension). + * @subtype : Subtype of TDREPORT (fixed as 0 by TDX Module + * specification, but added a parameter to handle + * future extension). + * @reserved : Reserved entries to handle future requirements. + * Default acceptable value is 0. + * + * Used in TDX_CMD_GET_REPORT IOCTL request. + */ +struct tdx_report_req { + __u64 reportdata; + __u64 tdreport; + __u32 rpd_len; + __u32 tdr_len; + __u8 subtype; + __u8 reserved[7]; +}; + +/* + * TDX_CMD_GET_REPORT - Get TDREPORT using TDCALL[TDG.MR.REPORT] + * + * Return 0 on success, -EIO on TDCALL execution failure, and + * standard errno on other general error cases. + * + */ +#define TDX_CMD_GET_REPORT _IOWR('T', 0x01, __u64) + +#endif /* _UAPI_ASM_X86_TDX_H */ diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile index 10b34bb03bc1..22bdb3d848f5 100644 --- a/tools/testing/selftests/Makefile +++ b/tools/testing/selftests/Makefile @@ -70,6 +70,7 @@ TARGETS += sync TARGETS += syscall_user_dispatch TARGETS += sysctl TARGETS += tc-testing +TARGETS += tdx TARGETS += timens ifneq (1, $(quicktest)) TARGETS += timers diff --git a/tools/testing/selftests/tdx/Makefile b/tools/testing/selftests/tdx/Makefile new file mode 100644 index 000000000000..014795420184 --- /dev/null +++ b/tools/testing/selftests/tdx/Makefile @@ -0,0 +1,11 @@ +# SPDX-License-Identifier: GPL-2.0 + +top_srcdir = ../../../.. + +LINUX_TOOL_ARCH_INCLUDE = $(top_srcdir)/tools/arch/x86/include + +CFLAGS += -O3 -Wl,-no-as-needed -Wall -static -I$(LINUX_TOOL_ARCH_INCLUDE) + +TEST_GEN_PROGS := tdx_attest_test + +include ../lib.mk diff --git a/tools/testing/selftests/tdx/config b/tools/testing/selftests/tdx/config new file mode 100644 index 000000000000..1340073a4abf --- /dev/null +++ b/tools/testing/selftests/tdx/config @@ -0,0 +1 @@ +CONFIG_INTEL_TDX_GUEST=y diff --git a/tools/testing/selftests/tdx/tdx_attest_test.c b/tools/testing/selftests/tdx/tdx_attest_test.c new file mode 100644 index 000000000000..122b25b38da7 --- /dev/null +++ b/tools/testing/selftests/tdx/tdx_attest_test.c @@ -0,0 +1,157 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Test TDX attestation + * + * Copyright (C) 2022 Intel Corporation. All rights reserved. + * + * Author: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppuswamy@linux.intel.com + */ + +#include <errno.h> +#include <fcntl.h> +#include <stdio.h> +#include <stdlib.h> +#include <sys/ioctl.h> +#include <sys/types.h> +#include <uapi/asm/tdx.h> + +#include "../kselftest_harness.h" + +#define TDX_GUEST_DEVNAME "/dev/"TDX_GUEST_DEVICE +#define HEX_DUMP_SIZE 8 +#define __packed __attribute__((packed)) + +#define DEBUG 0 + +/* + * Trusted Execution Environment (TEE) report (TDREPORT_STRUCT) type, + * sub type and version. More details can be found in TDX v1.0 Module + * specification, sec titled "REPORTTYPE". + */ +struct tdreport_type { + /* 0 - SGX, 81 -TDX, rest are reserved */ + __u8 type; + /* Default value is 0 */ + __u8 sub_type; + /* Default value is 0 */ + __u8 version; + __u8 reserved; +} __packed; + +/* + * struct reportmac - First field in the TRDREPORT_STRUCT. It is common + * to Intel’s TEE's e.g., SGX and TDX. It is MAC-protected and contains + * hashes of the remainder of the report structure which includes the + * TEE’s measurements, and where applicable, the measurements of additional + * TCB elements not reflected in CPUSVN – e.g., a SEAM’s measurements. + * More details can be found in TDX v1.0 Module specification, sec titled + * "REPORTMACSTRUCT" + */ +struct reportmac { + struct tdreport_type type; + __u8 reserved1[12]; + /* CPU security version */ + __u8 cpu_svn[16]; + /* SHA384 hash of TEE TCB INFO */ + __u8 tee_tcb_info_hash[48]; + /* SHA384 hash of TDINFO_STRUCT */ + __u8 tee_td_info_hash[48]; + /* User defined unique data passed in TDG.MR.REPORT request */ + __u8 reportdata[64]; + __u8 reserved2[32]; + __u8 mac[32]; +} __packed; + +/* + * struct td_info - It contains the measurements and initial configuration + * of the TDX Guest that was locked at initialization and a set of measurement + * registers that are run-time extendable. These values are copied from + * the TDCS by the TDG.MR.REPORT function. More details can be found in + * TDX v1.0 Module specification, sec titled "TDINFO_STRUCT". + */ +struct td_info { + /* TDX Guest attributes (like debug, spet_disable, etc) */ + __u8 attr[8]; + __u64 xfam; + /* Measurement registers */ + __u64 mrtd[6]; + __u64 mrconfigid[6]; + __u64 mrowner[6]; + __u64 mrownerconfig[6]; + /* Runtime measurement registers */ + __u64 rtmr[24]; + __u64 reserved[14]; +} __packed; + +struct tdreport { + /* Common to TDX/SGX of size 256 bytes */ + struct reportmac reportmac; + __u8 tee_tcb_info[239]; + __u8 reserved[17]; + /* Measurements and configuration data of size 512 byes */ + struct td_info tdinfo; +} __packed; + +static void print_array_hex(const char *title, const char *prefix_str, + const void *buf, int len) +{ + int i, rowsize = HEX_DUMP_SIZE; + const __u8 *ptr = buf; + + if (!len || !buf) + return; + + printf("\t\t%s", title); + + for (i = 0; i < len; i++) { + if (!(i % rowsize)) + printf("\n%s%.8x:", prefix_str, i); + printf(" %.2x", ptr[i]); + } + + printf("\n"); +} + +TEST(verify_report) +{ + __u8 reportdata[TDX_REPORTDATA_LEN]; + struct tdx_report_req req; + struct tdreport tdreport; + int devfd, i; + + devfd = open(TDX_GUEST_DEVNAME, O_RDWR | O_SYNC); + + ASSERT_LT(0, devfd); + + /* Generate sample report data */ + for (i = 0; i < TDX_REPORTDATA_LEN; i++) + reportdata[i] = i; + + /* Initialize IOCTL request */ + req.subtype = 0; + req.reportdata = (__u64)reportdata; + req.rpd_len = TDX_REPORTDATA_LEN; + req.tdreport = (__u64)&tdreport; + req.tdr_len = sizeof(tdreport); + + memset(req.reserved, 0, sizeof(req.reserved)); + + /* Get TDREPORT */ + ASSERT_EQ(0, ioctl(devfd, TDX_CMD_GET_REPORT, &req)); + + if (DEBUG) { + print_array_hex("\n\t\tTDX report data\n", "", + reportdata, sizeof(reportdata)); + + print_array_hex("\n\t\tTDX tdreport data\n", "", + &tdreport, sizeof(tdreport)); + } + + /* Make sure TDREPORT data includes the REPORTDATA passed */ + ASSERT_EQ(0, memcmp(&tdreport.reportmac.reportdata[0], + reportdata, sizeof(reportdata))); + + ASSERT_EQ(0, close(devfd)); +} + +TEST_HARNESS_MAIN
On Fri, 2022-09-09 at 12:27 -0700, Kuppuswamy Sathyanarayanan wrote:
Attestation is used to verify the trustworthiness of a TDX guest. During the guest bring-up, Intel TDX module measures and records the initial contents and configuration of the guest, and at runtime, guest software uses runtime measurement registers (RMTRs) to measure and record details related to kernel image, command line params, ACPI tables, initrd, etc. At TDX guest runtime, Intel SGX attestation infrastructure is re-used to attest to these measurement data.
Similar the comment to patch 3, I don't particularly like "to attest" part as only the verification service can truly _attest_ somthing (I suppose the "SGX infrastructure" here you mean SGX QE to generate the Quote).
I think you can just say something like "TDX leverages SGX Quote mechanism to support remote attestation of TDX guests". And you can combine this with below paragraph.
First step in the TDX attestation process is to get the TDREPORT data. It is a fixed size data structure generated by the TDX module which includes the above mentioned measurements data, a MAC to protect the integerity of the TDREPORT, and a 64-Byte of user specified data passed during TDREPORT request which can uniquely identify the TDREPORT.
Intel's TDX guest driver exposes TDX_CMD_GET_REPORT IOCTL interface to get the TDREPORT from the user space.
Add a kernel selftest module to test this ABI and verify the validity of generated TDREPORT.
Reviewed-by: Tony Luck tony.luck@intel.com Reviewed-by: Andi Kleen ak@linux.intel.com Acked-by: Kirill A. Shutemov kirill.shutemov@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppuswamy@linux.intel.com
Anyway (although still not sure all the definitions of TDX architectural data structures are needed):
Acked-by: Kai Huang kai.huang@intel.com
Hi Kai,
On 9/12/22 12:17 AM, Huang, Kai wrote:
On Fri, 2022-09-09 at 12:27 -0700, Kuppuswamy Sathyanarayanan wrote:
Attestation is used to verify the trustworthiness of a TDX guest. During the guest bring-up, Intel TDX module measures and records the initial contents and configuration of the guest, and at runtime, guest software uses runtime measurement registers (RMTRs) to measure and record details related to kernel image, command line params, ACPI tables, initrd, etc. At TDX guest runtime, Intel SGX attestation infrastructure is re-used to attest to these measurement data.
Similar the comment to patch 3, I don't particularly like "to attest" part as only the verification service can truly _attest_ somthing (I suppose the "SGX infrastructure" here you mean SGX QE to generate the Quote).
I think you can just say something like "TDX leverages SGX Quote mechanism to support remote attestation of TDX guests". And you can combine this with below paragraph.
The part about leveraging the SGX infrastructure is not very important. We can even drop it. But I want to add some details about what we do with this measurement data. In the first paragraph, we have started with collection of measurements data. If we directly jump to attestation process without explaining the need for collecting measurements, it will be a bit confusing.
How about following version?
Attestation is used to verify the trustworthiness of a TDX guest.
During the guest bring-up, Intel TDX module measures and records
the initial contents and configuration of the guest, and at runtime,
guest software uses runtime measurement registers (RMTRs) to measure
and record details related to kernel image, command line params, ACPI
tables, initrd, etc. At guest runtime, the attestation process is used to attest to these measurements.
First step in the TDX attestation process is to get the TDREPORT data. It is a fixed size data structure generated by the TDX module which includes the above mentioned measurements data, a MAC to protect the integerity of the TDREPORT, and a 64-Byte of user specified data passed during TDREPORT request which can uniquely identify the TDREPORT.
Intel's TDX guest driver exposes TDX_CMD_GET_REPORT IOCTL interface to get the TDREPORT from the user space.
Add a kernel selftest module to test this ABI and verify the validity of generated TDREPORT.
Reviewed-by: Tony Luck tony.luck@intel.com Reviewed-by: Andi Kleen ak@linux.intel.com Acked-by: Kirill A. Shutemov kirill.shutemov@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppuswamy@linux.intel.com
Anyway (although still not sure all the definitions of TDX architectural data structures are needed):
Acked-by: Kai Huang kai.huang@intel.com
On Mon, 2022-09-12 at 15:06 -0700, Sathyanarayanan Kuppuswamy wrote:
Hi Kai,
On 9/12/22 12:17 AM, Huang, Kai wrote:
On Fri, 2022-09-09 at 12:27 -0700, Kuppuswamy Sathyanarayanan wrote:
Attestation is used to verify the trustworthiness of a TDX guest. During the guest bring-up, Intel TDX module measures and records the initial contents and configuration of the guest, and at runtime, guest software uses runtime measurement registers (RMTRs) to measure and record details related to kernel image, command line params, ACPI tables, initrd, etc. At TDX guest runtime, Intel SGX attestation infrastructure is re-used to attest to these measurement data.
Similar the comment to patch 3, I don't particularly like "to attest" part as only the verification service can truly _attest_ somthing (I suppose the "SGX infrastructure" here you mean SGX QE to generate the Quote).
I think you can just say something like "TDX leverages SGX Quote mechanism to support remote attestation of TDX guests". And you can combine this with below paragraph.
The part about leveraging the SGX infrastructure is not very important. We can even drop it. But I want to add some details about what we do with this measurement data. In the first paragraph, we have started with collection of measurements data. If we directly jump to attestation process without explaining the need for collecting measurements, it will be a bit confusing.
How about following version?
Attestation is used to verify the trustworthiness of a TDX guest.
During the guest bring-up, Intel TDX module measures and records
the initial contents and configuration of the guest, and at runtime,
guest software uses runtime measurement registers (RMTRs) to measure
and record details related to kernel image, command line params, ACPI
tables, initrd, etc. At guest runtime, the attestation process is used to attest to these measurements.
Yeah fine to me.
On Fri, 2022-09-09 at 12:27 -0700, Kuppuswamy Sathyanarayanan wrote:
Intel's TDX guest driver exposes TDX_CMD_GET_REPORT IOCTL interface to get the TDREPORT from the user space.
(Sorry missed this one in previous reply).
Also, the IOCTL is to return the TDREPORT _to_ userspace, but not get the TDREPORT _from_ userspace.
On 9/12/22 12:21 AM, Huang, Kai wrote:
On Fri, 2022-09-09 at 12:27 -0700, Kuppuswamy Sathyanarayanan wrote:
Intel's TDX guest driver exposes TDX_CMD_GET_REPORT IOCTL interface to get the TDREPORT from the user space.
(Sorry missed this one in previous reply).
Also, the IOCTL is to return the TDREPORT _to_ userspace, but not get the TDREPORT _from_ userspace.
How about following?
Intel's TDX guest driver exposes TDX_CMD_GET_REPORT IOCTL interface to
enable guest user space get the TDREPORT.
On Mon, 2022-09-12 at 14:38 -0700, Sathyanarayanan Kuppuswamy wrote:
On 9/12/22 12:21 AM, Huang, Kai wrote:
On Fri, 2022-09-09 at 12:27 -0700, Kuppuswamy Sathyanarayanan wrote:
Intel's TDX guest driver exposes TDX_CMD_GET_REPORT IOCTL interface to get the TDREPORT from the user space.
(Sorry missed this one in previous reply).
Also, the IOCTL is to return the TDREPORT _to_ userspace, but not get the TDREPORT _from_ userspace.
How about following?
Intel's TDX guest driver exposes TDX_CMD_GET_REPORT IOCTL interface to
enable guest user space get the TDREPORT.
^ to get ?
Sure fine to me (as long as no grammar error).
Document details about TDX attestation process and related user API support.
Attestation details can be found in Guest-Host-Communication Interface (GHCI) for Intel Trust Domain Extensions (TDX), section titled "TD attestation".
[Bagas Sanjaya fixed htmldocs warning] Reviewed-by: Bagas Sanjaya bagasdotme@gmail.com Signed-off-by: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppuswamy@linux.intel.com ---
Change since v12: * None
Changes since v11: * Fixed htmldocs warnings.
Documentation/x86/tdx.rst | 75 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+)
diff --git a/Documentation/x86/tdx.rst b/Documentation/x86/tdx.rst index b8fa4329e1a5..c9e3ecf86e0b 100644 --- a/Documentation/x86/tdx.rst +++ b/Documentation/x86/tdx.rst @@ -210,6 +210,81 @@ converted to shared on boot. For coherent DMA allocation, the DMA buffer gets converted on the allocation. Check force_dma_unencrypted() for details.
+Attestation +=========== + +Attestation is used to verify the TDX guest trustworthiness to other +entities before provisioning secrets to the guest. For example, a key +server may request for attestation before releasing the encryption keys +to mount the encrypted rootfs or secondary drive. + +TDX module records the state of the TDX guest in various stages of guest +boot process using build time measurement register (MRTD) and runtime +measurement registers (RTMR). Measurements related to guest initial +configuration and firmware image is recorded in the MRTD register. +Measurements related to initial state, kernel image, firmware image, +command line options, initrd, ACPI tables, etc are recorded in RTMR +registers. For more details, please refer to TDX Virtual Firmware design +specification, sec titled "TD Measurement". + +At TDX guest runtime, the Intel TDX module reuses the Intel SGX attestation +infrastructure to provide support for attesting to these measurements as +described below. + +The attestation process consists of two steps: TDREPORT generation and +Quote generation. + +TDX guest uses TDCALL[TDG.MR.REPORT] to get the TDREPORT (TDREPORT_STRUCT) +from the TDX module. TDREPORT is a fixed-size data structure generated by +the TDX module which contains guest-specific information (such as build +and boot measurements), platform security version, and the MAC to protect +the integrity of the TDREPORT. + +After getting the TDREPORT, the second step of the attestation process +is to send it to the QE to generate the Quote. TDREPORT by design can only +be verified on local platform as the MAC key is bound to the platform. To +support remote verification of the TDREPORT, TDX leverages Intel SGX Quote +Enclave (QE) to verify the TDREPORT locally and convert it to a remote +verifiable Quote. Method of sending TDREPORT to QE is implemenentation +specific. Attestation software can choose whatever communication channel +available (i.e. vsock or hypercall) to send the TDREPORT to QE and receive +the Quote. + +To allow userspace attestation agent get the TDREPORT, TDX guest driver +exposes an IOCTL (TDX_CMD_GET_REPORT) interface via /dev/tdx-guest misc +device. + +TDX Guest driver +================ + +The TDX guest driver exposes IOCTL interfaces via /dev/tdx-guest misc +device to allow user space to get certain TDX guest specific details +(like attestation report, attestation quote or storage keys, etc). + +In this section, for each supported IOCTL, following information is +provided along with generic description. + +:Input parameters: Parameters passed to the IOCTL and related details. +:Output: Details about output data and return value (with details + about the non common error values). + +TDX_CMD_GET_REPORT +------------------ + +:Input parameters: struct tdx_report_req +:Output: Upon successful execution, TDREPORT data is copied to + tdx_report_req.tdreport and returns 0 or returns + -EIO on TDCALL failure and standard error number on + other common failures. + +The TDX_CMD_GET_REPORT IOCTL can be used by the attestation software to +get the TDX guest measurements data (with few other info) in the format +of TDREPORT_STRUCT. It uses TDCALL[TDG.MR.REPORT] to get the TDREPORT +from the TDX Module. + +Format of TDREPORT_STRUCT can be found in TDX 1.0 Module specification, +sec titled "TDREPORT_STRUCT". + References ==========
+At TDX guest runtime, the Intel TDX module reuses the Intel SGX attestation +infrastructure to provide support for attesting to these measurements as +described below.
The above paragraph isn't right. The Intel TDX module itself doesn't use anything about SGX (perhaps except using the key to generate the MAC for the TDREPORT, but it certainly doesn't use "SGX infrastructure" for sure). Even the new ENCLU leaf used to verify the TDREPORT is not part of the TDX module -- it's an extension to SGX to support TDX attestation.
Also, conceptually, only the verification service can truly _attest_ something. The SGX software stack running on the machine that hosts TDX guests doesn't actually _attest_ anything. It only can _generate_ something (Quote) that can be attested.
In below you already mentioned "TDX leverages Intel SGX Quote (should be Quoting I think) Enclave to ...". I don't think this paragraph is even necessary and you can just delete it.
If you really want to say, I think one simple sentence like "TDX leverages SGX to support attestation" is enough.
+The attestation process consists of two steps: TDREPORT generation and +Quote generation.
+TDX guest uses TDCALL[TDG.MR.REPORT] to get the TDREPORT (TDREPORT_STRUCT) +from the TDX module. TDREPORT is a fixed-size data structure generated by +the TDX module which contains guest-specific information (such as build +and boot measurements), platform security version, and the MAC to protect +the integrity of the TDREPORT.
+After getting the TDREPORT, the second step of the attestation process +is to send it to the QE to generate the Quote. TDREPORT by design can only +be verified on local platform as the MAC key is bound to the platform. To +support remote verification of the TDREPORT, TDX leverages Intel SGX Quote +Enclave (QE) to verify the TDREPORT locally and convert it to a remote +verifiable Quote. Method of sending TDREPORT to QE is implemenentation +specific. Attestation software can choose whatever communication channel +available (i.e. vsock or hypercall) to send the TDREPORT to QE and receive +the Quote.
+To allow userspace attestation agent get the TDREPORT, TDX guest driver
^ to get
+exposes an IOCTL (TDX_CMD_GET_REPORT) interface via /dev/tdx-guest misc +device.
+TDX Guest driver +================
+The TDX guest driver exposes IOCTL interfaces via /dev/tdx-guest misc +device to allow user space to get certain TDX guest specific details +(like attestation report, attestation quote or storage keys, etc).
Only TDX_CMD_GET_REPORT is supported now. Whether GetQuote TDVMCALL should be supported, or how should it be supported is unknown now. Not to mention "get the storage keys".
I don't think you should put anything here now except "allow userspace to get TDREPORT".
+In this section, for each supported IOCTL, following information is +provided along with generic description.
+:Input parameters: Parameters passed to the IOCTL and related details. +:Output: Details about output data and return value (with details
about the non common error values).+TDX_CMD_GET_REPORT +------------------
+:Input parameters: struct tdx_report_req +:Output: Upon successful execution, TDREPORT data is copied to
tdx_report_req.tdreport and returns 0 or returns-EIO on TDCALL failure and standard error number onother common failures.+The TDX_CMD_GET_REPORT IOCTL can be used by the attestation software to +get the TDX guest measurements data (with few other info) in the format +of TDREPORT_STRUCT.
IMHO "to get the TDREPORT" is enough. You already used TDREPORT in many places in this documentation (and in this series), and you have already explained it.
With above (at least errors) fixed:
Acked-by: Kai Huang kai.huang@intel.com
On 9/12/22 12:04 AM, Huang, Kai wrote:
+TDX Guest driver +================
+The TDX guest driver exposes IOCTL interfaces via /dev/tdx-guest misc +device to allow user space to get certain TDX guest specific details +(like attestation report, attestation quote or storage keys, etc).
Only TDX_CMD_GET_REPORT is supported now. Whether GetQuote TDVMCALL should be supported, or how should it be supported is unknown now. Not to mention "get the storage keys".
The reason for adding them is to give an idea that this driver in future could be used for use cases other than GetReport. Query about possible use cases came up in a previous review about /dev/tdx-guest device name usage. So I thought it is better to give a clear idea on how this device may be used in the future.
Maybe I can add a note that currently only attestation report is supported.
I don't think you should put anything here now except "allow userspace to get TDREPORT".
On Mon, 2022-09-12 at 07:15 -0700, Sathyanarayanan Kuppuswamy wrote:
On 9/12/22 12:04 AM, Huang, Kai wrote:
+TDX Guest driver +================
+The TDX guest driver exposes IOCTL interfaces via /dev/tdx-guest misc +device to allow user space to get certain TDX guest specific details +(like attestation report, attestation quote or storage keys, etc).
Only TDX_CMD_GET_REPORT is supported now. Whether GetQuote TDVMCALL should be supported, or how should it be supported is unknown now. Not to mention "get the storage keys".
The reason for adding them is to give an idea that this driver in future could be used for use cases other than GetReport. Query about possible use cases came up in a previous review about /dev/tdx-guest device name usage. So I thought it is better to give a clear idea on how this device may be used in the future.
But I don't think "attestation quote or storage keys" are good example, as it's uncertain, i.e. can be wrong to put here.
Maybe I can add a note that currently only attestation report is supported.
Maybe something like this?
" The TDX guest exposes /dev/tdx-guest to userspace to support all TDX guest specific operations in one driver. Currently only TDX_CMD_GET_RERPORT IOCTL is supported to return the TDREPORT to userspace to support attestation for the TDX guest. "
On Fri, Sep 09, 2022 at 12:27:08PM -0700, Kuppuswamy Sathyanarayanan wrote:
Document details about TDX attestation process and related user API support.
"related user API support" sounds wrong to me.
Maybe just "related userspace API"?
Attestation details can be found in Guest-Host-Communication Interface (GHCI) for Intel Trust Domain Extensions (TDX), section titled "TD attestation".
[Bagas Sanjaya fixed htmldocs warning] Reviewed-by: Bagas Sanjaya bagasdotme@gmail.com Signed-off-by: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppuswamy@linux.intel.com
Change since v12:
- None
Changes since v11:
- Fixed htmldocs warnings.
Documentation/x86/tdx.rst | 75 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+)
diff --git a/Documentation/x86/tdx.rst b/Documentation/x86/tdx.rst index b8fa4329e1a5..c9e3ecf86e0b 100644 --- a/Documentation/x86/tdx.rst +++ b/Documentation/x86/tdx.rst @@ -210,6 +210,81 @@ converted to shared on boot. For coherent DMA allocation, the DMA buffer gets converted on the allocation. Check force_dma_unencrypted() for details. +Attestation +===========
+Attestation is used to verify the TDX guest trustworthiness to other +entities before provisioning secrets to the guest. For example, a key +server may request for attestation before releasing the encryption keys +to mount the encrypted rootfs or secondary drive.
Maybe "may request attestation quote before ..."?
+TDX module records the state of the TDX guest in various stages of guest +boot process using build time measurement register (MRTD) and runtime +measurement registers (RTMR). Measurements related to guest initial +configuration and firmware image is recorded in the MRTD register. +Measurements related to initial state, kernel image, firmware image, +command line options, initrd, ACPI tables, etc are recorded in RTMR +registers. For more details, please refer to TDX Virtual Firmware design +specification, sec titled "TD Measurement".
+At TDX guest runtime, the Intel TDX module reuses the Intel SGX attestation +infrastructure to provide support for attesting to these measurements as +described below.
+The attestation process consists of two steps: TDREPORT generation and +Quote generation.
+TDX guest uses TDCALL[TDG.MR.REPORT] to get the TDREPORT (TDREPORT_STRUCT) +from the TDX module. TDREPORT is a fixed-size data structure generated by +the TDX module which contains guest-specific information (such as build +and boot measurements), platform security version, and the MAC to protect +the integrity of the TDREPORT.
+After getting the TDREPORT, the second step of the attestation process +is to send it to the QE to generate the Quote. TDREPORT by design can only
The first use of QE abbreviation is before it is defined. -EPARSE.
+be verified on local platform as the MAC key is bound to the platform. To +support remote verification of the TDREPORT, TDX leverages Intel SGX Quote +Enclave (QE) to verify the TDREPORT locally and convert it to a remote +verifiable Quote. Method of sending TDREPORT to QE is implemenentation +specific. Attestation software can choose whatever communication channel +available (i.e. vsock or hypercall) to send the TDREPORT to QE and receive +the Quote.
+To allow userspace attestation agent get the TDREPORT, TDX guest driver +exposes an IOCTL (TDX_CMD_GET_REPORT) interface via /dev/tdx-guest misc +device.
+TDX Guest driver +================
+The TDX guest driver exposes IOCTL interfaces via /dev/tdx-guest misc +device to allow user space to get certain TDX guest specific details +(like attestation report, attestation quote or storage keys, etc).
+In this section, for each supported IOCTL, following information is +provided along with generic description.
"for each" looks strange as we only have single IOCTL.
+:Input parameters: Parameters passed to the IOCTL and related details. +:Output: Details about output data and return value (with details
about the non common error values).+TDX_CMD_GET_REPORT +------------------
+:Input parameters: struct tdx_report_req +:Output: Upon successful execution, TDREPORT data is copied to
tdx_report_req.tdreport and returns 0 or returns-EIO on TDCALL failure and standard error number onother common failures.+The TDX_CMD_GET_REPORT IOCTL can be used by the attestation software to +get the TDX guest measurements data (with few other info) in the format +of TDREPORT_STRUCT. It uses TDCALL[TDG.MR.REPORT] to get the TDREPORT +from the TDX Module.
+Format of TDREPORT_STRUCT can be found in TDX 1.0 Module specification, +sec titled "TDREPORT_STRUCT".
On 9/13/22 10:54 AM, Kirill A . Shutemov wrote:
On Fri, Sep 09, 2022 at 12:27:08PM -0700, Kuppuswamy Sathyanarayanan wrote:
Document details about TDX attestation process and related user API support.
"related user API support" sounds wrong to me.
Maybe just "related userspace API"?
Ok
Attestation details can be found in Guest-Host-Communication Interface (GHCI) for Intel Trust Domain Extensions (TDX), section titled "TD attestation".
[Bagas Sanjaya fixed htmldocs warning] Reviewed-by: Bagas Sanjaya bagasdotme@gmail.com Signed-off-by: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppuswamy@linux.intel.com
Change since v12:
- None
Changes since v11:
- Fixed htmldocs warnings.
Documentation/x86/tdx.rst | 75 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+)
diff --git a/Documentation/x86/tdx.rst b/Documentation/x86/tdx.rst index b8fa4329e1a5..c9e3ecf86e0b 100644 --- a/Documentation/x86/tdx.rst +++ b/Documentation/x86/tdx.rst @@ -210,6 +210,81 @@ converted to shared on boot. For coherent DMA allocation, the DMA buffer gets converted on the allocation. Check force_dma_unencrypted() for details. +Attestation +===========
+Attestation is used to verify the TDX guest trustworthiness to other +entities before provisioning secrets to the guest. For example, a key +server may request for attestation before releasing the encryption keys +to mount the encrypted rootfs or secondary drive.
Maybe "may request attestation quote before ..."?
+TDX module records the state of the TDX guest in various stages of guest +boot process using build time measurement register (MRTD) and runtime +measurement registers (RTMR). Measurements related to guest initial +configuration and firmware image is recorded in the MRTD register. +Measurements related to initial state, kernel image, firmware image, +command line options, initrd, ACPI tables, etc are recorded in RTMR +registers. For more details, please refer to TDX Virtual Firmware design +specification, sec titled "TD Measurement".
+At TDX guest runtime, the Intel TDX module reuses the Intel SGX attestation +infrastructure to provide support for attesting to these measurements as +described below.
+The attestation process consists of two steps: TDREPORT generation and +Quote generation.
+TDX guest uses TDCALL[TDG.MR.REPORT] to get the TDREPORT (TDREPORT_STRUCT) +from the TDX module. TDREPORT is a fixed-size data structure generated by +the TDX module which contains guest-specific information (such as build +and boot measurements), platform security version, and the MAC to protect +the integrity of the TDREPORT.
+After getting the TDREPORT, the second step of the attestation process +is to send it to the QE to generate the Quote. TDREPORT by design can only
The first use of QE abbreviation is before it is defined. -EPARSE.
Yes. I already noticed it and fixed it.
+be verified on local platform as the MAC key is bound to the platform. To +support remote verification of the TDREPORT, TDX leverages Intel SGX Quote +Enclave (QE) to verify the TDREPORT locally and convert it to a remote +verifiable Quote. Method of sending TDREPORT to QE is implemenentation +specific. Attestation software can choose whatever communication channel +available (i.e. vsock or hypercall) to send the TDREPORT to QE and receive +the Quote.
+To allow userspace attestation agent get the TDREPORT, TDX guest driver +exposes an IOCTL (TDX_CMD_GET_REPORT) interface via /dev/tdx-guest misc +device.
+TDX Guest driver +================
+The TDX guest driver exposes IOCTL interfaces via /dev/tdx-guest misc +device to allow user space to get certain TDX guest specific details +(like attestation report, attestation quote or storage keys, etc).
+In this section, for each supported IOCTL, following information is +provided along with generic description.
"for each" looks strange as we only have single IOCTL.
I just want to give an overview of IOCTL documentation. Although we have only one IOCTL now, we have plans to extend it in near future. At least VERIFYEREPORT IOCTL will be added soon. Do you think I should still fix it? How about the following?
In this section, in addition to generic information of IOCTL, following details are provided.
+:Input parameters: Parameters passed to the IOCTL and related details. +:Output: Details about output data and return value (with details
about the non common error values).+TDX_CMD_GET_REPORT +------------------
+:Input parameters: struct tdx_report_req +:Output: Upon successful execution, TDREPORT data is copied to
tdx_report_req.tdreport and returns 0 or returns-EIO on TDCALL failure and standard error number onother common failures.+The TDX_CMD_GET_REPORT IOCTL can be used by the attestation software to +get the TDX guest measurements data (with few other info) in the format +of TDREPORT_STRUCT. It uses TDCALL[TDG.MR.REPORT] to get the TDREPORT +from the TDX Module.
+Format of TDREPORT_STRUCT can be found in TDX 1.0 Module specification, +sec titled "TDREPORT_STRUCT".
Hi Kirill/Kai,
On 9/13/22 10:54 AM, Kirill A . Shutemov wrote:
On Fri, Sep 09, 2022 at 12:27:08PM -0700, Kuppuswamy Sathyanarayanan wrote:
Document details about TDX attestation process and related user API support.
"related user API support" sounds wrong to me.
Maybe just "related userspace API"?
Attestation details can be found in Guest-Host-Communication Interface (GHCI) for Intel Trust Domain Extensions (TDX), section titled "TD attestation".
[Bagas Sanjaya fixed htmldocs warning] Reviewed-by: Bagas Sanjaya bagasdotme@gmail.com Signed-off-by: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppuswamy@linux.intel.com
Change since v12:
- None
Changes since v11:
- Fixed htmldocs warnings.
Documentation/x86/tdx.rst | 75 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+)
diff --git a/Documentation/x86/tdx.rst b/Documentation/x86/tdx.rst index b8fa4329e1a5..c9e3ecf86e0b 100644 --- a/Documentation/x86/tdx.rst +++ b/Documentation/x86/tdx.rst @@ -210,6 +210,81 @@ converted to shared on boot. For coherent DMA allocation, the DMA buffer gets converted on the allocation. Check force_dma_unencrypted() for details. +Attestation +===========
+Attestation is used to verify the TDX guest trustworthiness to other +entities before provisioning secrets to the guest. For example, a key +server may request for attestation before releasing the encryption keys +to mount the encrypted rootfs or secondary drive.
Maybe "may request attestation quote before ..."?
+TDX module records the state of the TDX guest in various stages of guest +boot process using build time measurement register (MRTD) and runtime +measurement registers (RTMR). Measurements related to guest initial +configuration and firmware image is recorded in the MRTD register. +Measurements related to initial state, kernel image, firmware image, +command line options, initrd, ACPI tables, etc are recorded in RTMR +registers. For more details, please refer to TDX Virtual Firmware design +specification, sec titled "TD Measurement".
+At TDX guest runtime, the Intel TDX module reuses the Intel SGX attestation +infrastructure to provide support for attesting to these measurements as +described below.
+The attestation process consists of two steps: TDREPORT generation and +Quote generation.
+TDX guest uses TDCALL[TDG.MR.REPORT] to get the TDREPORT (TDREPORT_STRUCT) +from the TDX module. TDREPORT is a fixed-size data structure generated by +the TDX module which contains guest-specific information (such as build +and boot measurements), platform security version, and the MAC to protect +the integrity of the TDREPORT.
+After getting the TDREPORT, the second step of the attestation process +is to send it to the QE to generate the Quote. TDREPORT by design can only
The first use of QE abbreviation is before it is defined. -EPARSE.
+be verified on local platform as the MAC key is bound to the platform. To +support remote verification of the TDREPORT, TDX leverages Intel SGX Quote +Enclave (QE) to verify the TDREPORT locally and convert it to a remote +verifiable Quote. Method of sending TDREPORT to QE is implemenentation +specific. Attestation software can choose whatever communication channel +available (i.e. vsock or hypercall) to send the TDREPORT to QE and receive +the Quote.
+To allow userspace attestation agent get the TDREPORT, TDX guest driver +exposes an IOCTL (TDX_CMD_GET_REPORT) interface via /dev/tdx-guest misc +device.
+TDX Guest driver +================
+The TDX guest driver exposes IOCTL interfaces via /dev/tdx-guest misc +device to allow user space to get certain TDX guest specific details +(like attestation report, attestation quote or storage keys, etc).
+In this section, for each supported IOCTL, following information is +provided along with generic description.
"for each" looks strange as we only have single IOCTL.
+:Input parameters: Parameters passed to the IOCTL and related details. +:Output: Details about output data and return value (with details
about the non common error values).+TDX_CMD_GET_REPORT +------------------
+:Input parameters: struct tdx_report_req +:Output: Upon successful execution, TDREPORT data is copied to
tdx_report_req.tdreport and returns 0 or returns-EIO on TDCALL failure and standard error number onother common failures.+The TDX_CMD_GET_REPORT IOCTL can be used by the attestation software to +get the TDX guest measurements data (with few other info) in the format +of TDREPORT_STRUCT. It uses TDCALL[TDG.MR.REPORT] to get the TDREPORT +from the TDX Module.
+Format of TDREPORT_STRUCT can be found in TDX 1.0 Module specification, +sec titled "TDREPORT_STRUCT".
After addressing the comments, the final version looks like below.
Attestation
===========
Attestation is used to verify the TDX guest trustworthiness to other
entities before provisioning secrets to the guest. For example, a key
server may request attestation quote before releasing the encryption
keys to mount the encrypted rootfs or secondary drive.
The TDX module records the state of the TDX guest in various stages of
the guest boot process using build time measurement register (MRTD) and
runtime measurement registers (RTMR). Measurements related to guest
initial configuration and firmware image are recorded in the MRTD
register. Measurements related to initial state, kernel image, firmware
image, command line options, initrd, ACPI tables, etc are recorded in
RTMR registers. For more details, please refer to TDX Virtual Firmware
design specification, sec titled "TD Measurement". At TDX guest runtime,
the attestation process is used to attest to these measurements.
The attestation process consists of two steps: TDREPORT generation and
Quote generation.
TDX guest uses TDCALL[TDG.MR.REPORT] to get the TDREPORT (TDREPORT_STRUCT)
from the TDX module. TDREPORT is a fixed-size data structure generated by
the TDX module which contains guest-specific information (such as build
and boot measurements), platform security version, and the MAC to protect
the integrity of the TDREPORT.
After getting the TDREPORT, the second step of the attestation process
is to send it to the Quoting Enclave (QE) to generate the Quote. TDREPORT
by design can only be verified on the local platform as the MAC key is
bound to the platform. To support remote verification of the TDREPORT,
TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT locally
and convert it to a remotely verifiable Quote. Method of sending TDREPORT
to QE is implementation specific. Attestation software can choose
whatever communication channel available (i.e. vsock or hypercall) to
send the TDREPORT to QE and receive the Quote.
TDX Guest driver
================
The TDX guest driver exposes IOCTL interfaces via /dev/tdx-guest device
to service TDX guest user-specific requests. But currently only
TDX_CMD_GET_RERPORT IOCTL is supported to allow user space attestation
agent to get the TDREPORT.
Following are the IOCTL ABI details:
TDX_CMD_GET_REPORT
------------------
:Input parameters: struct tdx_report_req
:Output: Upon successful execution, TDREPORT data is copied to
tdx_report_req.tdreport and return 0. Return -EIO on
TDCALL failure or standard error number on other common
failures.
The TDX_CMD_GET_REPORT IOCTL can be used by the attestation software to
get the TDREPORT from the TDX module using TDCALL[TDG.MR.REPORT].
On Tue, Sep 13, 2022 at 06:23:34PM -0700, Sathyanarayanan Kuppuswamy wrote:
After addressing the comments, the final version looks like below.
Looks okay to me. You can keep my Acked-by for the patchset.
On Tue, 2022-09-13 at 18:23 -0700, Sathyanarayanan Kuppuswamy wrote:
Attestation is used to verify the TDX guest trustworthiness to other
entities before provisioning secrets to the guest. For example, a key
server may request attestation quote before releasing the encryption
keys to mount the encrypted rootfs or secondary drive.
I would replace "may request attestation quote" to "may want to use attestation to verify the guest is the desired one". The "quote" was never mentioned before here so it's -EPARSE. Also getting the quote is not the purpose, the purpose is to get it verified by verification service.
The TDX module records the state of the TDX guest in various stages of
the guest boot process using build time measurement register (MRTD) and
runtime measurement registers (RTMR). Measurements related to guest
initial configuration and firmware image are recorded in the MRTD
register. Measurements related to initial state, kernel image, firmware
image, command line options, initrd, ACPI tables, etc are recorded in
RTMR registers. For more details, please refer to TDX Virtual Firmware
design specification, sec titled "TD Measurement". At TDX guest runtime,
the attestation process is used to attest to these measurements.
I would like to point out that "TDVF is is just an example". TDVF can be replaced with other BIOS, theoretically (especially if you consider container case in the future), so all things in TDVF can only just be an "example". I don't like the idea to bind TDX architecture with TDVF.
How about:
"For more details as an example, please refer to TDX virtual Firmware ...".
Otherwise looks good. You can have my Ack anyway:
Acked-by: Kai Huang kai.huang@intel.com
linux-kselftest-mirror@lists.linaro.org
-
Dave Hansen -
Greg Kroah-Hartman -
Huang, Kai -
Kirill A . Shutemov -
Kirill A. Shutemov -
Kuppuswamy Sathyanarayanan -
Sathyanarayanan Kuppuswamy