2022-11-02 15:30:37

by Dionna Amalie Glaze

[permalink] [raw]
Subject: [PATCH v5 0/4] Add throttling detection to sev-guest

The guest request synchronous API from SEV-SNP VMs to the host's security
processor consumes a global resource. For this reason, AMD's docs
recommend that the host implements a throttling mechanism. In order for
the guest to know it's been throttled and should try its request again,
we need some good-faith communication from the host that the request
has been throttled.

These patches work with the existing /dev/sev-guest ABI to detect a
throttling code.

Changes from v4:
* Clarified comment on SEV_RET_NO_FW_CALL
* Changed ratelimit loop to use sleep_timeout_interruptible
Changes from v3:
* sev-guest ratelimits itself to one request twice a second.
* Fixed a type signature to use u64 instead of unsigned int
* Set *exitinfo2 unconditionally after the ghcb_hv_call.
Changes from v2:
* Codified the non-firmware-call firmware error code as (u32)-1.
* Changed sev_issue_guest_request unsigned long *fw_err argument to
u64 *exitinfo2 to more accurately and type-safely describe the
value that it outputs.
* Changed sev_issue_guest_request to always set its exitinfo2
argument to either the non-firmware-call error code, the
EXIT_INFO_2 returned from the VMM if the request failed, or 0 on
success. This fixes a bug that returned uninitialized kernel stack
memory to the user when there is no error.
* Changed the throttle behavior to retry in the driver instead of
returning -EAGAIN, due to possible message sequence number reuse
on different message contents.

Changes from v1:
* Changed throttle error code to 2

Cc: Tom Lendacky <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: Peter Gonda <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Dave Hansen <[email protected]>

Signed-off-by: Dionna Glaze <[email protected]>

Dionna Glaze (4):
ccp: Name -1 return value as SEV_RET_NO_FW_CALL
x86/sev: Change snp_guest_issue_request's fw_err
virt/coco/sev-guest: Remove err in handle_guest_request
virt/coco/sev-guest: interpret VMM errors from guest request

arch/x86/include/asm/sev.h | 4 +-
arch/x86/kernel/sev.c | 10 +++--
drivers/crypto/ccp/sev-dev.c | 2 +-
drivers/virt/coco/sev-guest/sev-guest.c | 57 ++++++++++++++++++++-----
include/uapi/linux/psp-sev.h | 7 +++
include/uapi/linux/sev-guest.h | 18 +++++++-
6 files changed, 78 insertions(+), 20 deletions(-)

--
2.38.1.273.g43a17bfeac-goog



2022-11-02 15:30:37

by Dionna Amalie Glaze

[permalink] [raw]
Subject: [PATCH v5 4/4] virt/coco/sev-guest: interpret VMM errors from guest request

The GHCB specification states that the upper 32 bits of exitinfo2 are
for the VMM's error codes. The sev-guest ABI has already locked in
that the fw_err status of the input will be 64 bits, and that
BIT_ULL(32) means that the extended guest request's data buffer was too
small, so we have to keep that ABI.

We can still interpret the upper 32 bits of exitinfo2 for the user
anyway in case the request gets throttled. For safety, since the
encryption algorithm in GHCBv2 is AES_GCM, we cannot return to user
space without having completed the request with the current sequence
number. If we were to return and the guest were to make another request
but with different message contents, then that would be IV reuse.

When throttled, the driver will reschedule itself and then try
again after sleeping half its ratelimit time to avoid a big wait queue.
The ioctl may block indefinitely, but that has always been the case
when deferring these requests to the host.

Cc: Tom Lendacky <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: Peter Gonda <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Dave Hansen <[email protected]>

Signed-off-by: Dionna Glaze <[email protected]>
---
drivers/virt/coco/sev-guest/sev-guest.c | 50 ++++++++++++++++++++++---
include/uapi/linux/sev-guest.h | 18 ++++++++-
2 files changed, 60 insertions(+), 8 deletions(-)

diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index 0508c2f46f6b..43e110ad4aa9 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -14,6 +14,7 @@
#include <linux/io.h>
#include <linux/platform_device.h>
#include <linux/miscdevice.h>
+#include <linux/ratelimit.h>
#include <linux/set_memory.h>
#include <linux/fs.h>
#include <crypto/aead.h>
@@ -48,12 +49,22 @@ struct snp_guest_dev {
struct snp_req_data input;
u32 *os_area_msg_seqno;
u8 *vmpck;
+
+ struct ratelimit_state rs;
};

static u32 vmpck_id;
module_param(vmpck_id, uint, 0444);
MODULE_PARM_DESC(vmpck_id, "The VMPCK ID to use when communicating with the PSP.");

+static int rate_hz = 2;
+module_param(rate_hz, int, 0444);
+MODULE_PARM_DESC(vmpck_id, "The rate limit frequency to limit requests to.");
+
+static int rate_burst = 1;
+module_param(rate_burst, int, 0444);
+MODULE_PARM_DESC(rate_burst, "The rate limit burst amount to limit requests to.");
+
/* Mutex to serialize the shared buffer access and command handling. */
static DEFINE_MUTEX(snp_cmd_mutex);

@@ -305,6 +316,7 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
u8 type, void *req_buf, size_t req_sz, void *resp_buf,
u32 resp_sz, __u64 *exitinfo2)
{
+ unsigned int vmm_err;
u64 seqno;
int rc;

@@ -320,9 +332,33 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
if (rc)
return rc;

+retry:
+ /*
+ * Rate limit commands internally since the host can also throttle, and
+ * we don't want to create a tight request spin that could end up
+ * getting this VM throttled more heavily.
+ */
+ if (!__ratelimit(&snp_dev->rs)) {
+ sleep_timeout_interruptible((rate_hz * HZ) / 2);
+ goto retry;
+ }
/* Call firmware to process the request */
rc = snp_issue_guest_request(exit_code, &snp_dev->input, exitinfo2);

+ vmm_err = *exitinfo2 >> SNP_GUEST_VMM_ERR_SHIFT;
+ /*
+ * The host may return EBUSY if the request has been throttled.
+ * We retry in the driver to avoid returning and reusing the message
+ * sequence number on a different message.
+ */
+ if (vmm_err == SNP_GUEST_VMM_ERR_BUSY)
+ goto retry;
+
+ if (vmm_err && vmm_err != SNP_GUEST_VMM_ERR_INVALID_LEN) {
+ pr_err("sev-guest: host returned unknown error code: %d\n",
+ vmm_err);
+ return -EINVAL;
+ }
if (rc)
return rc;

@@ -375,7 +411,7 @@ static int get_report(struct snp_guest_dev *snp_dev, struct snp_guest_request_io

rc = handle_guest_request(snp_dev, SVM_VMGEXIT_GUEST_REQUEST, arg->msg_version,
SNP_MSG_REPORT_REQ, &req, sizeof(req), resp->data,
- resp_len, &arg->fw_err);
+ resp_len, &arg->exitinfo2);
if (rc)
goto e_free;

@@ -415,7 +451,7 @@ static int get_derived_key(struct snp_guest_dev *snp_dev, struct snp_guest_reque

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);
+ &arg->exitinfo2);
if (rc)
return rc;

@@ -477,10 +513,10 @@ static int get_ext_report(struct snp_guest_dev *snp_dev, struct snp_guest_reques
snp_dev->input.data_npages = npages;
ret = handle_guest_request(snp_dev, SVM_VMGEXIT_EXT_GUEST_REQUEST, arg->msg_version,
SNP_MSG_REPORT_REQ, &req.data,
- sizeof(req.data), resp->data, resp_len, &arg->fw_err);
+ sizeof(req.data), resp->data, resp_len, &arg->exitinfo2);

/* If certs length is invalid then copy the returned length */
- if (arg->fw_err == SNP_GUEST_REQ_INVALID_LEN) {
+ if (arg->vmm_error == SNP_GUEST_VMM_ERR_INVALID_LEN) {
req.certs_len = snp_dev->input.data_npages << PAGE_SHIFT;

if (copy_to_user((void __user *)arg->req_data, &req, sizeof(req)))
@@ -515,7 +551,7 @@ static long snp_guest_ioctl(struct file *file, unsigned int ioctl, unsigned long
if (copy_from_user(&input, argp, sizeof(input)))
return -EFAULT;

- input.fw_err = 0xff;
+ input.exitinfo2 = SEV_RET_NO_FW_CALL;

/* Message version must be non-zero */
if (!input.msg_version)
@@ -546,7 +582,7 @@ static long snp_guest_ioctl(struct file *file, unsigned int ioctl, unsigned long

mutex_unlock(&snp_cmd_mutex);

- if (input.fw_err && copy_to_user(argp, &input, sizeof(input)))
+ if (input.exitinfo2 && copy_to_user(argp, &input, sizeof(input)))
return -EFAULT;

return ret;
@@ -696,6 +732,8 @@ static int __init sev_guest_probe(struct platform_device *pdev)
if (ret)
goto e_free_cert_data;

+ ratelimit_state_init(&snp_dev->rs, rate_hz * HZ, rate_burst);
+
dev_info(dev, "Initialized SEV guest driver (using vmpck_id %d)\n", vmpck_id);
return 0;

diff --git a/include/uapi/linux/sev-guest.h b/include/uapi/linux/sev-guest.h
index 256aaeff7e65..8e4144aa78c9 100644
--- a/include/uapi/linux/sev-guest.h
+++ b/include/uapi/linux/sev-guest.h
@@ -52,8 +52,15 @@ struct snp_guest_request_ioctl {
__u64 req_data;
__u64 resp_data;

- /* firmware error code on failure (see psp-sev.h) */
- __u64 fw_err;
+ /* bits[63:32]: VMM error code, bits[31:0] firmware error code (see psp-sev.h) */
+ union {
+ __u64 exitinfo2;
+ __u64 fw_err; /* Name deprecated in favor of others */
+ struct {
+ __u32 fw_error;
+ __u32 vmm_error;
+ };
+ };
};

struct snp_ext_report_req {
@@ -77,4 +84,11 @@ struct snp_ext_report_req {
/* Get SNP extended report as defined in the GHCB specification version 2. */
#define SNP_GET_EXT_REPORT _IOWR(SNP_GUEST_REQ_IOC_TYPE, 0x2, struct snp_guest_request_ioctl)

+/* Guest message request EXIT_INFO_2 constants */
+#define SNP_GUEST_FW_ERR_MASK GENMASK_ULL(31, 0)
+#define SNP_GUEST_VMM_ERR_SHIFT 32
+
+#define SNP_GUEST_VMM_ERR_INVALID_LEN 1
+#define SNP_GUEST_VMM_ERR_BUSY 2
+
#endif /* __UAPI_LINUX_SEV_GUEST_H_ */
--
2.38.1.273.g43a17bfeac-goog


2022-11-02 15:44:14

by Dionna Amalie Glaze

[permalink] [raw]
Subject: [PATCH v5 1/4] ccp: Name -1 return value as SEV_RET_NO_FW_CALL

The PSP can return a "firmware error" code of -1 in circumstances where
the PSP is not actually called. To make this protocol unambiguous, we
add a constant naming the return value.

From: Peter Gonda <[email protected]>
Cc: Thomas Lendacky <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Andy Lutomirsky <[email protected]>

Signed-off-by: Dionna Glaze <[email protected]>
---
drivers/crypto/ccp/sev-dev.c | 2 +-
include/uapi/linux/psp-sev.h | 7 +++++++
2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index 06fc7156c04f..97eb3544ab36 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -444,7 +444,7 @@ static int __sev_platform_init_locked(int *error)
{
struct psp_device *psp = psp_master;
struct sev_device *sev;
- int rc = 0, psp_ret = -1;
+ int rc = 0, psp_ret = SEV_RET_NO_FW_CALL;
int (*init_function)(int *error);

if (!psp || !psp->sev_data)
diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h
index 91b4c63d5cbf..1ad7f0a7e328 100644
--- a/include/uapi/linux/psp-sev.h
+++ b/include/uapi/linux/psp-sev.h
@@ -36,6 +36,13 @@ enum {
* SEV Firmware status code
*/
typedef enum {
+ /*
+ * This error code is not in the SEV spec but is added to convey that
+ * there was an error that prevented the SEV Firmware from being called.
+ * This is (u32)-1 since the firmware error code is represented as a
+ * 32-bit integer.
+ */
+ SEV_RET_NO_FW_CALL = 0xffffffff,
SEV_RET_SUCCESS = 0,
SEV_RET_INVALID_PLATFORM_STATE,
SEV_RET_INVALID_GUEST_STATE,
--
2.38.1.273.g43a17bfeac-goog


2022-11-02 17:38:46

by Tom Lendacky

[permalink] [raw]
Subject: Re: [PATCH v5 1/4] ccp: Name -1 return value as SEV_RET_NO_FW_CALL

On 11/2/22 10:43, Peter Gonda wrote:
> From: Dionna Glaze <[email protected]>
>
> The PSP can return a "firmware error" code of -1 in circumstances where
> the PSP is not actually called. To make this protocol unambiguous, we
> add a constant naming the return value.
>
> From: Peter Gonda <[email protected]>
> Cc: Thomas Lendacky <[email protected]>
> Cc: Paolo Bonzini <[email protected]>
> Cc: Joerg Roedel <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Andy Lutomirsky <[email protected]>
>
> Signed-off-by: Dionna Glaze <[email protected]>
>
> I think you can modify the author of this commit to be 'Peter Gonda
> <[email protected]>' then include my Signed-off-by.
>

Since you have to resend for the proper Signed-off-by: chain, the subject
line should really be: crypto: ccp - Name -1 ...

and you missed copying the other CCP driver maintainer.

It's always good to do a git log on the file(s) you're updating to get an
idea of the appropriate prefix to use.

Thanks,
Tom

>

2022-11-02 19:31:00

by Borislav Petkov

[permalink] [raw]
Subject: Re: [PATCH v5 1/4] ccp: Name -1 return value as SEV_RET_NO_FW_CALL

On Wed, Nov 02, 2022 at 12:30:17PM -0500, Tom Lendacky wrote:
> It's always good to do a git log on the file(s) you're updating to get an
> idea of the appropriate prefix to use.

You mean:

git show <commit id> | ./scripts/get_maintainer.pl
Brijesh Singh <[email protected]> (supporter:AMD CRYPTOGRAPHIC COPROCESSOR (CCP) DRIVER - SE...)
Tom Lendacky <[email protected]> (supporter:AMD CRYPTOGRAPHIC COPROCESSOR (CCP) DRIVER - SE...)
John Allen <[email protected]> (supporter:AMD CRYPTOGRAPHIC COPROCESSOR (CCP) DRIVER)
Herbert Xu <[email protected]> (maintainer:CRYPTO API)
"David S. Miller" <[email protected]> (maintainer:CRYPTO API)
[email protected] (open list:AMD CRYPTOGRAPHIC COPROCESSOR (CCP) DRIVER - SE...)
[email protected] (open list)

Btw, I think we need to remove Brijesh...

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

2022-11-03 16:02:40

by Peter Gonda

[permalink] [raw]
Subject: Re: [PATCH v5 0/4] Add throttling detection to sev-guest

On Wed, Nov 2, 2022 at 9:18 AM Dionna Glaze <[email protected]> wrote:
>
> The guest request synchronous API from SEV-SNP VMs to the host's security
> processor consumes a global resource. For this reason, AMD's docs
> recommend that the host implements a throttling mechanism. In order for
> the guest to know it's been throttled and should try its request again,
> we need some good-faith communication from the host that the request
> has been throttled.
>
> These patches work with the existing /dev/sev-guest ABI to detect a
> throttling code.
>
> Changes from v4:
> * Clarified comment on SEV_RET_NO_FW_CALL
> * Changed ratelimit loop to use sleep_timeout_interruptible
> Changes from v3:
> * sev-guest ratelimits itself to one request twice a second.
> * Fixed a type signature to use u64 instead of unsigned int
> * Set *exitinfo2 unconditionally after the ghcb_hv_call.
> Changes from v2:
> * Codified the non-firmware-call firmware error code as (u32)-1.
> * Changed sev_issue_guest_request unsigned long *fw_err argument to
> u64 *exitinfo2 to more accurately and type-safely describe the
> value that it outputs.
> * Changed sev_issue_guest_request to always set its exitinfo2
> argument to either the non-firmware-call error code, the
> EXIT_INFO_2 returned from the VMM if the request failed, or 0 on
> success. This fixes a bug that returned uninitialized kernel stack
> memory to the user when there is no error.
> * Changed the throttle behavior to retry in the driver instead of
> returning -EAGAIN, due to possible message sequence number reuse
> on different message contents.
>
> Changes from v1:
> * Changed throttle error code to 2
>
> Cc: Tom Lendacky <[email protected]>
> Cc: Paolo Bonzini <[email protected]>
> Cc: Joerg Roedel <[email protected]>
> Cc: Peter Gonda <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Dave Hansen <[email protected]>
>
> Signed-off-by: Dionna Glaze <[email protected]>

Should this change be rebased on top of the 'virt: sev: Prevent IV
reuse in SNP guest driver'?
https://lore.kernel.org/lkml/[email protected]/

Since that change is a security fix?

2022-11-03 19:30:33

by Dionna Amalie Glaze

[permalink] [raw]
Subject: Re: [PATCH v5 0/4] Add throttling detection to sev-guest

> Should this change be rebased on top of the 'virt: sev: Prevent IV
> reuse in SNP guest driver'?
> https://lore.kernel.org/lkml/[email protected]/
>
> Since that change is a security fix?

I can do that when your patch gets its Reviewed-By tags.


--
-Dionna Glaze, PhD (she/her)