* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-22 23:34 ` [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver Kuppuswamy Sathyanarayanan
@ 2022-04-25 5:44 ` Kai Huang
2022-04-26 19:07 ` Sathyanarayanan Kuppuswamy
2022-04-27 4:05 ` Sathyanarayanan Kuppuswamy
2022-04-27 5:45 ` Isaku Yamahata
2022-04-28 17:45 ` Wander Lairson Costa
2 siblings, 2 replies; 28+ messages in thread
From: Kai Huang @ 2022-04-25 5:44 UTC (permalink / raw)
To: Kuppuswamy Sathyanarayanan, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86
Cc: H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
linux-kernel
On Fri, 2022-04-22 at 16:34 -0700, Kuppuswamy Sathyanarayanan wrote:
> In TDX guest, attestation is used to verify the trustworthiness of a TD
> to other entities before making any secure communication.
Before provisioning secrets to the TD.
>
> One usage example is, when a TD guest uses encrypted drive and the
> decryption keys required to access the drive are stored in a secure
> 3rd party keyserver, TD guest can use the quote generated via the
> attestation process to prove its trustworthiness with keyserver and
> get access to the storage keys.
"The key server can use attestation to verify TD's trustworthiness and release
the decryption keys to the TD".
It is the key server who starts the attestation request, but not the TD.
>
> General steps involved in attestation process are,
>
> 1. TD guest generates the TDREPORT that contains version information
> about the Intel TDX module, measurement of the TD, along with a
> TD-specified nonce.
> 2. TD guest shares the TDREPORT with TD host via GetQuote hypercall
> which is used by the host to generate a quote via quoting
> enclave (QE).
> 3. Quote generation completion notification is sent to TD OS via
> callback interrupt vector configured by TD using
> SetupEventNotifyInterrupt hypercall.
> 4. After receiving the generated TDQUOTE, a remote verifier can be
> used to verify the quote and confirm the trustworthiness of the
> TD.
Let's separate TDREPORT generation and Quote generation, and get rid of details
of how to get Quote part for now. Detail of GetQuote belongs to the patch which
implements it. Here I think we should focus on explaining why we need such a
basic driver to allow userspace to get the TDREPORT.
Below is for your reference:
"
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 to contain the TD-specific informatin (such as TD
measurements), platform information such as the security version of the platform
and the TDX module and the MAC to protect the integrity of the TDREPORT. TD
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.
TDREPORT can only be verified locally as the MAC key is bound to the platform.
TDX attestation leverages Intel SGX Quote Enclave (QE) to verify the TDREPORT
locally and convert it to a remote verifiable Quote to support remote
attestation of the TDREPORT. After getting the TDREPORT, the second step of
attestation process is to send the TDREPORT to QE to generate the Quote.
How is the QE, or Quote Generation Service (QGS) in general, implemented and
deployed is implementation specific. As a result, how to send the TDREPORT to
QE/QGS also depends on QE/QGS implementation and the deployment. TDX doesn't
support SGX inside a TD, so the QE/QGS can be deployed in the host, or inside a
dedicated legacy VM.
A typical implementation is TD userspace attestation software gets the TDREPORT
from TD kernel, sends it to QE/QGS, and QE/QGS returns the Quote. The data and
data format that TD userspace attestation software sends to the QE/QGS is also
implementation specific, but not necessarily just the raw TDREPORT. TD
attestation software can use any available communication channel to talk to
QE/QGS, such as using vsock and tcp/ip.
To support the case that those communication channels are not directly available
to the TD, TDX also defines TDVMCALLs to allow TD to use TDVMCALL to ask VMM to
help with sending the TDREPORT and receiving the Quote. This support is
documented in the GHCI spec "5.4 TD attestation".
Implement a basic attestation driver to allow TD userspace to get the TDREPORT
so the attestation software can send it to the QE to generate a Quote for remote
verification.
"
>
> More details on above mentioned steps can be found in TDX Guest-Host
> Communication Interface (GHCI) for Intel TDX 1.0, section titled
> "TD attestation".
>
> To allow the attestation agent (user application) to implement this
> feature, add an IOCTL interface to get TDREPORT and TDQUOTE from the
> user space. Since attestation agent can also use methods like vosck or
> TCP/IP to get the TDQUOTE, adding an IOCTL interface for it is an
> optional feature. So to simplify the driver, first add support for
> TDX_CMD_GET_TDREPORT IOCTL. Support for TDQUOTE IOCTL will be added by
> follow-on patches.
>
> TDREPORT can be generated by sending a TDCALL with leaf ID as 0x04.
> More details about the TDREPORT TDCALL can be found in Intel Trust
> Domain Extensions (Intel TDX) Module specification, section titled
> "TDG.MR.REPORT Leaf". Add a wrapper function (tdx_mcall_tdreport())
> to get the TDREPORT from the TDX Module. This API will be used by the
> interface driver to request for TDREPORT.
>
> 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.
>
> 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>
> ---
> arch/x86/coco/tdx/Makefile | 2 +-
> arch/x86/coco/tdx/attest.c | 191 ++++++++++++++++++++++++++++++++
> arch/x86/coco/tdx/tdx.c | 45 ++++++++
> arch/x86/include/asm/tdx.h | 2 +
> arch/x86/include/uapi/asm/tdx.h | 23 ++++
> 5 files changed, 262 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/coco/tdx/attest.c
> create mode 100644 arch/x86/include/uapi/asm/tdx.h
>
> diff --git a/arch/x86/coco/tdx/Makefile b/arch/x86/coco/tdx/Makefile
> index 46c55998557d..d2db3e6770e5 100644
> --- a/arch/x86/coco/tdx/Makefile
> +++ b/arch/x86/coco/tdx/Makefile
> @@ -1,3 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -obj-y += tdx.o tdcall.o
> +obj-y += tdx.o tdcall.o attest.o
> diff --git a/arch/x86/coco/tdx/attest.c b/arch/x86/coco/tdx/attest.c
> new file mode 100644
> index 000000000000..b776e81f6c20
> --- /dev/null
> +++ b/arch/x86/coco/tdx/attest.c
> @@ -0,0 +1,191 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * attest.c - TDX guest attestation interface driver.
> + *
> + * Implements user interface to trigger attestation process and
> + * read the TD Quote result.
Read TDREPORT. You can extend it in later patch if you want to call out
TDREPORT, Quote. But I don't think it's even necessary. Perhaps just say "TDX
attestation support" in general is enough.
> + *
> + * Copyright (C) 2022 Intel Corporation
> + *
> + */
> +
> +#define pr_fmt(fmt) "x86/tdx: attest: " fmt
> +
> +#include <linux/module.h>
> +#include <linux/miscdevice.h>
> +#include <linux/uaccess.h>
> +#include <linux/fs.h>
> +#include <linux/mm.h>
> +#include <linux/slab.h>
> +#include <linux/set_memory.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/platform_device.h>
> +#include <linux/jiffies.h>
> +#include <linux/io.h>
> +#include <asm/apic.h>
> +#include <asm/tdx.h>
> +#include <asm/irq_vectors.h>
> +#include <uapi/asm/tdx.h>
> +
> +#define DRIVER_NAME "tdx-attest"
> +
> +static struct platform_device *pdev;
> +static struct miscdevice miscdev;
> +
> +static long tdx_get_tdreport(void __user *argp)
> +{
> + void *report_buf = NULL, *tdreport_buf = NULL;
> + long ret = 0, err;
> +
> + /* Allocate space for report data */
> + report_buf = kmalloc(TDX_REPORT_DATA_LEN, GFP_KERNEL);
> + if (!report_buf)
> + return -ENOMEM;
> +
> + /*
> + * Allocate space for TDREPORT buffer (1024-byte aligned).
> + * Full page alignment is more than enough.
> + */
> + tdreport_buf = (void *)get_zeroed_page(GFP_KERNEL);
> + if (!tdreport_buf) {
> + ret = -ENOMEM;
> + goto tdreport_failed;
> + }
> +
> + /* Copy report data to kernel buffer */
> + if (copy_from_user(report_buf, argp, TDX_REPORT_DATA_LEN)) {
> + ret = -EFAULT;
> + goto tdreport_failed;
> + }
> +
> + /* Generate TDREPORT using report data in report_buf */
> + err = tdx_mcall_tdreport(tdreport_buf, report_buf);
> + if (err) {
> + /* If failed, pass TDCALL error code back to user */
> + ret = put_user(err, (long __user *)argp);
> + ret = -EIO;
> + goto tdreport_failed;
> + }
If you want support this, I guess it's better to explicitly use some data
structure so userspace software can be very clear about what does this IOCTL do:
struct tdx_get_tdreport {
union {
/* Input: REPORTDATA for TDCALL[TDG.MR.REPORT] */
__u8 reportdata[TDX_REPORT_DATA_LEN];
/* Output when TDCALL[TDG.MR.REPORT] fails */
__u64 tdcall_err;
} buf;
};
And you need to explain in the comment saying -EIO means TDCALL failed, and the
error code is returned to userspace.
But I am not sure whether this is necessary. The spec says TDG.MR.REPORT can
return: TDX_OPERAND_BUSY, TDX_OPERAND_INVALID, TDX_SUCCESS.
TDX_OPERAND_INVALID basically happens when buffer alignment doesn't meet, GPA is
wrong, etc, so this case is kernel bug. I don't see there's a need to expose it
to userspace as userspace won't be able to do anything anyway.
The BUSY case is (if I understand correctly, I took a look at the SEAM module
code) basically there's another thread updating the TDMR (registers for runtime
measurement update). Since it seems current kernel doesn't support
TDG.MR.RTMR.EXTEND, TDX_OPERAND_BUSY should not happen either. Even considering
the support of TDG.MR.RTMR.EXTEND in the future, I think kernel should use some
mutex to serialize it with TDG.MR.REPORT?
The bottom line is even we want to report BUSY to userspace, we choose to
return -EBUSY to indicate this case. So basically I don't see the value of
exposing TDCALL error to userspace.
> +
> + /* Copy TDREPORT data back to user buffer */
> + if (copy_to_user(argp, tdreport_buf, TDX_TDREPORT_LEN))
> + ret = -EFAULT;
> +
> +tdreport_failed:
> + kfree(report_buf);
> + if (tdreport_buf)
> + free_pages((unsigned long)tdreport_buf, 0);
> +
> + return ret;
> +}
> +
> +static long tdx_attest_ioctl(struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> + void __user *argp = (void __user *)arg;
> + long ret = 0;
> +
> + switch (cmd) {
> + case TDX_CMD_GET_TDREPORT:
> + ret = tdx_get_tdreport(argp);
> + break;
> + default:
> + pr_err("cmd %d not supported\n", cmd);
> + break;
Seems you are returning 0 in the default case.
> + }
> +
> + return ret;
> +}
> +
> +static const struct file_operations tdx_attest_fops = {
> + .owner = THIS_MODULE,
> + .unlocked_ioctl = tdx_attest_ioctl,
> + .llseek = no_llseek,
> +};
> +
> +static int tdx_attest_probe(struct platform_device *attest_pdev)
> +{
> + struct device *dev = &attest_pdev->dev;
> + long ret = 0;
> +
> + /* Only single device is allowed */
> + if (pdev)
> + return -EBUSY;
> +
> + pdev = attest_pdev;
> +
> + miscdev.name = DRIVER_NAME;
> + miscdev.minor = MISC_DYNAMIC_MINOR;
> + miscdev.fops = &tdx_attest_fops;
> + miscdev.parent = dev;
> +
> + ret = misc_register(&miscdev);
> + if (ret) {
> + pr_err("misc device registration failed\n");
> + goto failed;
> + }
> +
> + pr_debug("module initialization success\n");
> +
> + return 0;
> +
> +failed:
> + misc_deregister(&miscdev);
> +
> + pr_debug("module initialization failed\n");
> +
> + return ret;
> +}
> +
> +static int tdx_attest_remove(struct platform_device *attest_pdev)
> +{
> + misc_deregister(&miscdev);
> + pr_debug("module is successfully removed\n");
> + return 0;
> +}
> +
> +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);
Is there any particular reason to use platform driver and support it as a
module?
SGX driver uses misc_register() to register /dev/sgx_enclave during boot. Looks
it would be simpler.
> +
> +MODULE_AUTHOR("Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>");
> +MODULE_DESCRIPTION("TDX attestation driver");
> +MODULE_LICENSE("GPL");
> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
> index 03deb4d6920d..2a79ca92a52d 100644
> --- a/arch/x86/coco/tdx/tdx.c
> +++ b/arch/x86/coco/tdx/tdx.c
> @@ -11,10 +11,12 @@
> #include <asm/insn.h>
> #include <asm/insn-eval.h>
> #include <asm/pgtable.h>
> +#include <asm/io.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 */
> @@ -34,6 +36,10 @@
> #define VE_GET_PORT_NUM(e) ((e) >> 16)
> #define VE_IS_IO_STRING(e) ((e) & BIT(4))
>
> +/* TDX Module call error codes */
> +#define TDCALL_RETURN_CODE_MASK 0xffffffff00000000
> +#define TDCALL_RETURN_CODE(a) ((a) & TDCALL_RETURN_CODE_MASK)
> +
> /*
> * Wrapper for standard use of __tdx_hypercall with no output aside from
> * return code.
> @@ -98,6 +104,45 @@ static inline void tdx_module_call(u64 fn, u64 rcx, u64 rdx, u64 r8, u64 r9,
> panic("TDCALL %lld failed (Buggy TDX module!)\n", fn);
> }
>
> +/*
> + * tdx_mcall_tdreport() - Generate TDREPORT_STRUCT using TDCALL.
> + *
> + * @data : Address of 1024B aligned data to store
> + * TDREPORT_STRUCT.
> + * @reportdata : Address of 64B aligned report data
> + *
> + * return 0 on success or failure error number.
> + */
> +long tdx_mcall_tdreport(void *data, void *reportdata)
Change 'data' to be something more meaningful, i.e. tdreport?
> +{
> + u64 ret;
> +
> + /*
> + * Check for a valid TDX guest to ensure this API is only
> + * used by TDX guest platform. Also make sure "data" and
> + * "reportdata" pointers are valid.
> + */
> + if (!data || !reportdata || !cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
> + return -EINVAL;
Other TDCALL wrappers such as tdx_get_ve_info() doesn't have
X86_FEATURE_TDX_GUEST check. Why is it needed in this particular one?
> +
> + /*
> + * Pass the physical address of user generated report data
> + * and the physical address of output buffer to the TDX module
> + * to generate the TD report. Generated data contains
> + * measurements/configuration data of the TD guest. More info
> + * about ABI can be found in TDX 1.0 Module specification, sec
> + * titled "TDG.MR.REPORT".
> + */
> + ret = __tdx_module_call(TDX_GET_REPORT, virt_to_phys(data),
> + virt_to_phys(reportdata), 0, 0, NULL);
> +
> + if (ret)
> + return TDCALL_RETURN_CODE(ret);
If we don't expose TDCALL error to userspace, I don't think this is required?
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(tdx_mcall_tdreport);
If you use SGX similar way to use misc_register() at boot but don't support the
driver as module, then you don't have to export this symbol.
> +
> static u64 get_cc_mask(void)
> {
> struct tdx_module_output out;
> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
> index 020c81a7c729..a151f69dd6ef 100644
> --- a/arch/x86/include/asm/tdx.h
> +++ b/arch/x86/include/asm/tdx.h
> @@ -67,6 +67,8 @@ void tdx_safe_halt(void);
>
> bool tdx_early_handle_ve(struct pt_regs *regs);
>
> +long tdx_mcall_tdreport(void *data, void *reportdata);
> +
> #else
>
> static inline void tdx_early_init(void) { };
> diff --git a/arch/x86/include/uapi/asm/tdx.h b/arch/x86/include/uapi/asm/tdx.h
> new file mode 100644
> index 000000000000..c21f9d6fe88b
> --- /dev/null
> +++ b/arch/x86/include/uapi/asm/tdx.h
> @@ -0,0 +1,23 @@
> +/* 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>
> +
> +/* Input report data length for TDX_CMD_GET_TDREPORT IOCTL request */
> +#define TDX_REPORT_DATA_LEN 64
I'd change to TDX_REPORTDATA_LEN to make it consistent with spec.
REPORT_DATA can be vague.
> +
> +/* Output TD report data length after TDX_CMD_GET_TDREPORT IOCTL execution */
> +#define TDX_TDREPORT_LEN 1024
> +
> +/*
> + * TDX_CMD_GET_TDREPORT IOCTL is used to get TDREPORT data from the TDX
"TDREPORT data" -> "TDREPORT", or "TDREPORT_STRUCT".
> + * Module. Users should pass report data of size TDX_REPORT_DATA_LEN bytes
> + * via user input buffer of size TDX_TDREPORT_LEN. Once IOCTL is successful
> + * TDREPORT data is copied to the user buffer. On failure, TDCALL error
> + * code is copied back to the user buffer.
As I commented above, I am not convinced we need to copy TDCALL error code back
to userspace. If we want to do that, we need to explicitly tell on what error
code (-EIO, i.e.), the TDCALL error code is copied back.
> + */
> +#define TDX_CMD_GET_TDREPORT _IOWR('T', 0x01, __u64)
I personally think it's better to define a structure to represent the argument
used by this IOCTL:
struct tdx_get_tdreport {
__u8 reportdata[TDX_REPORTDATA_LEN];
};
You might add some padding for future expending too.
Then we can have a clearer comment explaining what the reportdata. Below is
just for your reference. You may come up with better words.
"User-defined 64-Byte REPORTDATA to be included into the TDREPORT. Typically it
can be some nonce provided by attestation software so the generated TDREPORT can
be uniquely verified."
> +
> +#endif /* _UAPI_ASM_X86_TDX_H */
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-25 5:44 ` Kai Huang
@ 2022-04-26 19:07 ` Sathyanarayanan Kuppuswamy
2022-04-27 5:15 ` Kai Huang
2022-04-27 4:05 ` Sathyanarayanan Kuppuswamy
1 sibling, 1 reply; 28+ messages in thread
From: Sathyanarayanan Kuppuswamy @ 2022-04-26 19:07 UTC (permalink / raw)
To: Kai Huang, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86
Cc: H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
linux-kernel
Hi Kai,
Thanks for the review.
On 4/24/22 10:44 PM, Kai Huang wrote:
> On Fri, 2022-04-22 at 16:34 -0700, Kuppuswamy Sathyanarayanan wrote:
>> In TDX guest, attestation is used to verify the trustworthiness of a TD
>> to other entities before making any secure communication.
>
> Before provisioning secrets to the TD.
Ok. Will change it.
>
>>
>> One usage example is, when a TD guest uses encrypted drive and the
>> decryption keys required to access the drive are stored in a secure
>> 3rd party keyserver, TD guest can use the quote generated via the
>> attestation process to prove its trustworthiness with keyserver and
>> get access to the storage keys.
>
> "The key server can use attestation to verify TD's trustworthiness and release
> the decryption keys to the TD".
>
> It is the key server who starts the attestation request, but not the TD.
>
>>
>> General steps involved in attestation process are,
>>
>> 1. TD guest generates the TDREPORT that contains version information
>> about the Intel TDX module, measurement of the TD, along with a
>> TD-specified nonce.
>> 2. TD guest shares the TDREPORT with TD host via GetQuote hypercall
>> which is used by the host to generate a quote via quoting
>> enclave (QE).
>> 3. Quote generation completion notification is sent to TD OS via
>> callback interrupt vector configured by TD using
>> SetupEventNotifyInterrupt hypercall.
>> 4. After receiving the generated TDQUOTE, a remote verifier can be
>> used to verify the quote and confirm the trustworthiness of the
>> TD.
>
> Let's separate TDREPORT generation and Quote generation, and get rid of details
> of how to get Quote part for now. Detail of GetQuote belongs to the patch which
> implements it. Here I think we should focus on explaining why we need such a
> basic driver to allow userspace to get the TDREPORT.
>
> Below is for your reference:
>
> "
> 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 to contain the TD-specific informatin (such as TD
> measurements), platform information such as the security version of the platform
> and the TDX module and the MAC to protect the integrity of the TDREPORT. TD
> 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.
>
> TDREPORT can only be verified locally as the MAC key is bound to the platform.
> TDX attestation leverages Intel SGX Quote Enclave (QE) to verify the TDREPORT
> locally and convert it to a remote verifiable Quote to support remote
> attestation of the TDREPORT. After getting the TDREPORT, the second step of
> attestation process is to send the TDREPORT to QE to generate the Quote.
>
> How is the QE, or Quote Generation Service (QGS) in general, implemented and
> deployed is implementation specific. As a result, how to send the TDREPORT to
> QE/QGS also depends on QE/QGS implementation and the deployment. TDX doesn't
> support SGX inside a TD, so the QE/QGS can be deployed in the host, or inside a
> dedicated legacy VM.
>
> A typical implementation is TD userspace attestation software gets the TDREPORT
> from TD kernel, sends it to QE/QGS, and QE/QGS returns the Quote. The data and
> data format that TD userspace attestation software sends to the QE/QGS is also
> implementation specific, but not necessarily just the raw TDREPORT. TD
> attestation software can use any available communication channel to talk to
> QE/QGS, such as using vsock and tcp/ip.
>
> To support the case that those communication channels are not directly available
> to the TD, TDX also defines TDVMCALLs to allow TD to use TDVMCALL to ask VMM to
> help with sending the TDREPORT and receiving the Quote. This support is
> documented in the GHCI spec "5.4 TD attestation".
>
> Implement a basic attestation driver to allow TD userspace to get the TDREPORT
> so the attestation software can send it to the QE to generate a Quote for remote
> verification.
> "
>
Thanks. I will use it with some addition about the driver mentioned
below.
>
>>
>> More details on above mentioned steps can be found in TDX Guest-Host
>> Communication Interface (GHCI) for Intel TDX 1.0, section titled
>> "TD attestation".
>>
>> To allow the attestation agent (user application) to implement this
>> feature, add an IOCTL interface to get TDREPORT and TDQUOTE from the
>> user space. Since attestation agent can also use methods like vosck or
>> TCP/IP to get the TDQUOTE, adding an IOCTL interface for it is an
>> optional feature. So to simplify the driver, first add support for
>> TDX_CMD_GET_TDREPORT IOCTL. Support for TDQUOTE IOCTL will be added by
>> follow-on patches.
>>
>> TDREPORT can be generated by sending a TDCALL with leaf ID as 0x04.
>> More details about the TDREPORT TDCALL can be found in Intel Trust
>> Domain Extensions (Intel TDX) Module specification, section titled
>> "TDG.MR.REPORT Leaf". Add a wrapper function (tdx_mcall_tdreport())
>> to get the TDREPORT from the TDX Module. This API will be used by the
>> interface driver to request for TDREPORT.
>>
>> 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.
>>
>> 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>
>> ---
>> arch/x86/coco/tdx/Makefile | 2 +-
>> arch/x86/coco/tdx/attest.c | 191 ++++++++++++++++++++++++++++++++
>> arch/x86/coco/tdx/tdx.c | 45 ++++++++
>> arch/x86/include/asm/tdx.h | 2 +
>> arch/x86/include/uapi/asm/tdx.h | 23 ++++
>> 5 files changed, 262 insertions(+), 1 deletion(-)
>> create mode 100644 arch/x86/coco/tdx/attest.c
>> create mode 100644 arch/x86/include/uapi/asm/tdx.h
>>
>> diff --git a/arch/x86/coco/tdx/Makefile b/arch/x86/coco/tdx/Makefile
>> index 46c55998557d..d2db3e6770e5 100644
>> --- a/arch/x86/coco/tdx/Makefile
>> +++ b/arch/x86/coco/tdx/Makefile
>> @@ -1,3 +1,3 @@
>> # SPDX-License-Identifier: GPL-2.0
>>
>> -obj-y += tdx.o tdcall.o
>> +obj-y += tdx.o tdcall.o attest.o
>> diff --git a/arch/x86/coco/tdx/attest.c b/arch/x86/coco/tdx/attest.c
>> new file mode 100644
>> index 000000000000..b776e81f6c20
>> --- /dev/null
>> +++ b/arch/x86/coco/tdx/attest.c
>> @@ -0,0 +1,191 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * attest.c - TDX guest attestation interface driver.
>> + *
>> + * Implements user interface to trigger attestation process and
>> + * read the TD Quote result.
>
> Read TDREPORT. You can extend it in later patch if you want to call out
> TDREPORT, Quote. But I don't think it's even necessary. Perhaps just say "TDX
> attestation support" in general is enough.
Ok. I will fix it.
>
>> + *
>> + * Copyright (C) 2022 Intel Corporation
>> + *
>> + */
>> +
>> +#define pr_fmt(fmt) "x86/tdx: attest: " fmt
>> +
>> +#include <linux/module.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/uaccess.h>
>> +#include <linux/fs.h>
>> +#include <linux/mm.h>
>> +#include <linux/slab.h>
>> +#include <linux/set_memory.h>
>> +#include <linux/dma-mapping.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/io.h>
>> +#include <asm/apic.h>
>> +#include <asm/tdx.h>
>> +#include <asm/irq_vectors.h>
>> +#include <uapi/asm/tdx.h>
>> +
>> +#define DRIVER_NAME "tdx-attest"
>> +
>> +static struct platform_device *pdev;
>> +static struct miscdevice miscdev;
>> +
>> +static long tdx_get_tdreport(void __user *argp)
>> +{
>> + void *report_buf = NULL, *tdreport_buf = NULL;
>> + long ret = 0, err;
>> +
>> + /* Allocate space for report data */
>> + report_buf = kmalloc(TDX_REPORT_DATA_LEN, GFP_KERNEL);
>> + if (!report_buf)
>> + return -ENOMEM;
>> +
>> + /*
>> + * Allocate space for TDREPORT buffer (1024-byte aligned).
>> + * Full page alignment is more than enough.
>> + */
>> + tdreport_buf = (void *)get_zeroed_page(GFP_KERNEL);
>> + if (!tdreport_buf) {
>> + ret = -ENOMEM;
>> + goto tdreport_failed;
>> + }
>> +
>> + /* Copy report data to kernel buffer */
>> + if (copy_from_user(report_buf, argp, TDX_REPORT_DATA_LEN)) {
>> + ret = -EFAULT;
>> + goto tdreport_failed;
>> + }
>> +
>> + /* Generate TDREPORT using report data in report_buf */
>> + err = tdx_mcall_tdreport(tdreport_buf, report_buf);
>> + if (err) {
>> + /* If failed, pass TDCALL error code back to user */
>> + ret = put_user(err, (long __user *)argp);
>> + ret = -EIO;
>> + goto tdreport_failed;
>> + }
>
> If you want support this, I guess it's better to explicitly use some data
> structure so userspace software can be very clear about what does this IOCTL do:
>
> struct tdx_get_tdreport {
> union {
> /* Input: REPORTDATA for TDCALL[TDG.MR.REPORT] */
> __u8 reportdata[TDX_REPORT_DATA_LEN];
> /* Output when TDCALL[TDG.MR.REPORT] fails */
> __u64 tdcall_err;
> } buf;
> };
>
> And you need to explain in the comment saying -EIO means TDCALL failed, and the
> error code is returned to userspace.
>
> But I am not sure whether this is necessary. The spec says TDG.MR.REPORT can
> return: TDX_OPERAND_BUSY, TDX_OPERAND_INVALID, TDX_SUCCESS.
>
> TDX_OPERAND_INVALID basically happens when buffer alignment doesn't meet, GPA is
> wrong, etc, so this case is kernel bug. I don't see there's a need to expose it
> to userspace as userspace won't be able to do anything anyway.
>
> The BUSY case is (if I understand correctly, I took a look at the SEAM module
> code) basically there's another thread updating the TDMR (registers for runtime
> measurement update). Since it seems current kernel doesn't support
> TDG.MR.RTMR.EXTEND, TDX_OPERAND_BUSY should not happen either. Even considering
> the support of TDG.MR.RTMR.EXTEND in the future, I think kernel should use some
> mutex to serialize it with TDG.MR.REPORT?
Ok. I will keep this in mind when adding RTMR support in future.
>
> The bottom line is even we want to report BUSY to userspace, we choose to
> return -EBUSY to indicate this case. So basically I don't see the value of
> exposing TDCALL error to userspace.
I have mainly added it to get more debug info about the failure in user
app. But I agree with your point that this not necessary. I will remove
this in next version.
>
>
>> +
>> + /* Copy TDREPORT data back to user buffer */
>> + if (copy_to_user(argp, tdreport_buf, TDX_TDREPORT_LEN))
>> + ret = -EFAULT;
>> +
>> +tdreport_failed:
>> + kfree(report_buf);
>> + if (tdreport_buf)
>> + free_pages((unsigned long)tdreport_buf, 0);
>> +
>> + return ret;
>> +}
>> +
>> +static long tdx_attest_ioctl(struct file *file, unsigned int cmd,
>> + unsigned long arg)
>> +{
>> + void __user *argp = (void __user *)arg;
>> + long ret = 0;
>> +
>> + switch (cmd) {
>> + case TDX_CMD_GET_TDREPORT:
>> + ret = tdx_get_tdreport(argp);
>> + break;
>> + default:
>> + pr_err("cmd %d not supported\n", cmd);
>> + break;
>
> Seems you are returning 0 in the default case.
Good catch. I will fix it in next version.
>
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static const struct file_operations tdx_attest_fops = {
>> + .owner = THIS_MODULE,
>> + .unlocked_ioctl = tdx_attest_ioctl,
>> + .llseek = no_llseek,
>> +};
>> +
>> +static int tdx_attest_probe(struct platform_device *attest_pdev)
>> +{
>> + struct device *dev = &attest_pdev->dev;
>> + long ret = 0;
>> +
>> + /* Only single device is allowed */
>> + if (pdev)
>> + return -EBUSY;
>> +
>> + pdev = attest_pdev;
>> +
>> + miscdev.name = DRIVER_NAME;
>> + miscdev.minor = MISC_DYNAMIC_MINOR;
>> + miscdev.fops = &tdx_attest_fops;
>> + miscdev.parent = dev;
>> +
>> + ret = misc_register(&miscdev);
>> + if (ret) {
>> + pr_err("misc device registration failed\n");
>> + goto failed;
>> + }
>> +
>> + pr_debug("module initialization success\n");
>> +
>> + return 0;
>> +
>> +failed:
>> + misc_deregister(&miscdev);
>> +
>> + pr_debug("module initialization failed\n");
>> +
>> + return ret;
>> +}
>> +
>> +static int tdx_attest_remove(struct platform_device *attest_pdev)
>> +{
>> + misc_deregister(&miscdev);
>> + pr_debug("module is successfully removed\n");
>> + return 0;
>> +}
>> +
>> +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);
>
> Is there any particular reason to use platform driver and support it as a
> module?
>
> SGX driver uses misc_register() to register /dev/sgx_enclave during boot. Looks
> it would be simpler.
Main reason is to use a proper device in dma_alloc* APIs.
My initial version only used misc device as you have mentioned. But
Hans raised a concern about using proper struct device in dma_alloc*
APIs and suggested modifying the driver to use platform device
model. You can find relevant discussion here.
https://lore.kernel.org/all/47d06f45-c1b5-2c8f-d937-3abacbf10321@redhat.com/
>
>> +
>> +MODULE_AUTHOR("Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>");
>> +MODULE_DESCRIPTION("TDX attestation driver");
>> +MODULE_LICENSE("GPL");
>> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
>> index 03deb4d6920d..2a79ca92a52d 100644
>> --- a/arch/x86/coco/tdx/tdx.c
>> +++ b/arch/x86/coco/tdx/tdx.c
>> @@ -11,10 +11,12 @@
>> #include <asm/insn.h>
>> #include <asm/insn-eval.h>
>> #include <asm/pgtable.h>
>> +#include <asm/io.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 */
>> @@ -34,6 +36,10 @@
>> #define VE_GET_PORT_NUM(e) ((e) >> 16)
>> #define VE_IS_IO_STRING(e) ((e) & BIT(4))
>>
>> +/* TDX Module call error codes */
>> +#define TDCALL_RETURN_CODE_MASK 0xffffffff00000000
>> +#define TDCALL_RETURN_CODE(a) ((a) & TDCALL_RETURN_CODE_MASK)
>> +
>> /*
>> * Wrapper for standard use of __tdx_hypercall with no output aside from
>> * return code.
>> @@ -98,6 +104,45 @@ static inline void tdx_module_call(u64 fn, u64 rcx, u64 rdx, u64 r8, u64 r9,
>> panic("TDCALL %lld failed (Buggy TDX module!)\n", fn);
>> }
>>
>> +/*
>> + * tdx_mcall_tdreport() - Generate TDREPORT_STRUCT using TDCALL.
>> + *
>> + * @data : Address of 1024B aligned data to store
>> + * TDREPORT_STRUCT.
>> + * @reportdata : Address of 64B aligned report data
>> + *
>> + * return 0 on success or failure error number.
>> + */
>> +long tdx_mcall_tdreport(void *data, void *reportdata)
>
> Change 'data' to be something more meaningful, i.e. tdreport?
Ok. I will change it.
>
>> +{
>> + u64 ret;
>> +
>> + /*
>> + * Check for a valid TDX guest to ensure this API is only
>> + * used by TDX guest platform. Also make sure "data" and
>> + * "reportdata" pointers are valid.
>> + */
>> + if (!data || !reportdata || !cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
>> + return -EINVAL;
>
> Other TDCALL wrappers such as tdx_get_ve_info() doesn't have
> X86_FEATURE_TDX_GUEST check. Why is it needed in this particular one?
Previously the attestation driver can be compiled as a module so I have
exported this function. But I was not sure whether this function will be
called *only* from the attestation driver. So to protect against any
incorrect usage, I have added check for valid TDX guest with in this
function.
But I think this is no longer required. I will remove it in the next
version.
>
>> +
>> + /*
>> + * Pass the physical address of user generated report data
>> + * and the physical address of output buffer to the TDX module
>> + * to generate the TD report. Generated data contains
>> + * measurements/configuration data of the TD guest. More info
>> + * about ABI can be found in TDX 1.0 Module specification, sec
>> + * titled "TDG.MR.REPORT".
>> + */
>> + ret = __tdx_module_call(TDX_GET_REPORT, virt_to_phys(data),
>> + virt_to_phys(reportdata), 0, 0, NULL);
>> +
>> + if (ret)
>> + return TDCALL_RETURN_CODE(ret);
>
> If we don't expose TDCALL error to userspace, I don't think this is required?
>
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(tdx_mcall_tdreport);
>
> If you use SGX similar way to use misc_register() at boot but don't support the
> driver as module, then you don't have to export this symbol.
Now that we don't have separate config for attestation, module
compilation is not possible. I will remove it.
>
>> +
>> static u64 get_cc_mask(void)
>> {
>> struct tdx_module_output out;
>> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
>> index 020c81a7c729..a151f69dd6ef 100644
>> --- a/arch/x86/include/asm/tdx.h
>> +++ b/arch/x86/include/asm/tdx.h
>> @@ -67,6 +67,8 @@ void tdx_safe_halt(void);
>>
>> bool tdx_early_handle_ve(struct pt_regs *regs);
>>
>> +long tdx_mcall_tdreport(void *data, void *reportdata);
>> +
>> #else
>>
>> static inline void tdx_early_init(void) { };
>> diff --git a/arch/x86/include/uapi/asm/tdx.h b/arch/x86/include/uapi/asm/tdx.h
>> new file mode 100644
>> index 000000000000..c21f9d6fe88b
>> --- /dev/null
>> +++ b/arch/x86/include/uapi/asm/tdx.h
>> @@ -0,0 +1,23 @@
>> +/* 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>
>> +
>> +/* Input report data length for TDX_CMD_GET_TDREPORT IOCTL request */
>> +#define TDX_REPORT_DATA_LEN 64
>
> I'd change to TDX_REPORTDATA_LEN to make it consistent with spec.
>
> REPORT_DATA can be vague.
Ok.
>
>> +
>> +/* Output TD report data length after TDX_CMD_GET_TDREPORT IOCTL execution */
>> +#define TDX_TDREPORT_LEN 1024
>> +
>> +/*
>> + * TDX_CMD_GET_TDREPORT IOCTL is used to get TDREPORT data from the TDX
>
> "TDREPORT data" -> "TDREPORT", or "TDREPORT_STRUCT".
Ok. I will make it consistent.
>
>> + * Module. Users should pass report data of size TDX_REPORT_DATA_LEN bytes
>> + * via user input buffer of size TDX_TDREPORT_LEN. Once IOCTL is successful
>> + * TDREPORT data is copied to the user buffer. On failure, TDCALL error
>> + * code is copied back to the user buffer.
>
> As I commented above, I am not convinced we need to copy TDCALL error code back
> to userspace. If we want to do that, we need to explicitly tell on what error
> code (-EIO, i.e.), the TDCALL error code is copied back.
>
I will remove the error code return support.
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-26 19:07 ` Sathyanarayanan Kuppuswamy
@ 2022-04-27 5:15 ` Kai Huang
2022-04-27 21:45 ` Sathyanarayanan Kuppuswamy
0 siblings, 1 reply; 28+ messages in thread
From: Kai Huang @ 2022-04-27 5:15 UTC (permalink / raw)
To: Sathyanarayanan Kuppuswamy, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86
Cc: H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
linux-kernel
On Tue, 2022-04-26 at 12:07 -0700, Sathyanarayanan Kuppuswamy wrote:
> > Is there any particular reason to use platform driver and support it as a
> > module?
> >
> > SGX driver uses misc_register() to register /dev/sgx_enclave during boot.
> > Looks
> > it would be simpler.
>
> Main reason is to use a proper device in dma_alloc* APIs.
>
> My initial version only used misc device as you have mentioned. But
> Hans raised a concern about using proper struct device in dma_alloc*
> APIs and suggested modifying the driver to use platform device
> model. You can find relevant discussion here.
>
> https://lore.kernel.org/all/47d06f45-c1b5-2c8f-d937-3abacbf10321@redhat.com/
Thanks for the info. Sorry I didn't dig review comments for previous version.
However, after digging more, I am wondering why do you need to use DMA API at
the first place.
Firstly, for this basic driver to report TDREPORT to userspace, there's no need
to use any DMA API, nor we need to use shared memory, as we just get the report
into some buffer (doesn't need to be shared) and copy the report back to
userspace. So it doesn't make a lot sense to use platform device here.
Secondly, in terms of GetQuote support, it seems Dave/Andi suggested you can use
vmalloc()/vmap() and just use set_memory_decrypted() to convert it to shared:
https://lore.kernel.org/all/ce0feeec-a949-35f8-3010-b0d69acbbc2e@linux.intel.com/
I don't see why it cannot work? Then wouldn't this approach be simpler than
using DMA API? Any reason to choose platform device?
Btw, a side topic:
Andy suggested we don't do memory allocation and private-shared conversion at
IOCTL time as the conversion is expensive:
https://lore.kernel.org/all/06c85c19-e16c-3121-ed47-075cfa779b67@kernel.org/
This is reasonable (and sorry I didn't see this when I commented in v3).
To avoid IOCTL time private-shared conversion, and yet support dynamic Quote
length, can we do following:
- Allocate a *default* size buffer at driver loading time (i.e. 4 pages), and
convert to shared. This default size should cover 99% cases as Intel QGS
currently generates Quote smaller than 8K, and Intel attestation agent hard-code
a 4 pages buffer for Quote.
- In GetQuote IOCTL, when the len is larger than default size, we discard the
original one and allocate a larger buffer.
How does this sound?
--
Thanks,
-Kai
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-27 5:15 ` Kai Huang
@ 2022-04-27 21:45 ` Sathyanarayanan Kuppuswamy
2022-04-27 23:40 ` Kai Huang
0 siblings, 1 reply; 28+ messages in thread
From: Sathyanarayanan Kuppuswamy @ 2022-04-27 21:45 UTC (permalink / raw)
To: Kai Huang, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86
Cc: H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
linux-kernel
Hi,
On 4/26/22 10:15 PM, Kai Huang wrote:
> On Tue, 2022-04-26 at 12:07 -0700, Sathyanarayanan Kuppuswamy wrote:
>>> Is there any particular reason to use platform driver and support it as a
>>> module?
>>>
>>> SGX driver uses misc_register() to register /dev/sgx_enclave during boot.
>>> Looks
>>> it would be simpler.
>>
>> Main reason is to use a proper device in dma_alloc* APIs.
>>
>> My initial version only used misc device as you have mentioned. But
>> Hans raised a concern about using proper struct device in dma_alloc*
>> APIs and suggested modifying the driver to use platform device
>> model. You can find relevant discussion here.
>>
>> https://lore.kernel.org/all/47d06f45-c1b5-2c8f-d937-3abacbf10321@redhat.com/
>
> Thanks for the info. Sorry I didn't dig review comments for previous version.
>
> However, after digging more, I am wondering why do you need to use DMA API at
> the first place.
>
> Firstly, for this basic driver to report TDREPORT to userspace, there's no need
> to use any DMA API, nor we need to use shared memory, as we just get the report
> into some buffer (doesn't need to be shared) and copy the report back to
> userspace. So it doesn't make a lot sense to use platform device here.
Yes. For this patch itself, since we don't need to use DMA API,
platform driver model is not required. But I have made this patch use
platform driver format in consideration of its need in the next patch.
Making it misc driver in this patch and changing it to platform driver
in next patch does not make sense. Since they are all in the same patch
set we can add some changes in consideration of the next patch.
>
> Secondly, in terms of GetQuote support, it seems Dave/Andi suggested you can use
> vmalloc()/vmap() and just use set_memory_decrypted() to convert it to shared:
>
> https://lore.kernel.org/all/ce0feeec-a949-35f8-3010-b0d69acbbc2e@linux.intel.com/
>
> I don't see why it cannot work? Then wouldn't this approach be simpler than
> using DMA API? Any reason to choose platform device?
Yes, it will work. But I am not sure whether it is simpler than adding
platform driver specific buffer code. I have used DMA APIs because it
will handle allocation and decryption setting internally. I thought is
simpler than we handling it ourselves.
But if platform device driver model is not preferred, I can change it.
>
> Btw, a side topic:
>
> Andy suggested we don't do memory allocation and private-shared conversion at
> IOCTL time as the conversion is expensive:
>
> https://lore.kernel.org/all/06c85c19-e16c-3121-ed47-075cfa779b67@kernel.org/
>
> This is reasonable (and sorry I didn't see this when I commented in v3).
>
> To avoid IOCTL time private-shared conversion, and yet support dynamic Quote
> length, can we do following:
>
> - Allocate a *default* size buffer at driver loading time (i.e. 4 pages), and
> convert to shared. This default size should cover 99% cases as Intel QGS
> currently generates Quote smaller than 8K, and Intel attestation agent hard-code
> a 4 pages buffer for Quote.
>
> - In GetQuote IOCTL, when the len is larger than default size, we discard the
> original one and allocate a larger buffer.
>
> How does this sound?
It sounds fine. Your suggestion can indeed decrease the IOCTL time.
But, IMO, since attestation will not be used that frequently,
we don't need to consider optimization at this point of time. Also, I
think the memory allocation time is negligible compared to time it takes
for the TDQUOTE generation.
Even if we have to do it, we can add it in future as a separate
patch. We don't need to add it part of this basic driver support
patch.
>
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-27 21:45 ` Sathyanarayanan Kuppuswamy
@ 2022-04-27 23:40 ` Kai Huang
2022-04-28 0:40 ` Sathyanarayanan Kuppuswamy
0 siblings, 1 reply; 28+ messages in thread
From: Kai Huang @ 2022-04-27 23:40 UTC (permalink / raw)
To: Sathyanarayanan Kuppuswamy, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86
Cc: H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
linux-kernel
On Wed, 2022-04-27 at 14:45 -0700, Sathyanarayanan Kuppuswamy wrote:
> Hi,
>
> On 4/26/22 10:15 PM, Kai Huang wrote:
> > On Tue, 2022-04-26 at 12:07 -0700, Sathyanarayanan Kuppuswamy wrote:
> > > > Is there any particular reason to use platform driver and support it as a
> > > > module?
> > > >
> > > > SGX driver uses misc_register() to register /dev/sgx_enclave during boot.
> > > > Looks
> > > > it would be simpler.
> > >
> > > Main reason is to use a proper device in dma_alloc* APIs.
> > >
> > > My initial version only used misc device as you have mentioned. But
> > > Hans raised a concern about using proper struct device in dma_alloc*
> > > APIs and suggested modifying the driver to use platform device
> > > model. You can find relevant discussion here.
> > >
> > > https://lore.kernel.org/all/47d06f45-c1b5-2c8f-d937-3abacbf10321@redhat.com/
> >
> > Thanks for the info. Sorry I didn't dig review comments for previous version.
> >
> > However, after digging more, I am wondering why do you need to use DMA API at
> > the first place.
> >
> > Firstly, for this basic driver to report TDREPORT to userspace, there's no need
> > to use any DMA API, nor we need to use shared memory, as we just get the report
> > into some buffer (doesn't need to be shared) and copy the report back to
> > userspace. So it doesn't make a lot sense to use platform device here.
>
> Yes. For this patch itself, since we don't need to use DMA API,
> platform driver model is not required. But I have made this patch use
> platform driver format in consideration of its need in the next patch.
> Making it misc driver in this patch and changing it to platform driver
> in next patch does not make sense. Since they are all in the same patch
> set we can add some changes in consideration of the next patch.
>
> >
> > Secondly, in terms of GetQuote support, it seems Dave/Andi suggested you can use
> > vmalloc()/vmap() and just use set_memory_decrypted() to convert it to shared:
> >
> > https://lore.kernel.org/all/ce0feeec-a949-35f8-3010-b0d69acbbc2e@linux.intel.com/
> >
> > I don't see why it cannot work? Then wouldn't this approach be simpler than
> > using DMA API? Any reason to choose platform device?
>
> Yes, it will work. But I am not sure whether it is simpler than adding
> platform driver specific buffer code. I have used DMA APIs because it
> will handle allocation and decryption setting internally. I thought is
> simpler than we handling it ourselves.
>
> But if platform device driver model is not preferred, I can change it.
I don't think ignoring Dave/Andi's comments w/o providing feedback is good.
Also I personally don't see how using DMA API is better than using
vmalloc()/vmap(). In order to use DMA API, you have to add more code to use
platform_device, which isn't necessary.
I'll leave this to Dave/Andi.
>
>
> >
> > Btw, a side topic:
> >
> > Andy suggested we don't do memory allocation and private-shared conversion at
> > IOCTL time as the conversion is expensive:
> >
> > https://lore.kernel.org/all/06c85c19-e16c-3121-ed47-075cfa779b67@kernel.org/
> >
> > This is reasonable (and sorry I didn't see this when I commented in v3).
> >
> > To avoid IOCTL time private-shared conversion, and yet support dynamic Quote
> > length, can we do following:
> >
> > - Allocate a *default* size buffer at driver loading time (i.e. 4 pages), and
> > convert to shared. This default size should cover 99% cases as Intel QGS
> > currently generates Quote smaller than 8K, and Intel attestation agent hard-code
> > a 4 pages buffer for Quote.
> >
> > - In GetQuote IOCTL, when the len is larger than default size, we discard the
> > original one and allocate a larger buffer.
> >
> > How does this sound?
>
> It sounds fine. Your suggestion can indeed decrease the IOCTL time.
>
> But, IMO, since attestation will not be used that frequently,
> we don't need to consider optimization at this point of time. Also, I
> think the memory allocation time is negligible compared to time it takes
> for the TDQUOTE generation.
>
> Even if we have to do it, we can add it in future as a separate
> patch. We don't need to add it part of this basic driver support
> patch.
>
>
I am just pointing out Andy made such suggestion before, and it's not something
we cannot support.
Anyway will let you decide.
--
Thanks,
-Kai
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-27 23:40 ` Kai Huang
@ 2022-04-28 0:40 ` Sathyanarayanan Kuppuswamy
0 siblings, 0 replies; 28+ messages in thread
From: Sathyanarayanan Kuppuswamy @ 2022-04-28 0:40 UTC (permalink / raw)
To: Kai Huang, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86
Cc: H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
linux-kernel
Hi Kai,
On 4/27/22 4:40 PM, Kai Huang wrote:
> On Wed, 2022-04-27 at 14:45 -0700, Sathyanarayanan Kuppuswamy wrote:
>> Hi,
>>
>> On 4/26/22 10:15 PM, Kai Huang wrote:
>>> On Tue, 2022-04-26 at 12:07 -0700, Sathyanarayanan Kuppuswamy wrote:
>>>>> Is there any particular reason to use platform driver and support it as a
>>>>> module?
>>>>>
>>>>> SGX driver uses misc_register() to register /dev/sgx_enclave during boot.
>>>>> Looks
>>>>> it would be simpler.
>>>>
>>>> Main reason is to use a proper device in dma_alloc* APIs.
>>>>
>>>> My initial version only used misc device as you have mentioned. But
>>>> Hans raised a concern about using proper struct device in dma_alloc*
>>>> APIs and suggested modifying the driver to use platform device
>>>> model. You can find relevant discussion here.
>>>>
>>>> https://lore.kernel.org/all/47d06f45-c1b5-2c8f-d937-3abacbf10321@redhat.com/
>>>
>>> Thanks for the info. Sorry I didn't dig review comments for previous version.
>>>
>>> However, after digging more, I am wondering why do you need to use DMA API at
>>> the first place.
>>>
>>> Firstly, for this basic driver to report TDREPORT to userspace, there's no need
>>> to use any DMA API, nor we need to use shared memory, as we just get the report
>>> into some buffer (doesn't need to be shared) and copy the report back to
>>> userspace. So it doesn't make a lot sense to use platform device here.
>>
>> Yes. For this patch itself, since we don't need to use DMA API,
>> platform driver model is not required. But I have made this patch use
>> platform driver format in consideration of its need in the next patch.
>> Making it misc driver in this patch and changing it to platform driver
>> in next patch does not make sense. Since they are all in the same patch
>> set we can add some changes in consideration of the next patch.
>>
>>>
>>> Secondly, in terms of GetQuote support, it seems Dave/Andi suggested you can use
>>> vmalloc()/vmap() and just use set_memory_decrypted() to convert it to shared:
>>>
>>> https://lore.kernel.org/all/ce0feeec-a949-35f8-3010-b0d69acbbc2e@linux.intel.com/
>>>
>>> I don't see why it cannot work? Then wouldn't this approach be simpler than
>>> using DMA API? Any reason to choose platform device?
>>
>> Yes, it will work. But I am not sure whether it is simpler than adding
>> platform driver specific buffer code. I have used DMA APIs because it
>> will handle allocation and decryption setting internally. I thought is
>> simpler than we handling it ourselves.
>>
>> But if platform device driver model is not preferred, I can change it.
>
> I don't think ignoring Dave/Andi's comments w/o providing feedback is good.
It is not intentional. I think it is missed during my vacation due to
some mail access issues. Sorry about it.
>
> Also I personally don't see how using DMA API is better than using
> vmalloc()/vmap(). In order to use DMA API, you have to add more code to use
> platform_device, which isn't necessary.
>
> I'll leave this to Dave/Andi.
As I said, I am fine with the change (if it is preferred).
>
>>
>>
>>>
>>> Btw, a side topic:
>>>
>>> Andy suggested we don't do memory allocation and private-shared conversion at
>>> IOCTL time as the conversion is expensive:
>>>
>>> https://lore.kernel.org/all/06c85c19-e16c-3121-ed47-075cfa779b67@kernel.org/
>>>
>>> This is reasonable (and sorry I didn't see this when I commented in v3).
>>>
>>> To avoid IOCTL time private-shared conversion, and yet support dynamic Quote
>>> length, can we do following:
>>>
>>> - Allocate a *default* size buffer at driver loading time (i.e. 4 pages), and
>>> convert to shared. This default size should cover 99% cases as Intel QGS
>>> currently generates Quote smaller than 8K, and Intel attestation agent hard-code
>>> a 4 pages buffer for Quote.
>>>
>>> - In GetQuote IOCTL, when the len is larger than default size, we discard the
>>> original one and allocate a larger buffer.
>>>
>>> How does this sound?
>>
>> It sounds fine. Your suggestion can indeed decrease the IOCTL time.
>>
>> But, IMO, since attestation will not be used that frequently,
>> we don't need to consider optimization at this point of time. Also, I
>> think the memory allocation time is negligible compared to time it takes
>> for the TDQUOTE generation.
>>
>> Even if we have to do it, we can add it in future as a separate
>> patch. We don't need to add it part of this basic driver support
>> patch.
>>
>>
>
> I am just pointing out Andy made such suggestion before, and it's not something
> we cannot support.
>
> Anyway will let you decide.
Ok.
>
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-25 5:44 ` Kai Huang
2022-04-26 19:07 ` Sathyanarayanan Kuppuswamy
@ 2022-04-27 4:05 ` Sathyanarayanan Kuppuswamy
2022-04-27 4:28 ` Kai Huang
1 sibling, 1 reply; 28+ messages in thread
From: Sathyanarayanan Kuppuswamy @ 2022-04-27 4:05 UTC (permalink / raw)
To: Kai Huang, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86
Cc: H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
linux-kernel
Hi Kai,
On 4/24/22 10:44 PM, Kai Huang wrote:
>> In TDX guest, attestation is used to verify the trustworthiness of a TD
>> to other entities before making any secure communication.
> Before provisioning secrets to the TD.
>
>> One usage example is, when a TD guest uses encrypted drive and the
>> decryption keys required to access the drive are stored in a secure
>> 3rd party keyserver, TD guest can use the quote generated via the
>> attestation process to prove its trustworthiness with keyserver and
>> get access to the storage keys.
> "The key server can use attestation to verify TD's trustworthiness and release
> the decryption keys to the TD".
>
> It is the key server who starts the attestation request, but not the TD.
>
>> General steps involved in attestation process are,
>>
>> 1. TD guest generates the TDREPORT that contains version information
>> about the Intel TDX module, measurement of the TD, along with a
>> TD-specified nonce.
>> 2. TD guest shares the TDREPORT with TD host via GetQuote hypercall
>> which is used by the host to generate a quote via quoting
>> enclave (QE).
>> 3. Quote generation completion notification is sent to TD OS via
>> callback interrupt vector configured by TD using
>> SetupEventNotifyInterrupt hypercall.
>> 4. After receiving the generated TDQUOTE, a remote verifier can be
>> used to verify the quote and confirm the trustworthiness of the
>> TD.
> Let's separate TDREPORT generation and Quote generation, and get rid of details
> of how to get Quote part for now. Detail of GetQuote belongs to the patch which
> implements it. Here I think we should focus on explaining why we need such a
> basic driver to allow userspace to get the TDREPORT.
>
> Below is for your reference:
>
> "
> 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 to contain the TD-specific informatin (such as TD
> measurements), platform information such as the security version of the platform
> and the TDX module and the MAC to protect the integrity of the TDREPORT. TD
> 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.
>
> TDREPORT can only be verified locally as the MAC key is bound to the platform.
> TDX attestation leverages Intel SGX Quote Enclave (QE) to verify the TDREPORT
> locally and convert it to a remote verifiable Quote to support remote
> attestation of the TDREPORT. After getting the TDREPORT, the second step of
> attestation process is to send the TDREPORT to QE to generate the Quote.
>
> How is the QE, or Quote Generation Service (QGS) in general, implemented and
> deployed is implementation specific. As a result, how to send the TDREPORT to
> QE/QGS also depends on QE/QGS implementation and the deployment. TDX doesn't
> support SGX inside a TD, so the QE/QGS can be deployed in the host, or inside a
> dedicated legacy VM.
>
> A typical implementation is TD userspace attestation software gets the TDREPORT
> from TD kernel, sends it to QE/QGS, and QE/QGS returns the Quote. The data and
> data format that TD userspace attestation software sends to the QE/QGS is also
> implementation specific, but not necessarily just the raw TDREPORT. TD
> attestation software can use any available communication channel to talk to
> QE/QGS, such as using vsock and tcp/ip.
>
> To support the case that those communication channels are not directly available
> to the TD, TDX also defines TDVMCALLs to allow TD to use TDVMCALL to ask VMM to
> help with sending the TDREPORT and receiving the Quote. This support is
> documented in the GHCI spec "5.4 TD attestation".
>
> Implement a basic attestation driver to allow TD userspace to get the TDREPORT
> so the attestation software can send it to the QE to generate a Quote for remote
> verification.
> "
>
>
>>
>> More details on above mentioned steps can be found in TDX Guest-Host
>> Communication Interface (GHCI) for Intel TDX 1.0, section titled
>> "TD attestation".
>>
>> To allow the attestation agent (user application) to implement this
>> feature, add an IOCTL interface to get TDREPORT and TDQUOTE from the
>> user space. Since attestation agent can also use methods like vosck or
>> TCP/IP to get the TDQUOTE, adding an IOCTL interface for it is an
>> optional feature. So to simplify the driver, first add support for
>> TDX_CMD_GET_TDREPORT IOCTL. Support for TDQUOTE IOCTL will be added by
>> follow-on patches.
>>
>> TDREPORT can be generated by sending a TDCALL with leaf ID as 0x04.
>> More details about the TDREPORT TDCALL can be found in Intel Trust
>> Domain Extensions (Intel TDX) Module specification, section titled
>> "TDG.MR.REPORT Leaf". Add a wrapper function (tdx_mcall_tdreport())
>> to get the TDREPORT from the TDX Module. This API will be used by the
>> interface driver to request for TDREPORT.
>>
>> 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.
How about the following summary? It includes important notes mentioned
by you and some more driver info.
x86/tdx: Add TDX Guest attestation interface driver
In TDX guest, attestation is used to verify the trustworthiness of a TD
to other entities before provisioning secrets to the TD.
One usage example is, when a TD guest uses encrypted drive and if the
decryption keys required to access the drive are stored in a secure 3rd
party key server, the key server can use attestation to verify TD's
trustworthiness and release the decryption keys to the TD.
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 TD-specific information (such as TD
measurements), platform security version, and the MAC to protect the
integrity of the TDREPORT. The TD 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 TDREPORT can be found in
Intel TDX Module specification, section titled "TDG.MR.REPORT Leaf".
After getting the TDREPORT, the second step of the attestation process
is to send the TDREPORT to Quoting Enclave (QE) or Quote Generation
Service (QGS) to generate the Quote. However, the method of sending the
TDREPORT to QE/QGS, communication channel used and data format used is
specific to the implementation of QE/QGS.
A typical implementation is, TD userspace attestation software gets the
TDREPORT from TD kernel, sends it to QE/QGS, and QE/QGS returns the
Quote. TD attestation software can use any available communication
channel to talk to QE/QGS, such as using vsock and tcp/ip.
To support the case that those communication channels are not directly
available to the TD, TDX also defines TDVMCALL
(TDG.VP.VMCALL<GetQuote>) to allow TD to ask VMM to help with sending
the TDREPORT and receiving the Quote. This support is documented in the
GHCI spec section titled "5.4 TD attestation".
Implement a basic attestation driver to allow TD userspace to get the
TDREPORT, which is sent to QE by the attestation software to generate
a Quote for remote verification. Add a wrapper function
(tdx_mcall_tdreport()) to get the TDREPORT from the TDX Module. This
API will be used by the interface driver to request for TDREPORT.
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.
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-27 4:05 ` Sathyanarayanan Kuppuswamy
@ 2022-04-27 4:28 ` Kai Huang
2022-04-27 14:09 ` Sathyanarayanan Kuppuswamy
0 siblings, 1 reply; 28+ messages in thread
From: Kai Huang @ 2022-04-27 4:28 UTC (permalink / raw)
To: Sathyanarayanan Kuppuswamy, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86
Cc: H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
linux-kernel
>
> How about the following summary? It includes important notes mentioned
> by you and some more driver info.
Yes fine to me, except minor comments below:
>
> x86/tdx: Add TDX Guest attestation interface driver
>
> In TDX guest, attestation is used to verify the trustworthiness of a TD
> to other entities before provisioning secrets to the TD.
>
> One usage example is, when a TD guest uses encrypted drive and if the
> decryption keys required to access the drive are stored in a secure 3rd
> party key server, the key server can use attestation to verify TD's
> trustworthiness and release the decryption keys to the TD.
>
> 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 TD-specific information (such as TD
> measurements), platform security version, and the MAC to protect the
> integrity of the TDREPORT. The TD 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 TDREPORT can be found in
> Intel TDX Module specification, section titled "TDG.MR.REPORT Leaf".
>
> After getting the TDREPORT, the second step of the attestation process
> is to send the TDREPORT to Quoting Enclave (QE) or Quote Generation
> Service (QGS) to generate the Quote. However, the method of sending the
> TDREPORT to QE/QGS, communication channel used and data format used is
> specific to the implementation of QE/QGS.
>
> A typical implementation is, TD userspace attestation software gets the
> TDREPORT from TD kernel, sends it to QE/QGS, and QE/QGS returns the
> Quote. TD attestation software can use any available communication
> channel to talk to QE/QGS, such as using vsock and tcp/ip.
>
> To support the case that those communication channels are not directly
> available to the TD, TDX also defines TDVMCALL
> (TDG.VP.VMCALL<GetQuote>) to allow TD to ask VMM to help with sending
> the TDREPORT and receiving the Quote. This support is documented in the
> GHCI spec section titled "5.4 TD attestation".
I intentionally omitted to mention TDG.VP.VMCALL<GetQuote> as I personally
believe there are still couple issues around GetQuote that we haven't discussed
thoroughly (timeout, etc). I am still considering whether we should change GHCI
to use TDG.VP.VMCALL<Service> defined in GHCI 1.5 for attestation. And the name
of TDVMCALL doesn't actually matter here, so I think we don't need to mention
GetQuote here but just say we have TDVMCALLs for that.
>
> Implement a basic attestation driver to allow TD userspace to get the
> TDREPORT, which is sent to QE by the attestation software to generate
> a Quote for remote verification. Add a wrapper function
> (tdx_mcall_tdreport()) to get the TDREPORT from the TDX Module. This
> API will be used by the interface driver to request for TDREPORT.
I don't think you need to mention tdx_mcall_tdreport().
>
> 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.
>
>
>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-27 4:28 ` Kai Huang
@ 2022-04-27 14:09 ` Sathyanarayanan Kuppuswamy
0 siblings, 0 replies; 28+ messages in thread
From: Sathyanarayanan Kuppuswamy @ 2022-04-27 14:09 UTC (permalink / raw)
To: Kai Huang, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86
Cc: H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
linux-kernel
On 4/26/22 9:28 PM, Kai Huang wrote:
>
>>
>> How about the following summary? It includes important notes mentioned
>> by you and some more driver info.
>
> Yes fine to me, except minor comments below:
>
>>
>> x86/tdx: Add TDX Guest attestation interface driver
>>
>> In TDX guest, attestation is used to verify the trustworthiness of a TD
>> to other entities before provisioning secrets to the TD.
>>
>> One usage example is, when a TD guest uses encrypted drive and if the
>> decryption keys required to access the drive are stored in a secure 3rd
>> party key server, the key server can use attestation to verify TD's
>> trustworthiness and release the decryption keys to the TD.
>>
>> 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 TD-specific information (such as TD
>> measurements), platform security version, and the MAC to protect the
>> integrity of the TDREPORT. The TD 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 TDREPORT can be found in
>> Intel TDX Module specification, section titled "TDG.MR.REPORT Leaf".
>>
>> After getting the TDREPORT, the second step of the attestation process
>> is to send the TDREPORT to Quoting Enclave (QE) or Quote Generation
>> Service (QGS) to generate the Quote. However, the method of sending the
>> TDREPORT to QE/QGS, communication channel used and data format used is
>> specific to the implementation of QE/QGS.
>>
>> A typical implementation is, TD userspace attestation software gets the
>> TDREPORT from TD kernel, sends it to QE/QGS, and QE/QGS returns the
>> Quote. TD attestation software can use any available communication
>> channel to talk to QE/QGS, such as using vsock and tcp/ip.
>>
>> To support the case that those communication channels are not directly
>> available to the TD, TDX also defines TDVMCALL
>> (TDG.VP.VMCALL<GetQuote>) to allow TD to ask VMM to help with sending
>> the TDREPORT and receiving the Quote. This support is documented in the
>> GHCI spec section titled "5.4 TD attestation".
>
> I intentionally omitted to mention TDG.VP.VMCALL<GetQuote> as I personally
> believe there are still couple issues around GetQuote that we haven't discussed
> thoroughly (timeout, etc). I am still considering whether we should change GHCI
> to use TDG.VP.VMCALL<Service> defined in GHCI 1.5 for attestation. And the name
> of TDVMCALL doesn't actually matter here, so I think we don't need to mention
> GetQuote here but just say we have TDVMCALLs for that.
Ok.
>
>>
>> Implement a basic attestation driver to allow TD userspace to get the
>> TDREPORT, which is sent to QE by the attestation software to generate
>> a Quote for remote verification. Add a wrapper function
>> (tdx_mcall_tdreport()) to get the TDREPORT from the TDX Module. This
>> API will be used by the interface driver to request for TDREPORT.
>
> I don't think you need to mention tdx_mcall_tdreport().
Ok. Will remove it.
>
>>
>> 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.
>>
>>
>>
>>
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-22 23:34 ` [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver Kuppuswamy Sathyanarayanan
2022-04-25 5:44 ` Kai Huang
@ 2022-04-27 5:45 ` Isaku Yamahata
2022-04-27 5:57 ` Kai Huang
2022-04-27 22:08 ` Sathyanarayanan Kuppuswamy
2022-04-28 17:45 ` Wander Lairson Costa
2 siblings, 2 replies; 28+ messages in thread
From: Isaku Yamahata @ 2022-04-27 5:45 UTC (permalink / raw)
To: Kuppuswamy Sathyanarayanan
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
Kai Huang, linux-kernel, isaku.yamahata
On Fri, Apr 22, 2022 at 04:34:16PM -0700,
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> wrote:
> In TDX guest, attestation is used to verify the trustworthiness of a TD
> to other entities before making any secure communication.
>
> One usage example is, when a TD guest uses encrypted drive and the
> decryption keys required to access the drive are stored in a secure
> 3rd party keyserver, TD guest can use the quote generated via the
> attestation process to prove its trustworthiness with keyserver and
> get access to the storage keys.
>
> General steps involved in attestation process are,
>
> 1. TD guest generates the TDREPORT that contains version information
> about the Intel TDX module, measurement of the TD, along with a
> TD-specified nonce.
> 2. TD guest shares the TDREPORT with TD host via GetQuote hypercall
> which is used by the host to generate a quote via quoting
> enclave (QE).
> 3. Quote generation completion notification is sent to TD OS via
> callback interrupt vector configured by TD using
> SetupEventNotifyInterrupt hypercall.
> 4. After receiving the generated TDQUOTE, a remote verifier can be
> used to verify the quote and confirm the trustworthiness of the
> TD.
>
> More details on above mentioned steps can be found in TDX Guest-Host
> Communication Interface (GHCI) for Intel TDX 1.0, section titled
> "TD attestation".
>
> To allow the attestation agent (user application) to implement this
> feature, add an IOCTL interface to get TDREPORT and TDQUOTE from the
> user space. Since attestation agent can also use methods like vosck or
> TCP/IP to get the TDQUOTE, adding an IOCTL interface for it is an
> optional feature. So to simplify the driver, first add support for
> TDX_CMD_GET_TDREPORT IOCTL. Support for TDQUOTE IOCTL will be added by
> follow-on patches.
>
> TDREPORT can be generated by sending a TDCALL with leaf ID as 0x04.
> More details about the TDREPORT TDCALL can be found in Intel Trust
> Domain Extensions (Intel TDX) Module specification, section titled
> "TDG.MR.REPORT Leaf". Add a wrapper function (tdx_mcall_tdreport())
> to get the TDREPORT from the TDX Module. This API will be used by the
> interface driver to request for TDREPORT.
>
> 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.
>
> 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>
> ---
> arch/x86/coco/tdx/Makefile | 2 +-
> arch/x86/coco/tdx/attest.c | 191 ++++++++++++++++++++++++++++++++
> arch/x86/coco/tdx/tdx.c | 45 ++++++++
> arch/x86/include/asm/tdx.h | 2 +
> arch/x86/include/uapi/asm/tdx.h | 23 ++++
> 5 files changed, 262 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/coco/tdx/attest.c
> create mode 100644 arch/x86/include/uapi/asm/tdx.h
>
> diff --git a/arch/x86/coco/tdx/Makefile b/arch/x86/coco/tdx/Makefile
> index 46c55998557d..d2db3e6770e5 100644
> --- a/arch/x86/coco/tdx/Makefile
> +++ b/arch/x86/coco/tdx/Makefile
> @@ -1,3 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -obj-y += tdx.o tdcall.o
> +obj-y += tdx.o tdcall.o attest.o
> diff --git a/arch/x86/coco/tdx/attest.c b/arch/x86/coco/tdx/attest.c
> new file mode 100644
> index 000000000000..b776e81f6c20
> --- /dev/null
> +++ b/arch/x86/coco/tdx/attest.c
> @@ -0,0 +1,191 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * attest.c - TDX guest attestation interface driver.
> + *
> + * Implements user interface to trigger attestation process and
> + * read the TD Quote result.
> + *
> + * Copyright (C) 2022 Intel Corporation
> + *
> + */
> +
> +#define pr_fmt(fmt) "x86/tdx: attest: " fmt
> +
> +#include <linux/module.h>
> +#include <linux/miscdevice.h>
> +#include <linux/uaccess.h>
> +#include <linux/fs.h>
> +#include <linux/mm.h>
> +#include <linux/slab.h>
> +#include <linux/set_memory.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/platform_device.h>
> +#include <linux/jiffies.h>
> +#include <linux/io.h>
> +#include <asm/apic.h>
> +#include <asm/tdx.h>
> +#include <asm/irq_vectors.h>
> +#include <uapi/asm/tdx.h>
> +
> +#define DRIVER_NAME "tdx-attest"
> +
> +static struct platform_device *pdev;
> +static struct miscdevice miscdev;
> +
> +static long tdx_get_tdreport(void __user *argp)
> +{
> + void *report_buf = NULL, *tdreport_buf = NULL;
> + long ret = 0, err;
> +
> + /* Allocate space for report data */
> + report_buf = kmalloc(TDX_REPORT_DATA_LEN, GFP_KERNEL);
> + if (!report_buf)
> + return -ENOMEM;
> +
> + /*
> + * Allocate space for TDREPORT buffer (1024-byte aligned).
> + * Full page alignment is more than enough.
> + */
> + tdreport_buf = (void *)get_zeroed_page(GFP_KERNEL);
> + if (!tdreport_buf) {
> + ret = -ENOMEM;
> + goto tdreport_failed;
> + }
> +
> + /* Copy report data to kernel buffer */
> + if (copy_from_user(report_buf, argp, TDX_REPORT_DATA_LEN)) {
> + ret = -EFAULT;
> + goto tdreport_failed;
> + }
> +
> + /* Generate TDREPORT using report data in report_buf */
> + err = tdx_mcall_tdreport(tdreport_buf, report_buf);
> + if (err) {
> + /* If failed, pass TDCALL error code back to user */
> + ret = put_user(err, (long __user *)argp);
ret is ignored. ret should be checked or ignore it explicitly by (void).
> + ret = -EIO;
> + goto tdreport_failed;
> + }
> +
> + /* Copy TDREPORT data back to user buffer */
> + if (copy_to_user(argp, tdreport_buf, TDX_TDREPORT_LEN))
> + ret = -EFAULT;
> +
> +tdreport_failed:
> + kfree(report_buf);
> + if (tdreport_buf)
> + free_pages((unsigned long)tdreport_buf, 0);
> +
> + return ret;
> +}
> +
> +static long tdx_attest_ioctl(struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> + void __user *argp = (void __user *)arg;
> + long ret = 0;
> +
> + switch (cmd) {
> + case TDX_CMD_GET_TDREPORT:
> + ret = tdx_get_tdreport(argp);
> + break;
> + default:
> + pr_err("cmd %d not supported\n", cmd);
pr_debug()? At least error should be returned to user space.
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static const struct file_operations tdx_attest_fops = {
> + .owner = THIS_MODULE,
> + .unlocked_ioctl = tdx_attest_ioctl,
> + .llseek = no_llseek,
> +};
> +
> +static int tdx_attest_probe(struct platform_device *attest_pdev)
> +{
> + struct device *dev = &attest_pdev->dev;
> + long ret = 0;
> +
> + /* Only single device is allowed */
> + if (pdev)
> + return -EBUSY;
> +
> + pdev = attest_pdev;
> +
> + miscdev.name = DRIVER_NAME;
> + miscdev.minor = MISC_DYNAMIC_MINOR;
> + miscdev.fops = &tdx_attest_fops;
> + miscdev.parent = dev;
> +
> + ret = misc_register(&miscdev);
> + if (ret) {
> + pr_err("misc device registration failed\n");
> + goto failed;
> + }
> +
> + pr_debug("module initialization success\n");
> +
> + return 0;
> +
> +failed:
> + misc_deregister(&miscdev);
> +
> + pr_debug("module initialization failed\n");
> +
> + return ret;
> +}
> +
> +static int tdx_attest_remove(struct platform_device *attest_pdev)
> +{
> + misc_deregister(&miscdev);
> + pr_debug("module is successfully removed\n");
> + return 0;
> +}
> +
> +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);
> +
> +MODULE_AUTHOR("Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>");
> +MODULE_DESCRIPTION("TDX attestation driver");
> +MODULE_LICENSE("GPL");
> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
> index 03deb4d6920d..2a79ca92a52d 100644
> --- a/arch/x86/coco/tdx/tdx.c
> +++ b/arch/x86/coco/tdx/tdx.c
> @@ -11,10 +11,12 @@
> #include <asm/insn.h>
> #include <asm/insn-eval.h>
> #include <asm/pgtable.h>
> +#include <asm/io.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 */
> @@ -34,6 +36,10 @@
> #define VE_GET_PORT_NUM(e) ((e) >> 16)
> #define VE_IS_IO_STRING(e) ((e) & BIT(4))
>
> +/* TDX Module call error codes */
> +#define TDCALL_RETURN_CODE_MASK 0xffffffff00000000
> +#define TDCALL_RETURN_CODE(a) ((a) & TDCALL_RETURN_CODE_MASK)
> +
> /*
> * Wrapper for standard use of __tdx_hypercall with no output aside from
> * return code.
> @@ -98,6 +104,45 @@ static inline void tdx_module_call(u64 fn, u64 rcx, u64 rdx, u64 r8, u64 r9,
> panic("TDCALL %lld failed (Buggy TDX module!)\n", fn);
> }
>
> +/*
> + * tdx_mcall_tdreport() - Generate TDREPORT_STRUCT using TDCALL.
> + *
> + * @data : Address of 1024B aligned data to store
> + * TDREPORT_STRUCT.
> + * @reportdata : Address of 64B aligned report data
> + *
> + * return 0 on success or failure error number.
Is "failure error number" TDX status code? not -Evalue?
> + */
> +long tdx_mcall_tdreport(void *data, void *reportdata)
> +{
> + u64 ret;
> +
> + /*
> + * Check for a valid TDX guest to ensure this API is only
> + * used by TDX guest platform. Also make sure "data" and
> + * "reportdata" pointers are valid.
> + */
> + if (!data || !reportdata || !cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
> + return -EINVAL;
> +
> + /*
> + * Pass the physical address of user generated report data
> + * and the physical address of output buffer to the TDX module
> + * to generate the TD report. Generated data contains
> + * measurements/configuration data of the TD guest. More info
> + * about ABI can be found in TDX 1.0 Module specification, sec
> + * titled "TDG.MR.REPORT".
> + */
> + ret = __tdx_module_call(TDX_GET_REPORT, virt_to_phys(data),
> + virt_to_phys(reportdata), 0, 0, NULL);
> +
> + if (ret)
> + return TDCALL_RETURN_CODE(ret);
Why is status code masked?
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(tdx_mcall_tdreport);
Can this function be put into attest.c. Instead, wecan export __tdx_module_call.
> static u64 get_cc_mask(void)
> {
> struct tdx_module_output out;
> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
> index 020c81a7c729..a151f69dd6ef 100644
> --- a/arch/x86/include/asm/tdx.h
> +++ b/arch/x86/include/asm/tdx.h
> @@ -67,6 +67,8 @@ void tdx_safe_halt(void);
>
> bool tdx_early_handle_ve(struct pt_regs *regs);
>
> +long tdx_mcall_tdreport(void *data, void *reportdata);
> +
> #else
>
> static inline void tdx_early_init(void) { };
> diff --git a/arch/x86/include/uapi/asm/tdx.h b/arch/x86/include/uapi/asm/tdx.h
> new file mode 100644
> index 000000000000..c21f9d6fe88b
> --- /dev/null
> +++ b/arch/x86/include/uapi/asm/tdx.h
> @@ -0,0 +1,23 @@
> +/* 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>
> +
> +/* Input report data length for TDX_CMD_GET_TDREPORT IOCTL request */
> +#define TDX_REPORT_DATA_LEN 64
> +
> +/* Output TD report data length after TDX_CMD_GET_TDREPORT IOCTL execution */
> +#define TDX_TDREPORT_LEN 1024
> +
> +/*
> + * TDX_CMD_GET_TDREPORT IOCTL is used to get TDREPORT data from the TDX
> + * Module. Users should pass report data of size TDX_REPORT_DATA_LEN bytes
> + * via user input buffer of size TDX_TDREPORT_LEN. Once IOCTL is successful
> + * TDREPORT data is copied to the user buffer. On failure, TDCALL error
> + * code is copied back to the user buffer.
> + */
> +#define TDX_CMD_GET_TDREPORT _IOWR('T', 0x01, __u64)
> +
> +#endif /* _UAPI_ASM_X86_TDX_H */
> --
> 2.25.1
>
--
Isaku Yamahata <isaku.yamahata@gmail.com>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-27 5:45 ` Isaku Yamahata
@ 2022-04-27 5:57 ` Kai Huang
2022-04-27 22:08 ` Sathyanarayanan Kuppuswamy
1 sibling, 0 replies; 28+ messages in thread
From: Kai Huang @ 2022-04-27 5:57 UTC (permalink / raw)
To: Isaku Yamahata, Kuppuswamy Sathyanarayanan
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
linux-kernel
On Tue, 2022-04-26 at 22:45 -0700, Isaku Yamahata wrote:
> > + */
> > +long tdx_mcall_tdreport(void *data, void *reportdata)
> > +{
> > + u64 ret;
> > +
> > + /*
> > + * Check for a valid TDX guest to ensure this API is only
> > + * used by TDX guest platform. Also make sure "data" and
> > + * "reportdata" pointers are valid.
> > + */
> > + if (!data || !reportdata ||
> > !cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
> > + return -EINVAL;
> > +
> > + /*
> > + * Pass the physical address of user generated report data
> > + * and the physical address of output buffer to the TDX module
> > + * to generate the TD report. Generated data contains
> > + * measurements/configuration data of the TD guest. More info
> > + * about ABI can be found in TDX 1.0 Module specification, sec
> > + * titled "TDG.MR.REPORT".
> > + */
> > + ret = __tdx_module_call(TDX_GET_REPORT, virt_to_phys(data),
> > + virt_to_phys(reportdata), 0, 0, NULL);
> > +
> > + if (ret)
> > + return TDCALL_RETURN_CODE(ret);
>
> Why is status code masked?
>
>
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(tdx_mcall_tdreport);
>
> Can this function be put into attest.c. Instead, wecan export
> __tdx_module_call.
As we discussed, there's no need to export this anymore.
Btw, I even think we can move this function to attest.c so it can be static.
Theoretically there should be no other caller of this except attest.c. I
understand in this way we need to define TDX_GET_REPORT macro in attest.c but
this looks fine to me. This function can even be removed, and we can call
__tdx_module_call() directly in attest.c. This function literally doesn't do
anything meaningful more than __tdx_module_call(), instead, calling
__tdx_module_call() directly gives us more context, i.e., we can easily see the
buffer is allocated by kernel and passed to TDX module, etc.
--
Thanks,
-Kai
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-27 5:45 ` Isaku Yamahata
2022-04-27 5:57 ` Kai Huang
@ 2022-04-27 22:08 ` Sathyanarayanan Kuppuswamy
1 sibling, 0 replies; 28+ messages in thread
From: Sathyanarayanan Kuppuswamy @ 2022-04-27 22:08 UTC (permalink / raw)
To: Isaku Yamahata
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
Kai Huang, linux-kernel
Hi Isaku,
On 4/26/22 10:45 PM, Isaku Yamahata wrote:
> On Fri, Apr 22, 2022 at 04:34:16PM -0700,
> Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> wrote:
>
>> In TDX guest, attestation is used to verify the trustworthiness of a TD
>> to other entities before making any secure communication.
>>
>> One usage example is, when a TD guest uses encrypted drive and the
>> decryption keys required to access the drive are stored in a secure
>> 3rd party keyserver, TD guest can use the quote generated via the
>> attestation process to prove its trustworthiness with keyserver and
>> get access to the storage keys.
>>
>> General steps involved in attestation process are,
>>
>> 1. TD guest generates the TDREPORT that contains version information
>> about the Intel TDX module, measurement of the TD, along with a
>> TD-specified nonce.
>> 2. TD guest shares the TDREPORT with TD host via GetQuote hypercall
>> which is used by the host to generate a quote via quoting
>> enclave (QE).
>> 3. Quote generation completion notification is sent to TD OS via
>> callback interrupt vector configured by TD using
>> SetupEventNotifyInterrupt hypercall.
>> 4. After receiving the generated TDQUOTE, a remote verifier can be
>> used to verify the quote and confirm the trustworthiness of the
>> TD.
>>
>> More details on above mentioned steps can be found in TDX Guest-Host
>> Communication Interface (GHCI) for Intel TDX 1.0, section titled
>> "TD attestation".
>>
>> To allow the attestation agent (user application) to implement this
>> feature, add an IOCTL interface to get TDREPORT and TDQUOTE from the
>> user space. Since attestation agent can also use methods like vosck or
>> TCP/IP to get the TDQUOTE, adding an IOCTL interface for it is an
>> optional feature. So to simplify the driver, first add support for
>> TDX_CMD_GET_TDREPORT IOCTL. Support for TDQUOTE IOCTL will be added by
>> follow-on patches.
>>
>> TDREPORT can be generated by sending a TDCALL with leaf ID as 0x04.
>> More details about the TDREPORT TDCALL can be found in Intel Trust
>> Domain Extensions (Intel TDX) Module specification, section titled
>> "TDG.MR.REPORT Leaf". Add a wrapper function (tdx_mcall_tdreport())
>> to get the TDREPORT from the TDX Module. This API will be used by the
>> interface driver to request for TDREPORT.
>>
>> 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.
>>
>> 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>
>> ---
>> arch/x86/coco/tdx/Makefile | 2 +-
>> arch/x86/coco/tdx/attest.c | 191 ++++++++++++++++++++++++++++++++
>> arch/x86/coco/tdx/tdx.c | 45 ++++++++
>> arch/x86/include/asm/tdx.h | 2 +
>> arch/x86/include/uapi/asm/tdx.h | 23 ++++
>> 5 files changed, 262 insertions(+), 1 deletion(-)
>> create mode 100644 arch/x86/coco/tdx/attest.c
>> create mode 100644 arch/x86/include/uapi/asm/tdx.h
>>
>> diff --git a/arch/x86/coco/tdx/Makefile b/arch/x86/coco/tdx/Makefile
>> index 46c55998557d..d2db3e6770e5 100644
>> --- a/arch/x86/coco/tdx/Makefile
>> +++ b/arch/x86/coco/tdx/Makefile
>> @@ -1,3 +1,3 @@
>> # SPDX-License-Identifier: GPL-2.0
>>
>> -obj-y += tdx.o tdcall.o
>> +obj-y += tdx.o tdcall.o attest.o
>> diff --git a/arch/x86/coco/tdx/attest.c b/arch/x86/coco/tdx/attest.c
>> new file mode 100644
>> index 000000000000..b776e81f6c20
>> --- /dev/null
>> +++ b/arch/x86/coco/tdx/attest.c
>> @@ -0,0 +1,191 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * attest.c - TDX guest attestation interface driver.
>> + *
>> + * Implements user interface to trigger attestation process and
>> + * read the TD Quote result.
>> + *
>> + * Copyright (C) 2022 Intel Corporation
>> + *
>> + */
>> +
>> +#define pr_fmt(fmt) "x86/tdx: attest: " fmt
>> +
>> +#include <linux/module.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/uaccess.h>
>> +#include <linux/fs.h>
>> +#include <linux/mm.h>
>> +#include <linux/slab.h>
>> +#include <linux/set_memory.h>
>> +#include <linux/dma-mapping.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/io.h>
>> +#include <asm/apic.h>
>> +#include <asm/tdx.h>
>> +#include <asm/irq_vectors.h>
>> +#include <uapi/asm/tdx.h>
>> +
>> +#define DRIVER_NAME "tdx-attest"
>> +
>> +static struct platform_device *pdev;
>> +static struct miscdevice miscdev;
>> +
>> +static long tdx_get_tdreport(void __user *argp)
>> +{
>> + void *report_buf = NULL, *tdreport_buf = NULL;
>> + long ret = 0, err;
>> +
>> + /* Allocate space for report data */
>> + report_buf = kmalloc(TDX_REPORT_DATA_LEN, GFP_KERNEL);
>> + if (!report_buf)
>> + return -ENOMEM;
>> +
>> + /*
>> + * Allocate space for TDREPORT buffer (1024-byte aligned).
>> + * Full page alignment is more than enough.
>> + */
>> + tdreport_buf = (void *)get_zeroed_page(GFP_KERNEL);
>> + if (!tdreport_buf) {
>> + ret = -ENOMEM;
>> + goto tdreport_failed;
>> + }
>> +
>> + /* Copy report data to kernel buffer */
>> + if (copy_from_user(report_buf, argp, TDX_REPORT_DATA_LEN)) {
>> + ret = -EFAULT;
>> + goto tdreport_failed;
>> + }
>> +
>> + /* Generate TDREPORT using report data in report_buf */
>> + err = tdx_mcall_tdreport(tdreport_buf, report_buf);
>> + if (err) {
>> + /* If failed, pass TDCALL error code back to user */
>> + ret = put_user(err, (long __user *)argp);
>
> ret is ignored. ret should be checked or ignore it explicitly by (void).
Since we are already in error path and we are going to return -EIO, I
did not check for it. I will ignore it explictly in next version.
>
>
>> + ret = -EIO;
>> + goto tdreport_failed;
>> + }
>> +
>> + /* Copy TDREPORT data back to user buffer */
>> + if (copy_to_user(argp, tdreport_buf, TDX_TDREPORT_LEN))
>> + ret = -EFAULT;
>> +
>> +tdreport_failed:
>> + kfree(report_buf);
>> + if (tdreport_buf)
>> + free_pages((unsigned long)tdreport_buf, 0);
>> +
>> + return ret;
>> +}
>> +
>> +static long tdx_attest_ioctl(struct file *file, unsigned int cmd,
>> + unsigned long arg)
>> +{
>> + void __user *argp = (void __user *)arg;
>> + long ret = 0;
>> +
>> + switch (cmd) {
>> + case TDX_CMD_GET_TDREPORT:
>> + ret = tdx_get_tdreport(argp);
>> + break;
>> + default:
>> + pr_err("cmd %d not supported\n", cmd);
>
> pr_debug()? At least error should be returned to user space.
Ok. I will change it to pr_debug(). I have already addressed the
issue of not setting error value in default case.
>
>> + break;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static const struct file_operations tdx_attest_fops = {
>> + .owner = THIS_MODULE,
>> + .unlocked_ioctl = tdx_attest_ioctl,
>> + .llseek = no_llseek,
>> +};
>> +
>> +static int tdx_attest_probe(struct platform_device *attest_pdev)
>> +{
>> + struct device *dev = &attest_pdev->dev;
>> + long ret = 0;
>> +
>> + /* Only single device is allowed */
>> + if (pdev)
>> + return -EBUSY;
>> +
>> + pdev = attest_pdev;
>> +
>> + miscdev.name = DRIVER_NAME;
>> + miscdev.minor = MISC_DYNAMIC_MINOR;
>> + miscdev.fops = &tdx_attest_fops;
>> + miscdev.parent = dev;
>> +
>> + ret = misc_register(&miscdev);
>> + if (ret) {
>> + pr_err("misc device registration failed\n");
>> + goto failed;
>> + }
>> +
>> + pr_debug("module initialization success\n");
>> +
>> + return 0;
>> +
>> +failed:
>> + misc_deregister(&miscdev);
>> +
>> + pr_debug("module initialization failed\n");
>> +
>> + return ret;
>> +}
>> +
>> +static int tdx_attest_remove(struct platform_device *attest_pdev)
>> +{
>> + misc_deregister(&miscdev);
>> + pr_debug("module is successfully removed\n");
>> + return 0;
>> +}
>> +
>> +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);
>> +
>> +MODULE_AUTHOR("Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>");
>> +MODULE_DESCRIPTION("TDX attestation driver");
>> +MODULE_LICENSE("GPL");
>> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
>> index 03deb4d6920d..2a79ca92a52d 100644
>> --- a/arch/x86/coco/tdx/tdx.c
>> +++ b/arch/x86/coco/tdx/tdx.c
>> @@ -11,10 +11,12 @@
>> #include <asm/insn.h>
>> #include <asm/insn-eval.h>
>> #include <asm/pgtable.h>
>> +#include <asm/io.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 */
>> @@ -34,6 +36,10 @@
>> #define VE_GET_PORT_NUM(e) ((e) >> 16)
>> #define VE_IS_IO_STRING(e) ((e) & BIT(4))
>>
>> +/* TDX Module call error codes */
>> +#define TDCALL_RETURN_CODE_MASK 0xffffffff00000000
>> +#define TDCALL_RETURN_CODE(a) ((a) & TDCALL_RETURN_CODE_MASK)
>> +
>> /*
>> * Wrapper for standard use of __tdx_hypercall with no output aside from
>> * return code.
>> @@ -98,6 +104,45 @@ static inline void tdx_module_call(u64 fn, u64 rcx, u64 rdx, u64 r8, u64 r9,
>> panic("TDCALL %lld failed (Buggy TDX module!)\n", fn);
>> }
>>
>> +/*
>> + * tdx_mcall_tdreport() - Generate TDREPORT_STRUCT using TDCALL.
>> + *
>> + * @data : Address of 1024B aligned data to store
>> + * TDREPORT_STRUCT.
>> + * @reportdata : Address of 64B aligned report data
>> + *
>> + * return 0 on success or failure error number.
>
> Is "failure error number" TDX status code? not -Evalue?
It is not -Evalue. I can use the term "TDX error code"
>
>
>> + */
>> +long tdx_mcall_tdreport(void *data, void *reportdata)
>> +{
>> + u64 ret;
>> +
>> + /*
>> + * Check for a valid TDX guest to ensure this API is only
>> + * used by TDX guest platform. Also make sure "data" and
>> + * "reportdata" pointers are valid.
>> + */
>> + if (!data || !reportdata || !cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
>> + return -EINVAL;
>> +
>> + /*
>> + * Pass the physical address of user generated report data
>> + * and the physical address of output buffer to the TDX module
>> + * to generate the TD report. Generated data contains
>> + * measurements/configuration data of the TD guest. More info
>> + * about ABI can be found in TDX 1.0 Module specification, sec
>> + * titled "TDG.MR.REPORT".
>> + */
>> + ret = __tdx_module_call(TDX_GET_REPORT, virt_to_phys(data),
>> + virt_to_phys(reportdata), 0, 0, NULL);
>> +
>> + if (ret)
>> + return TDCALL_RETURN_CODE(ret);
>
> Why is status code masked?
Only upper 32 bit has error code. Check "Function Completion Status
Codes" in TDX module spec.
>
>
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(tdx_mcall_tdreport);
>
> Can this function be put into attest.c. Instead, wecan export __tdx_module_call.
We don't need to export it anymore. I will remove it in next version.
Regarding moving it to attest.c, currently all TDCALL/TDVMCALL wrappers
are left in one place (in tdx.c). For example check tdx_kvm_hypercall()
implementation in tdx.c. I don't see any specific need to break this
uniformity for our use case. Grouping them together will make
it easier if we are fixing some core issues in core functions like
__tdx_hypercall() in future.
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-22 23:34 ` [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver Kuppuswamy Sathyanarayanan
2022-04-25 5:44 ` Kai Huang
2022-04-27 5:45 ` Isaku Yamahata
@ 2022-04-28 17:45 ` Wander Lairson Costa
2022-04-28 17:56 ` Sathyanarayanan Kuppuswamy
2 siblings, 1 reply; 28+ messages in thread
From: Wander Lairson Costa @ 2022-04-28 17:45 UTC (permalink / raw)
To: Kuppuswamy Sathyanarayanan
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
Kai Huang, linux-kernel
On Fri, Apr 22, 2022 at 04:34:16PM -0700, Kuppuswamy Sathyanarayanan wrote:
[snip]
> +static long tdx_get_tdreport(void __user *argp)
> +{
> + void *report_buf = NULL, *tdreport_buf = NULL;
> + long ret = 0, err;
> +
> + /* Allocate space for report data */
> + report_buf = kmalloc(TDX_REPORT_DATA_LEN, GFP_KERNEL);
> + if (!report_buf)
> + return -ENOMEM;
> +
> + /*
> + * Allocate space for TDREPORT buffer (1024-byte aligned).
> + * Full page alignment is more than enough.
> + */
> + tdreport_buf = (void *)get_zeroed_page(GFP_KERNEL);
Maybe we should add BUILD_BUG_ON(TDX_TDREPORT_LEN > PAGE_SIZE)
> + if (!tdreport_buf) {
> + ret = -ENOMEM;
> + goto tdreport_failed;
> + }
> +
> + /* Copy report data to kernel buffer */
> + if (copy_from_user(report_buf, argp, TDX_REPORT_DATA_LEN)) {
> + ret = -EFAULT;
> + goto tdreport_failed;
> + }
> +
> + /* Generate TDREPORT using report data in report_buf */
> + err = tdx_mcall_tdreport(tdreport_buf, report_buf);
> + if (err) {
> + /* If failed, pass TDCALL error code back to user */
> + ret = put_user(err, (long __user *)argp);
The assigment to ret is useless here
> + ret = -EIO;
> + goto tdreport_failed;
> + }
> +
> + /* Copy TDREPORT data back to user buffer */
> + if (copy_to_user(argp, tdreport_buf, TDX_TDREPORT_LEN))
> + ret = -EFAULT;
> +
> +tdreport_failed:
> + kfree(report_buf);
> + if (tdreport_buf)
> + free_pages((unsigned long)tdreport_buf, 0);
> +
> + return ret;
> +}
> +
> +static long tdx_attest_ioctl(struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> + void __user *argp = (void __user *)arg;
> + long ret = 0;
> +
> + switch (cmd) {
> + case TDX_CMD_GET_TDREPORT:
> + ret = tdx_get_tdreport(argp);
> + break;
> + default:
> + pr_err("cmd %d not supported\n", cmd);
Shouldn't we add "ret = -EINVAL" here?
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static const struct file_operations tdx_attest_fops = {
> + .owner = THIS_MODULE,
> + .unlocked_ioctl = tdx_attest_ioctl,
> + .llseek = no_llseek,
> +};
> +
> +static int tdx_attest_probe(struct platform_device *attest_pdev)
> +{
> + struct device *dev = &attest_pdev->dev;
> + long ret = 0;
> +
> + /* Only single device is allowed */
> + if (pdev)
> + return -EBUSY;
> +
> + pdev = attest_pdev;
> +
> + miscdev.name = DRIVER_NAME;
> + miscdev.minor = MISC_DYNAMIC_MINOR;
> + miscdev.fops = &tdx_attest_fops;
> + miscdev.parent = dev;
> +
> + ret = misc_register(&miscdev);
> + if (ret) {
> + pr_err("misc device registration failed\n");
> + goto failed;
Why just not return error here? There is nothing to cleanup
> + }
> +
> + pr_debug("module initialization success\n");
> +
> + return 0;
> +
> +failed:
> + misc_deregister(&miscdev);
The only way to get here is if misc_register fails, so we don't need
this call here.
> +
> + pr_debug("module initialization failed\n");
> +
> + return ret;
> +}
> +
> +static int tdx_attest_remove(struct platform_device *attest_pdev)
> +{
> + misc_deregister(&miscdev);
> + pr_debug("module is successfully removed\n");
> + return 0;
> +}
> +
> +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);
pdev is assigned here and in the probe function. Is it correct?
> + 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;
> + }
> +
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-28 17:45 ` Wander Lairson Costa
@ 2022-04-28 17:56 ` Sathyanarayanan Kuppuswamy
2022-04-28 18:04 ` Dave Hansen
0 siblings, 1 reply; 28+ messages in thread
From: Sathyanarayanan Kuppuswamy @ 2022-04-28 17:56 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
Kai Huang, linux-kernel
Hi,
On 4/28/22 10:45 AM, Wander Lairson Costa wrote:
> On Fri, Apr 22, 2022 at 04:34:16PM -0700, Kuppuswamy Sathyanarayanan wrote:
>
> [snip]
>
>> +static long tdx_get_tdreport(void __user *argp)
>> +{
>> + void *report_buf = NULL, *tdreport_buf = NULL;
>> + long ret = 0, err;
>> +
>> + /* Allocate space for report data */
>> + report_buf = kmalloc(TDX_REPORT_DATA_LEN, GFP_KERNEL);
>> + if (!report_buf)
>> + return -ENOMEM;
>> +
>> + /*
>> + * Allocate space for TDREPORT buffer (1024-byte aligned).
>> + * Full page alignment is more than enough.
>> + */
>> + tdreport_buf = (void *)get_zeroed_page(GFP_KERNEL);
>
> Maybe we should add BUILD_BUG_ON(TDX_TDREPORT_LEN > PAGE_SIZE)
Currently, it is a constant value < PAGE_SIZE. But I can add the
BUILD_BUG_ON check for it.
>
>> + if (!tdreport_buf) {
>> + ret = -ENOMEM;
>> + goto tdreport_failed;
>> + }
>> +
>> + /* Copy report data to kernel buffer */
>> + if (copy_from_user(report_buf, argp, TDX_REPORT_DATA_LEN)) {
>> + ret = -EFAULT;
>> + goto tdreport_failed;
>> + }
>> +
>> + /* Generate TDREPORT using report data in report_buf */
>> + err = tdx_mcall_tdreport(tdreport_buf, report_buf);
>> + if (err) {
>> + /* If failed, pass TDCALL error code back to user */
>> + ret = put_user(err, (long __user *)argp);
>
> The assigment to ret is useless here
Yes, noted it already. I will remove it in next version.
>
>> + ret = -EIO;
>> + goto tdreport_failed;
>> + }
>> +
>> + /* Copy TDREPORT data back to user buffer */
>> + if (copy_to_user(argp, tdreport_buf, TDX_TDREPORT_LEN))
>> + ret = -EFAULT;
>> +
>> +tdreport_failed:
>> + kfree(report_buf);
>> + if (tdreport_buf)
>> + free_pages((unsigned long)tdreport_buf, 0);
>> +
>> + return ret;
>> +}
>> +
>> +static long tdx_attest_ioctl(struct file *file, unsigned int cmd,
>> + unsigned long arg)
>> +{
>> + void __user *argp = (void __user *)arg;
>> + long ret = 0;
>> +
>> + switch (cmd) {
>> + case TDX_CMD_GET_TDREPORT:
>> + ret = tdx_get_tdreport(argp);
>> + break;
>> + default:
>> + pr_err("cmd %d not supported\n", cmd);
>
> Shouldn't we add "ret = -EINVAL" here?
Yes. I have noted it already, I will fix this in next version.
>
>> + break;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static const struct file_operations tdx_attest_fops = {
>> + .owner = THIS_MODULE,
>> + .unlocked_ioctl = tdx_attest_ioctl,
>> + .llseek = no_llseek,
>> +};
>> +
>> +static int tdx_attest_probe(struct platform_device *attest_pdev)
>> +{
>> + struct device *dev = &attest_pdev->dev;
>> + long ret = 0;
>> +
>> + /* Only single device is allowed */
>> + if (pdev)
>> + return -EBUSY;
>> +
>> + pdev = attest_pdev;
>> +
>> + miscdev.name = DRIVER_NAME;
>> + miscdev.minor = MISC_DYNAMIC_MINOR;
>> + miscdev.fops = &tdx_attest_fops;
>> + miscdev.parent = dev;
>> +
>> + ret = misc_register(&miscdev);
>> + if (ret) {
>> + pr_err("misc device registration failed\n");
>> + goto failed;
>
> Why just not return error here? There is nothing to cleanup
Agree. It came along with patch split I did. I will remove it
in next version.
>
>> + }
>> +
>> + pr_debug("module initialization success\n");
>> +
>> + return 0;
>> +
>> +failed:
>> + misc_deregister(&miscdev);
>
> The only way to get here is if misc_register fails, so we don't need
> this call here.
Yes. It is not required. I will remove it.
>
>> +
>> + pr_debug("module initialization failed\n");
>> +
>> + return ret;
>> +}
>> +
>> +static int tdx_attest_remove(struct platform_device *attest_pdev)
>> +{
>> + misc_deregister(&miscdev);
>> + pr_debug("module is successfully removed\n");
>> + return 0;
>> +}
>> +
>> +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);
>
> pdev is assigned here and in the probe function. Is it correct?
platform_device_register_simple() seem to trigger probe before it
returns. So assigning it in probe is correct. Here it is redundant (
but not harmful)
Anyway this change will go way in next version when I change the driver
to be a pure "misc driver" and remove the "platform driver" support.
>
>> + 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;
>> + }
>> +
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-28 17:56 ` Sathyanarayanan Kuppuswamy
@ 2022-04-28 18:04 ` Dave Hansen
2022-04-28 18:18 ` Sathyanarayanan Kuppuswamy
0 siblings, 1 reply; 28+ messages in thread
From: Dave Hansen @ 2022-04-28 18:04 UTC (permalink / raw)
To: Sathyanarayanan Kuppuswamy, Wander Lairson Costa
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
Kai Huang, linux-kernel
On 4/28/22 10:56, Sathyanarayanan Kuppuswamy wrote:
> On 4/28/22 10:45 AM, Wander Lairson Costa wrote:
>> On Fri, Apr 22, 2022 at 04:34:16PM -0700, Kuppuswamy Sathyanarayanan
>> wrote:
>>> +static long tdx_get_tdreport(void __user *argp)
>>> +{
>>> + void *report_buf = NULL, *tdreport_buf = NULL;
>>> + long ret = 0, err;
>>> +
>>> + /* Allocate space for report data */
>>> + report_buf = kmalloc(TDX_REPORT_DATA_LEN, GFP_KERNEL);
>>> + if (!report_buf)
>>> + return -ENOMEM;
>>> +
>>> + /*
>>> + * Allocate space for TDREPORT buffer (1024-byte aligned).
>>> + * Full page alignment is more than enough.
>>> + */
>>> + tdreport_buf = (void *)get_zeroed_page(GFP_KERNEL);
>>
>> Maybe we should add BUILD_BUG_ON(TDX_TDREPORT_LEN > PAGE_SIZE)
>
> Currently, it is a constant value < PAGE_SIZE. But I can add the
> BUILD_BUG_ON check for it.
That's kinda silly. If it might ever be bigger than a page, you just do:
tdreport_buf = alloc_pages();
But, seriously, TDX_TDREPORT_LEN is part of the ABI and can't change.
kmalloc() would work too since TDX_TDREPORT_LEN is a power of 2.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver
2022-04-28 18:04 ` Dave Hansen
@ 2022-04-28 18:18 ` Sathyanarayanan Kuppuswamy
0 siblings, 0 replies; 28+ messages in thread
From: Sathyanarayanan Kuppuswamy @ 2022-04-28 18:18 UTC (permalink / raw)
To: Dave Hansen, Wander Lairson Costa
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H . Peter Anvin, Kirill A . Shutemov, Tony Luck, Andi Kleen,
Kai Huang, linux-kernel
On 4/28/22 11:04 AM, Dave Hansen wrote:
> On 4/28/22 10:56, Sathyanarayanan Kuppuswamy wrote:
>> On 4/28/22 10:45 AM, Wander Lairson Costa wrote:
>>> On Fri, Apr 22, 2022 at 04:34:16PM -0700, Kuppuswamy Sathyanarayanan
>>> wrote:
>>>> +static long tdx_get_tdreport(void __user *argp)
>>>> +{
>>>> + void *report_buf = NULL, *tdreport_buf = NULL;
>>>> + long ret = 0, err;
>>>> +
>>>> + /* Allocate space for report data */
>>>> + report_buf = kmalloc(TDX_REPORT_DATA_LEN, GFP_KERNEL);
>>>> + if (!report_buf)
>>>> + return -ENOMEM;
>>>> +
>>>> + /*
>>>> + * Allocate space for TDREPORT buffer (1024-byte aligned).
>>>> + * Full page alignment is more than enough.
>>>> + */
>>>> + tdreport_buf = (void *)get_zeroed_page(GFP_KERNEL);
>>>
>>> Maybe we should add BUILD_BUG_ON(TDX_TDREPORT_LEN > PAGE_SIZE)
>>
>> Currently, it is a constant value < PAGE_SIZE. But I can add the
>> BUILD_BUG_ON check for it.
>
> That's kinda silly. If it might ever be bigger than a page, you just do:
>
> tdreport_buf = alloc_pages();
>
> But, seriously, TDX_TDREPORT_LEN is part of the ABI and can't change.
> kmalloc() would work too since TDX_TDREPORT_LEN is a power of 2.
Agree. For our current requirement, kmalloc will just work fine. If the
length changes in the future, I can start using alloc_pages.
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
^ permalink raw reply [flat|nested] 28+ messages in thread