From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 586C7C433F5 for ; Tue, 1 Feb 2022 20:39:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC16D8D0089; Tue, 1 Feb 2022 15:39:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D6DB38D006D; Tue, 1 Feb 2022 15:39:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C35EE8D0089; Tue, 1 Feb 2022 15:39:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id B55B08D006D for ; Tue, 1 Feb 2022 15:39:41 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7018A80DE37F for ; Tue, 1 Feb 2022 20:39:41 +0000 (UTC) X-FDA: 79095376962.12.E97EC8B Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf29.hostedemail.com (Postfix) with ESMTP id 24A08120004 for ; Tue, 1 Feb 2022 20:39:40 +0000 (UTC) Received: by mail-lj1-f170.google.com with SMTP id e17so25852488ljk.5 for ; Tue, 01 Feb 2022 12:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CCHRlnNYeF95Z0E47QMIOcWFuVuKdPbhrfyvVDY/gqE=; b=MXDhzlA/b4G0ig7K6rclUU3oFoycV4wfrA/3QQrZCzuP+ttoHw4Bxm4G81iw1INDFN r7R2Kcga3uKko9XYj8F7TDykqLDIgMiSLy25AeE7UFgHfozMn8YLGuIaxYD0pCjDiQNb hWYMvvj15zyQnU5NcJZipSrluZeUR82fdDnZ7f6TV3eRq1XG1vGwIec59TGu+zDsQ/0C CgtsZC5Derge+uNFYv0nHex+jsnb3KLMo6BNaf16VRHehk68wbW1JL8pZ3DzVJWSf4xI k5whar2GAfdItMDRQZfNjsClnweO6EXT7aAe2oZrHe2Suspg6kt+SogsQ825Ps6iSRWx zEkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CCHRlnNYeF95Z0E47QMIOcWFuVuKdPbhrfyvVDY/gqE=; b=0clm1euv9F76M34XCItg3HSWMZ/mnaUzlB5lBwR1CBsQTJ2M3e15NYm0bvTpNq3CUV jQNlKGRzLYu+Q5SwJi3YHRx9J5eud3ER/rijsFtsH9irby+UAg1LiaraeFjXjXjsUa5K GaKbKI7nzfQbWPPFIDLXi3fn1BFs0prGpv8gEowxbIMZ04m/Ip7Fj0TcFvIELUGfmSjQ kjm8XW6AOSHvfkeCaGFJJr1c3Nvs4I9CK78SdBHhs6EZ557FCTWFIsRgR7W9yFzYNI5N nSDDkkxIHQ1lMJqu2VBzXS6OyBBYe0lsat1r4x0Gtcw4pk/mJDFHugxy53+FbmAfwPzM LKrg== X-Gm-Message-State: AOAM5320hiVMI/eDp3KIe9FU3TJrvPUEl4DcOJSkpVwGd1rm64sYuJWw c+uN4tcKSACWBXyJEJLX3o8i0k6PUajXv93AsowlEw== X-Google-Smtp-Source: ABdhPJz3tdzw9oSrD2hKDXB+1mXZIyEnyffVNF8qPwJHccVAns3fQrSH2hPsPAIgwyf+fex4mAbmF0sJBtpDyR1gxY8= X-Received: by 2002:a2e:a4a9:: with SMTP id g9mr17830908ljm.369.1643747979115; Tue, 01 Feb 2022 12:39:39 -0800 (PST) MIME-Version: 1.0 References: <20220128171804.569796-1-brijesh.singh@amd.com> <20220128171804.569796-43-brijesh.singh@amd.com> In-Reply-To: <20220128171804.569796-43-brijesh.singh@amd.com> From: Peter Gonda Date: Tue, 1 Feb 2022 13:39:27 -0700 Message-ID: Subject: Re: [PATCH v9 42/43] virt: sevguest: Add support to derive key To: Brijesh Singh Cc: "the arch/x86 maintainers" , LKML , kvm list , linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , "Dr . David Alan Gilbert" , brijesh.ksingh@gmail.com, Tony Luck , Marc Orr , Sathyanarayanan Kuppuswamy , Liam Merwick Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 24A08120004 X-Stat-Signature: hgyasjxwjer6dr6h5gwirdqniyicio3x X-Rspam-User: nil Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="MXDhzlA/"; spf=pass (imf29.hostedemail.com: domain of pgonda@google.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=pgonda@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1643747980-49684 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jan 28, 2022 at 10:19 AM Brijesh Singh wrote: > > The SNP_GET_DERIVED_KEY ioctl interface can be used by the SNP guest to > ask the firmware to provide a key derived from a root key. The derived > key may be used by the guest for any purposes it chooses, such as a > sealing key or communicating with the external entities. > > See SEV-SNP firmware spec for more information. > > Reviewed-by: Liam Merwick > Signed-off-by: Brijesh Singh Reviewed-by: Peter Gonda > --- > Documentation/virt/coco/sevguest.rst | 17 ++++++++++ > drivers/virt/coco/sevguest/sevguest.c | 45 +++++++++++++++++++++++++++ > include/uapi/linux/sev-guest.h | 17 ++++++++++ > 3 files changed, 79 insertions(+) > > diff --git a/Documentation/virt/coco/sevguest.rst b/Documentation/virt/coco/sevguest.rst > index 47ef3b0821d5..aafc9bce9aef 100644 > --- a/Documentation/virt/coco/sevguest.rst > +++ b/Documentation/virt/coco/sevguest.rst > @@ -72,6 +72,23 @@ On success, the snp_report_resp.data will contains the report. The report > contain the format described in the SEV-SNP specification. See the SEV-SNP > specification for further details. > > +2.2 SNP_GET_DERIVED_KEY > +----------------------- > +:Technology: sev-snp > +:Type: guest ioctl > +:Parameters (in): struct snp_derived_key_req > +:Returns (out): struct snp_derived_key_resp on success, -negative on error > + > +The SNP_GET_DERIVED_KEY ioctl can be used to get a key derive from a root key. derived from ... > +The derived key can be used by the guest for any purpose, such as sealing keys > +or communicating with external entities. Question: How would this be used to communicate with external entities? Reading Section 7.2 it seems like we could pick the VCEK and have no guest specific inputs and we'd get the same derived key as we would on another guest on the same platform with, is that correct? > + > +The ioctl uses the SNP_GUEST_REQUEST (MSG_KEY_REQ) command provided by the > +SEV-SNP firmware to derive the key. See SEV-SNP specification for further details > +on the various fields passed in the key derivation request. > + > +On success, the snp_derived_key_resp.data contains the derived key value. See > +the SEV-SNP specification for further details. > > Reference > --------- > diff --git a/drivers/virt/coco/sevguest/sevguest.c b/drivers/virt/coco/sevguest/sevguest.c > index 6dc0785ddd4b..4369e55df9a6 100644 > --- a/drivers/virt/coco/sevguest/sevguest.c > +++ b/drivers/virt/coco/sevguest/sevguest.c > @@ -392,6 +392,48 @@ static int get_report(struct snp_guest_dev *snp_dev, struct snp_guest_request_io > return rc; > } > > +static int get_derived_key(struct snp_guest_dev *snp_dev, struct snp_guest_request_ioctl *arg) > +{ > + struct snp_guest_crypto *crypto = snp_dev->crypto; > + struct snp_derived_key_resp resp = {0}; > + struct snp_derived_key_req req = {0}; > + int rc, resp_len; > + u8 buf[64+16]; /* Response data is 64 bytes and max authsize for GCM is 16 bytes */ > + > + if (!arg->req_data || !arg->resp_data) > + return -EINVAL; > + > + /* Copy the request payload from userspace */ > + if (copy_from_user(&req, (void __user *)arg->req_data, sizeof(req))) > + return -EFAULT; > + > + /* > + * The intermediate response buffer is used while decrypting the > + * response payload. Make sure that it has enough space to cover the > + * authtag. > + */ > + resp_len = sizeof(resp.data) + crypto->a_len; > + if (sizeof(buf) < resp_len) > + return -ENOMEM; > + > + /* Issue the command to get the attestation report */ > + rc = handle_guest_request(snp_dev, SVM_VMGEXIT_GUEST_REQUEST, arg->msg_version, > + SNP_MSG_KEY_REQ, &req, sizeof(req), buf, resp_len, > + &arg->fw_err); > + if (rc) > + goto e_free; > + > + /* Copy the response payload to userspace */ > + memcpy(resp.data, buf, sizeof(resp.data)); > + if (copy_to_user((void __user *)arg->resp_data, &resp, sizeof(resp))) > + rc = -EFAULT; > + > +e_free: > + memzero_explicit(buf, sizeof(buf)); > + memzero_explicit(&resp, sizeof(resp)); > + return rc; > +} > + > static long snp_guest_ioctl(struct file *file, unsigned int ioctl, unsigned long arg) > { > struct snp_guest_dev *snp_dev = to_snp_dev(file); > @@ -421,6 +463,9 @@ static long snp_guest_ioctl(struct file *file, unsigned int ioctl, unsigned long > case SNP_GET_REPORT: > ret = get_report(snp_dev, &input); > break; > + case SNP_GET_DERIVED_KEY: > + ret = get_derived_key(snp_dev, &input); > + break; > default: > break; > } > diff --git a/include/uapi/linux/sev-guest.h b/include/uapi/linux/sev-guest.h > index 081d314a6279..bcd00a6d4501 100644 > --- a/include/uapi/linux/sev-guest.h > +++ b/include/uapi/linux/sev-guest.h > @@ -30,6 +30,20 @@ struct snp_report_resp { > __u8 data[4000]; > }; > > +struct snp_derived_key_req { > + __u32 root_key_select; > + __u32 rsvd; > + __u64 guest_field_select; > + __u32 vmpl; > + __u32 guest_svn; > + __u64 tcb_version; > +}; > + > +struct snp_derived_key_resp { > + /* response data, see SEV-SNP spec for the format */ > + __u8 data[64]; > +}; > + > struct snp_guest_request_ioctl { > /* message version number (must be non-zero) */ > __u8 msg_version; > @@ -47,4 +61,7 @@ struct snp_guest_request_ioctl { > /* Get SNP attestation report */ > #define SNP_GET_REPORT _IOWR(SNP_GUEST_REQ_IOC_TYPE, 0x0, struct snp_guest_request_ioctl) > > +/* Get a derived key from the root */ > +#define SNP_GET_DERIVED_KEY _IOWR(SNP_GUEST_REQ_IOC_TYPE, 0x1, struct snp_guest_request_ioctl) > + > #endif /* __UAPI_LINUX_SEV_GUEST_H_ */ > -- > 2.25.1 >