From: Borislav Petkov <bp@alien8.de>
To: Brijesh Singh <brijesh.singh@amd.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, linux-efi@vger.kernel.org,
platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev,
linux-mm@kvack.org, linux-crypto@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Joerg Roedel <jroedel@suse.de>,
Tom Lendacky <thomas.lendacky@amd.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Ard Biesheuvel <ardb@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>,
Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Sergio Lopez <slp@redhat.com>, Peter Gonda <pgonda@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
David Rientjes <rientjes@google.com>,
tony.luck@intel.com, npmccallum@redhat.com
Subject: Re: [PATCH Part1 RFC v3 22/22] virt: Add SEV-SNP guest driver
Date: Wed, 30 Jun 2021 15:35:35 +0200 [thread overview]
Message-ID: <YNxzJ2I3ZumTELLb@zn.tnic> (raw)
In-Reply-To: <20210602140416.23573-23-brijesh.singh@amd.com>
On Wed, Jun 02, 2021 at 09:04:16AM -0500, Brijesh Singh wrote:
> SEV-SNP specification provides the guest a mechanism to communicate with
> the PSP without risk from a malicious hypervisor who wishes to read, alter,
> drop or replay the messages sent. The driver uses snp_issue_guest_request()
> to issue GHCB SNP_GUEST_REQUEST NAE event. This command constructs a
> trusted channel between the guest and the PSP firmware.
>
> The userspace can use the following ioctls provided by the driver:
>
> 1. Request an attestation report that can be used to assume the identity
> and security configuration of the guest.
> 2. Ask the firmware to provide a key derived from a root key.
>
> See SEV-SNP spec section Guest Messages for more details.
>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> drivers/virt/Kconfig | 3 +
> drivers/virt/Makefile | 1 +
> drivers/virt/sevguest/Kconfig | 10 +
> drivers/virt/sevguest/Makefile | 4 +
> drivers/virt/sevguest/snp.c | 448 +++++++++++++++++++++++++++++++++
> drivers/virt/sevguest/snp.h | 63 +++++
> include/uapi/linux/sev-guest.h | 56 +++++
> 7 files changed, 585 insertions(+)
> create mode 100644 drivers/virt/sevguest/Kconfig
> create mode 100644 drivers/virt/sevguest/Makefile
> create mode 100644 drivers/virt/sevguest/snp.c
> create mode 100644 drivers/virt/sevguest/snp.h
> create mode 100644 include/uapi/linux/sev-guest.h
Seeing how there are a bunch of such driver things for SEV stuff, I'd
say to put it under:
drivers/virt/coco/
where we can collect all those confidential computing supporting
drivers.
>
> diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
> index 8061e8ef449f..4de714c5ee9a 100644
> --- a/drivers/virt/Kconfig
> +++ b/drivers/virt/Kconfig
> @@ -36,4 +36,7 @@ source "drivers/virt/vboxguest/Kconfig"
> source "drivers/virt/nitro_enclaves/Kconfig"
>
> source "drivers/virt/acrn/Kconfig"
> +
> +source "drivers/virt/sevguest/Kconfig"
> +
> endif
> diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
> index 3e272ea60cd9..b2d1a8131c90 100644
> --- a/drivers/virt/Makefile
> +++ b/drivers/virt/Makefile
> @@ -8,3 +8,4 @@ obj-y += vboxguest/
>
> obj-$(CONFIG_NITRO_ENCLAVES) += nitro_enclaves/
> obj-$(CONFIG_ACRN_HSM) += acrn/
> +obj-$(CONFIG_SEV_GUEST) += sevguest/
> diff --git a/drivers/virt/sevguest/Kconfig b/drivers/virt/sevguest/Kconfig
> new file mode 100644
> index 000000000000..e88a85527bf6
> --- /dev/null
> +++ b/drivers/virt/sevguest/Kconfig
> @@ -0,0 +1,10 @@
> +config SEV_GUEST
> + tristate "AMD SEV Guest driver"
> + default y
> + depends on AMD_MEM_ENCRYPT
> + help
> + Provides AMD SNP guest request driver. The driver can be used by the
s/Provides AMD SNP guest request driver. //
> + guest to communicate with the hypervisor to request the attestation report
to communicate with the PSP, I thought, not the hypervisor?
> + and more.
> +
> + If you choose 'M' here, this module will be called sevguest.
> diff --git a/drivers/virt/sevguest/Makefile b/drivers/virt/sevguest/Makefile
> new file mode 100644
> index 000000000000..1505df437682
> --- /dev/null
> +++ b/drivers/virt/sevguest/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +sevguest-y := snp.o
What's that for?
Why isn't the filename simply called:
drivers/virt/coco/sevguest.c
?
Or is more coming?
And below there's
.name = "snp-guest",
so you need to get the naming in order here.
> +obj-$(CONFIG_SEV_GUEST) += sevguest.o
> diff --git a/drivers/virt/sevguest/snp.c b/drivers/virt/sevguest/snp.c
> new file mode 100644
> index 000000000000..00d8e8fddf2c
> --- /dev/null
> +++ b/drivers/virt/sevguest/snp.c
> @@ -0,0 +1,448 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * AMD Secure Encrypted Virtualization Nested Paging (SEV-SNP) guest request interface
> + *
> + * Copyright (C) 2021 Advanced Micro Devices, Inc.
> + *
> + * Author: Brijesh Singh <brijesh.singh@amd.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/types.h>
> +#include <linux/mutex.h>
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/miscdevice.h>
> +#include <linux/set_memory.h>
> +#include <linux/fs.h>
> +#include <crypto/aead.h>
> +#include <linux/scatterlist.h>
> +#include <linux/sev-guest.h>
> +#include <uapi/linux/sev-guest.h>
> +
> +#include "snp.h"
> +
> +#define DEVICE_NAME "sev-guest"
> +#define AAD_LEN 48
> +#define MSG_HDR_VER 1
> +
> +struct snp_guest_crypto {
> + struct crypto_aead *tfm;
> + uint8_t *iv, *authtag;
> + int iv_len, a_len;
> +};
> +
> +struct snp_guest_dev {
> + struct device *dev;
> + struct miscdevice misc;
> +
> + struct snp_guest_crypto *crypto;
> + struct snp_guest_msg *request, *response;
> +};
> +
> +static DEFINE_MUTEX(snp_cmd_mutex);
> +
> +static inline struct snp_guest_dev *to_snp_dev(struct file *file)
> +{
> + struct miscdevice *dev = file->private_data;
> +
> + return container_of(dev, struct snp_guest_dev, misc);
> +}
> +
> +static struct snp_guest_crypto *init_crypto(struct snp_guest_dev *snp_dev, uint8_t *key,
> + size_t keylen)
> +{
> + struct snp_guest_crypto *crypto;
> +
> + crypto = kzalloc(sizeof(*crypto), GFP_KERNEL_ACCOUNT);
> + if (!crypto)
> + return NULL;
> +
> + crypto->tfm = crypto_alloc_aead("gcm(aes)", 0, 0);
I know that it is hard to unselect CONFIG_CRYPTO_AEAD2 which provides
this but you better depend on it in the Makefile so that some random
config still builds.
> + if (IS_ERR(crypto->tfm))
> + goto e_free;
> +
> + if (crypto_aead_setkey(crypto->tfm, key, keylen))
> + goto e_free_crypto;
> +
> + crypto->iv_len = crypto_aead_ivsize(crypto->tfm);
> + if (crypto->iv_len < 12) {
> + dev_err(snp_dev->dev, "IV length is less than 12.\n");
> + goto e_free_crypto;
> + }
> +
> + crypto->iv = kmalloc(crypto->iv_len, GFP_KERNEL_ACCOUNT);
> + if (!crypto->iv)
> + goto e_free_crypto;
> +
> + if (crypto_aead_authsize(crypto->tfm) > MAX_AUTHTAG_LEN) {
> + if (crypto_aead_setauthsize(crypto->tfm, MAX_AUTHTAG_LEN)) {
> + dev_err(snp_dev->dev, "failed to set authsize to %d\n", MAX_AUTHTAG_LEN);
> + goto e_free_crypto;
> + }
> + }
> +
> + crypto->a_len = crypto_aead_authsize(crypto->tfm);
> + crypto->authtag = kmalloc(crypto->a_len, GFP_KERNEL_ACCOUNT);
> + if (!crypto->authtag)
> + goto e_free_crypto;
> +
> + return crypto;
> +
> +e_free_crypto:
> + crypto_free_aead(crypto->tfm);
> +e_free:
> + kfree(crypto->iv);
> + kfree(crypto->authtag);
> + kfree(crypto);
> +
> + return NULL;
> +}
...
> +static int handle_guest_request(struct snp_guest_dev *snp_dev, int msg_type,
> + struct snp_user_guest_request *input, void *req_buf,
> + size_t req_len, void __user *resp_buf, size_t resp_len)
> +{
> + struct snp_guest_crypto *crypto = snp_dev->crypto;
> + struct page *page;
> + size_t msg_len;
> + int ret;
> +
> + /* Allocate the buffer to hold response */
> + resp_len += crypto->a_len;
> + page = alloc_pages(GFP_KERNEL_ACCOUNT, get_order(resp_len));
> + if (!page)
> + return -ENOMEM;
> +
> + ret = __handle_guest_request(snp_dev, msg_type, input, req_buf, req_len,
> + page_address(page), resp_len, &msg_len);
Align arguments on the opening brace.
Check the whole patch too for other similar cases.
> + if (ret)
> + goto e_free;
> +
> + if (copy_to_user(resp_buf, page_address(page), msg_len))
> + ret = -EFAULT;
> +
> +e_free:
> + __free_pages(page, get_order(resp_len));
> +
> + return ret;
> +}
> +
> +static int get_report(struct snp_guest_dev *snp_dev, struct snp_user_guest_request *input)
> +{
> + struct snp_user_report __user *report = (struct snp_user_report *)input->data;
> + struct snp_user_report_req req;
> +
> + if (copy_from_user(&req, &report->req, sizeof(req)))
What guarantees that that __user report thing is valid and is not going
to trick the kernel into doing a NULL pointer access in the ->req access
here?
IOW, you need to verify all your user data being passed through before
using it.
> + return -EFAULT;
> +
> + return handle_guest_request(snp_dev, SNP_MSG_REPORT_REQ, input, &req.user_data,
> + sizeof(req.user_data), report->response, sizeof(report->response));
> +}
> +
> +static int derive_key(struct snp_guest_dev *snp_dev, struct snp_user_guest_request *input)
> +{
> + struct snp_user_derive_key __user *key = (struct snp_user_derive_key *)input->data;
> + struct snp_user_derive_key_req req;
> +
> + if (copy_from_user(&req, &key->req, sizeof(req)))
> + return -EFAULT;
> +
> + return handle_guest_request(snp_dev, SNP_MSG_KEY_REQ, input, &req, sizeof(req),
> + key->response, sizeof(key->response));
> +}
> +
> +static long snp_guest_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
> +{
> + struct snp_guest_dev *snp_dev = to_snp_dev(file);
> + struct snp_user_guest_request input;
> + void __user *argp = (void __user *)arg;
> + int ret = -ENOTTY;
> +
> + if (copy_from_user(&input, argp, sizeof(input)))
> + return -EFAULT;
> +
> + mutex_lock(&snp_cmd_mutex);
> + switch (ioctl) {
> + case SNP_GET_REPORT: {
> + ret = get_report(snp_dev, &input);
> + break;
> + }
> + case SNP_DERIVE_KEY: {
> + ret = derive_key(snp_dev, &input);
> + break;
> + }
> + default:
> + break;
> + }
If only two ioctls, you don't need the switch-case thing.
> +
> + mutex_unlock(&snp_cmd_mutex);
> +
> + if (copy_to_user(argp, &input, sizeof(input)))
> + return -EFAULT;
> +
> + return ret;
> +}
...
> diff --git a/include/uapi/linux/sev-guest.h b/include/uapi/linux/sev-guest.h
> new file mode 100644
> index 000000000000..0a8454631605
> --- /dev/null
> +++ b/include/uapi/linux/sev-guest.h
> @@ -0,0 +1,56 @@
> +/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */
> +/*
> + * Userspace interface for AMD SEV and SEV-SNP guest driver.
> + *
> + * Copyright (C) 2021 Advanced Micro Devices, Inc.
> + *
> + * Author: Brijesh Singh <brijesh.singh@amd.com>
> + *
> + * SEV-SNP API specification is available at: https://developer.amd.com/sev/
> + */
> +
> +#ifndef __UAPI_LINUX_SEV_GUEST_H_
> +#define __UAPI_LINUX_SEV_GUEST_H_
> +
> +#include <linux/types.h>
> +
> +struct snp_user_report_req {
> + __u8 user_data[64];
> +};
> +
> +struct snp_user_report {
> + struct snp_user_report_req req;
> +
> + /* see SEV-SNP spec for the response format */
> + __u8 response[4000];
> +};
> +
> +struct snp_user_derive_key_req {
> + __u8 root_key_select;
> + __u64 guest_field_select;
> + __u32 vmpl;
> + __u32 guest_svn;
> + __u64 tcb_version;
> +};
> +
> +struct snp_user_derive_key {
> + struct snp_user_derive_key_req req;
> +
> + /* see SEV-SNP spec for the response format */
> + __u8 response[64];
> +};
> +
> +struct snp_user_guest_request {
> + /* Message version number (must be non-zero) */
> + __u8 msg_version;
> + __u64 data;
> +
> + /* firmware error code on failure (see psp-sev.h) */
> + __u32 fw_err;
> +};
All those struct names have a "snp_user" prefix. It seems to me that
that "user" is superfluous.
> +
> +#define SNP_GUEST_REQ_IOC_TYPE 'S'
> +#define SNP_GET_REPORT _IOWR(SNP_GUEST_REQ_IOC_TYPE, 0x0, struct snp_user_guest_request)
> +#define SNP_DERIVE_KEY _IOWR(SNP_GUEST_REQ_IOC_TYPE, 0x1, struct snp_user_guest_request)
Where are those ioctls documented so that userspace can know how to use
them?
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-06-30 13:35 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-02 14:03 [PATCH Part1 RFC v3 00/22] Add AMD Secure Nested Paging (SEV-SNP) Guest Support Brijesh Singh
2021-06-02 14:03 ` [PATCH Part1 RFC v3 01/22] x86/sev: shorten GHCB terminate macro names Brijesh Singh
2021-06-08 15:54 ` Venu Busireddy
2021-06-02 14:03 ` [PATCH Part1 RFC v3 02/22] x86/sev: Define the Linux specific guest termination reasons Brijesh Singh
2021-06-08 15:59 ` Venu Busireddy
2021-06-08 16:51 ` Brijesh Singh
2021-06-02 14:03 ` [PATCH Part1 RFC v3 03/22] x86/sev: Save the negotiated GHCB version Brijesh Singh
2021-06-03 19:57 ` Borislav Petkov
2021-06-08 17:35 ` Venu Busireddy
2021-06-02 14:03 ` [PATCH Part1 RFC v3 04/22] x86/mm: Add sev_feature_enabled() helper Brijesh Singh
2021-06-05 10:50 ` Borislav Petkov
2021-06-02 14:03 ` [PATCH Part1 RFC v3 05/22] x86/sev: Add support for hypervisor feature VMGEXIT Brijesh Singh
2021-06-07 14:19 ` Borislav Petkov
2021-06-07 14:58 ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 06/22] x86/sev: check SEV-SNP features support Brijesh Singh
2021-06-07 14:54 ` Borislav Petkov
2021-06-07 16:01 ` Brijesh Singh
2021-06-17 18:46 ` Brijesh Singh
2021-06-18 5:46 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 07/22] x86/sev: Add a helper for the PVALIDATE instruction Brijesh Singh
2021-06-07 15:35 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 08/22] x86/compressed: Add helper for validating pages in the decompression stage Brijesh Singh
2021-06-08 11:12 ` Borislav Petkov
2021-06-08 15:58 ` Brijesh Singh
2021-06-16 10:21 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 09/22] x86/compressed: Register GHCB memory when SEV-SNP is active Brijesh Singh
2021-06-09 17:47 ` Borislav Petkov
2021-06-14 12:28 ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 10/22] x86/sev: " Brijesh Singh
2021-06-10 5:49 ` Borislav Petkov
2021-06-14 12:29 ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 11/22] x86/sev: Add helper for validating pages in early enc attribute changes Brijesh Singh
2021-06-10 15:50 ` Borislav Petkov
2021-06-14 12:45 ` Brijesh Singh
2021-06-14 19:03 ` Borislav Petkov
2021-06-14 21:01 ` Brijesh Singh
2021-06-16 10:07 ` Borislav Petkov
2021-06-16 11:00 ` Brijesh Singh
2021-06-16 12:03 ` Borislav Petkov
2021-06-16 12:49 ` Brijesh Singh
2021-06-16 13:02 ` Borislav Petkov
2021-06-16 13:10 ` Brijesh Singh
2021-06-16 14:36 ` Brijesh Singh
2021-06-16 14:37 ` Brijesh Singh
2021-06-16 13:06 ` Dr. David Alan Gilbert
2021-06-02 14:04 ` [PATCH Part1 RFC v3 12/22] x86/kernel: Make the bss.decrypted section shared in RMP table Brijesh Singh
2021-06-10 16:06 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 13/22] x86/kernel: Validate rom memory before accessing when SEV-SNP is active Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 14/22] x86/mm: Add support to validate memory when changing C-bit Brijesh Singh
2021-06-11 9:44 ` Borislav Petkov
2021-06-14 13:05 ` Brijesh Singh
2021-06-14 19:27 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 15/22] KVM: SVM: define new SEV_FEATURES field in the VMCB Save State Area Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 16/22] KVM: SVM: Create a separate mapping for the SEV-ES save area Brijesh Singh
2021-06-14 10:58 ` Borislav Petkov
2021-06-14 19:34 ` Tom Lendacky
2021-06-14 19:50 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 17/22] KVM: SVM: Create a separate mapping for the GHCB " Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 18/22] KVM: SVM: Update the SEV-ES save area mapping Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 19/22] x86/sev-snp: SEV-SNP AP creation support Brijesh Singh
2021-06-16 13:07 ` Borislav Petkov
2021-06-16 16:13 ` Tom Lendacky
2021-06-02 14:04 ` [PATCH Part1 RFC v3 20/22] x86/boot: Add Confidential Computing address to setup_header Brijesh Singh
2021-06-18 6:08 ` Borislav Petkov
2021-06-18 13:57 ` Brijesh Singh
2021-06-18 15:05 ` Borislav Petkov
2021-06-23 4:30 ` Michael Roth
2021-06-23 10:22 ` Borislav Petkov
2021-06-24 3:19 ` Michael Roth
2021-06-24 7:27 ` Borislav Petkov
2021-06-24 12:26 ` Michael Roth
2021-06-24 12:34 ` Michael Roth
2021-06-24 12:54 ` Borislav Petkov
2021-06-24 14:11 ` Michael Roth
2021-06-25 14:48 ` Borislav Petkov
2021-06-25 15:24 ` Brijesh Singh
2021-06-25 17:01 ` Borislav Petkov
2021-06-25 18:14 ` Michael Roth
2021-06-28 13:43 ` Borislav Petkov
2021-06-24 13:09 ` Kuppuswamy, Sathyanarayanan
2021-06-02 14:04 ` [PATCH Part1 RFC v3 21/22] x86/sev: Register SNP guest request platform device Brijesh Singh
2021-06-04 11:28 ` Sergio Lopez
2021-06-09 19:24 ` Dr. David Alan Gilbert
2021-06-11 13:16 ` Tom Lendacky
2021-06-14 17:15 ` Dr. David Alan Gilbert
2021-06-14 18:24 ` Brijesh Singh
2021-06-14 13:20 ` Brijesh Singh
2021-06-14 17:23 ` Dr. David Alan Gilbert
2021-06-14 20:50 ` Brijesh Singh
2021-06-18 9:46 ` Borislav Petkov
2021-06-18 13:59 ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 22/22] virt: Add SEV-SNP guest driver Brijesh Singh
2021-06-30 13:35 ` Borislav Petkov [this message]
2021-06-30 16:26 ` Brijesh Singh
2021-07-01 18:03 ` Borislav Petkov
2021-07-01 21:32 ` Brijesh Singh
2021-07-03 16:19 ` Borislav Petkov
2021-07-05 10:39 ` Brijesh Singh
2021-06-07 19:15 ` [PATCH Part1 RFC v3 00/22] Add AMD Secure Nested Paging (SEV-SNP) Guest Support Venu Busireddy
2021-06-07 19:17 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YNxzJ2I3ZumTELLb@zn.tnic \
--to=bp@alien8.de \
--cc=ardb@kernel.org \
--cc=brijesh.singh@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=jroedel@suse.de \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=npmccallum@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=pgonda@google.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rientjes@google.com \
--cc=seanjc@google.com \
--cc=slp@redhat.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tony.luck@intel.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).