| Message ID | 20211110220731.2396491-45-brijesh.singh@amd.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Add AMD Secure Nested Paging (SEV-SNP) Guest Support | expand |
On Wed, Nov 10, 2021 at 3:09 PM Brijesh Singh <brijesh.singh@amd.com> 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 choose, such as a > sealing key or communicating with the external entities. > > See SEV-SNP firmware spec for more information. > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > --- > Documentation/virt/coco/sevguest.rst | 19 ++++++++++- > drivers/virt/coco/sevguest/sevguest.c | 49 +++++++++++++++++++++++++++ > include/uapi/linux/sev-guest.h | 24 +++++++++++++ > 3 files changed, 91 insertions(+), 1 deletion(-) > > diff --git a/Documentation/virt/coco/sevguest.rst b/Documentation/virt/coco/sevguest.rst > index 002c90946b8a..0bd9a65e0370 100644 > --- a/Documentation/virt/coco/sevguest.rst > +++ b/Documentation/virt/coco/sevguest.rst > @@ -64,10 +64,27 @@ The SNP_GET_REPORT ioctl can be used to query the attestation report from the > SEV-SNP firmware. The ioctl uses the SNP_GUEST_REQUEST (MSG_REPORT_REQ) command > provided by the SEV-SNP firmware to query the attestation report. > > -On success, the snp_report_resp.data will contains the report. The report > +On success, the snp_report_resp.data will contain the report. The report > will 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_req on success, -negative on error > + > +The SNP_GET_DERIVED_KEY ioctl can be used to get a key derive from a root key. derived > +The derived key can be used by the guest for any purpose, such as sealing keys > +or communicating with external entities. > + > +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 will contains the derived key value. See ".data will contain the..." or ".data contains the derived key..." > +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 982714c1b4ca..bece6856573e 100644 > --- a/drivers/virt/coco/sevguest/sevguest.c > +++ b/drivers/virt/coco/sevguest/sevguest.c > @@ -392,6 +392,52 @@ 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; > + int rc, resp_len; > + u8 buf[89]; Could we document this magic number? > + > + 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; > + > + /* Message version must be non-zero */ > + if (!req.msg_version) > + return -EINVAL; > + > + /* > + * 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, req.msg_version, > + SNP_MSG_KEY_REQ, &req.data, sizeof(req.data), buf, resp_len, > + &arg->fw_err); > + if (rc) > + goto e_free; Should we check the first 32 bits of |data| here since that is a status field? If we see 16h here we could return -EINVAL, or better to let userspace deal with that error handling? > + > + /* 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); > @@ -417,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 eda7edcffda8..f6d9c136ff4d 100644 > --- a/include/uapi/linux/sev-guest.h > +++ b/include/uapi/linux/sev-guest.h > @@ -36,9 +36,33 @@ struct snp_guest_request_ioctl { > __u64 fw_err; > }; > > +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_req { > + /* message version number (must be non-zero) */ > + __u8 msg_version; > + > + struct __snp_derived_key_req data; > +}; > + > +struct snp_derived_key_resp { > + /* response data, see SEV-SNP spec for the format */ > + __u8 data[64]; > +}; > + > #define SNP_GUEST_REQ_IOC_TYPE 'S' > > /* 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 >
On 11/18/21 10:43 AM, Peter Gonda wrote: ... >> + u8 buf[89]; > > Could we document this magic number? > Yes, I will document from where this number came. >> + >> + 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; >> + >> + /* Message version must be non-zero */ >> + if (!req.msg_version) >> + return -EINVAL; >> + >> + /* >> + * 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, req.msg_version, >> + SNP_MSG_KEY_REQ, &req.data, sizeof(req.data), buf, resp_len, >> + &arg->fw_err); >> + if (rc) >> + goto e_free; > > Should we check the first 32 bits of |data| here since that is a > status field? If we see 16h here we could return -EINVAL, or better to > let userspace deal with that error handling? > I was trying to avoid looking into a response structure to keep the flexibility; e.g if SNP firmware changes a response format then we don't need to have any changes in the driver. The userspace should be able to deal with it and it can check the "status" or a new field etc. thanks
diff --git a/Documentation/virt/coco/sevguest.rst b/Documentation/virt/coco/sevguest.rst index 002c90946b8a..0bd9a65e0370 100644 --- a/Documentation/virt/coco/sevguest.rst +++ b/Documentation/virt/coco/sevguest.rst @@ -64,10 +64,27 @@ The SNP_GET_REPORT ioctl can be used to query the attestation report from the SEV-SNP firmware. The ioctl uses the SNP_GUEST_REQUEST (MSG_REPORT_REQ) command provided by the SEV-SNP firmware to query the attestation report. -On success, the snp_report_resp.data will contains the report. The report +On success, the snp_report_resp.data will contain the report. The report will 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_req on success, -negative on error + +The SNP_GET_DERIVED_KEY ioctl can be used to get a key derive from a root key. +The derived key can be used by the guest for any purpose, such as sealing keys +or communicating with external entities. + +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 will 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 982714c1b4ca..bece6856573e 100644 --- a/drivers/virt/coco/sevguest/sevguest.c +++ b/drivers/virt/coco/sevguest/sevguest.c @@ -392,6 +392,52 @@ 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; + int rc, resp_len; + u8 buf[89]; + + 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; + + /* Message version must be non-zero */ + if (!req.msg_version) + return -EINVAL; + + /* + * 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, req.msg_version, + SNP_MSG_KEY_REQ, &req.data, sizeof(req.data), 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); @@ -417,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 eda7edcffda8..f6d9c136ff4d 100644 --- a/include/uapi/linux/sev-guest.h +++ b/include/uapi/linux/sev-guest.h @@ -36,9 +36,33 @@ struct snp_guest_request_ioctl { __u64 fw_err; }; +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_req { + /* message version number (must be non-zero) */ + __u8 msg_version; + + struct __snp_derived_key_req data; +}; + +struct snp_derived_key_resp { + /* response data, see SEV-SNP spec for the format */ + __u8 data[64]; +}; + #define SNP_GUEST_REQ_IOC_TYPE 'S' /* 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_ */
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 choose, such as a sealing key or communicating with the external entities. See SEV-SNP firmware spec for more information. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> --- Documentation/virt/coco/sevguest.rst | 19 ++++++++++- drivers/virt/coco/sevguest/sevguest.c | 49 +++++++++++++++++++++++++++ include/uapi/linux/sev-guest.h | 24 +++++++++++++ 3 files changed, 91 insertions(+), 1 deletion(-)