[PATCH v12 3/3] virt: sev-guest: interpret VMM errors from guest request
From: Dionna Glaze
Date: Fri Jan 20 2023 - 16:53:22 EST
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. Add BIT_ULL(33) for "host refused the request for throttling
reasons".
The driver interprets 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, control must remain in the
kernel to complete the request with the current sequence number.
Returning without finishing the request allows the the guest to make
another request but with different message contents. This is IV reuse,
and breaks cryptographic protections.
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 <Thomas.Lendacky@xxxxxxx>
Cc: Peter Gonda <pgonda@xxxxxxxxxx>
Cc: Borislav Petkov <Borislav.Petkov@xxxxxxx>
Cc: Tom Lendacky <thomas.lendacky@xxxxxxx>
Cc: Liam Merwick <liam.merwick@xxxxxxxxxx>
Cc: Yang Yingliang <yangyingliang@xxxxxxxxxx>
Cc: Haowen Bai <baihaowen@xxxxxxxxx>
Reviewed-by: Tom Lendacky <Thomas.Lendacky@xxxxxxx>
Reviewed-by: Peter Gonda <pgonda@xxxxxxxxxx>
Signed-off-by: Dionna Glaze <dionnaglaze@xxxxxxxxxx>
---
Documentation/virt/coco/sev-guest.rst | 21 +++++++++++------
drivers/virt/coco/sev-guest/sev-guest.c | 31 +++++++++++++++++++++++++
2 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/Documentation/virt/coco/sev-guest.rst b/Documentation/virt/coco/sev-guest.rst
index e76393e389eb..fd8bf833f1cd 100644
--- a/Documentation/virt/coco/sev-guest.rst
+++ b/Documentation/virt/coco/sev-guest.rst
@@ -37,11 +37,12 @@ along with a description:
the return value. General error numbers (-ENOMEM, -EINVAL)
are not detailed, but errors with specific meanings are.
-The guest ioctl should be issued on a file descriptor of the /dev/sev-guest device.
-The ioctl accepts struct snp_user_guest_request. The input and output structure is
-specified through the req_data and resp_data field respectively. If the ioctl fails
-to execute due to a firmware error, then fw_err code will be set otherwise the
-fw_err will be set to 0x00000000ffffffff, i.e., the lower 32-bits are -1.
+The guest ioctl should be issued on a file descriptor of the
+/dev/sev-guest device. The ioctl accepts struct
+snp_user_guest_request. The input and output structure is specified
+through the req_data and resp_data field respectively. If the ioctl
+fails to execute due to a firmware error, then the fw_error code will
+be set, otherwise fw_error will be set to -1.
The firmware checks that the message sequence counter is one greater than
the guests message sequence counter. If guest driver fails to increment message
@@ -57,8 +58,14 @@ counter (e.g. counter overflow), then -EIO will be returned.
__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;
+ struct {
+ __u32 fw_error;
+ __u32 vmm_error;
+ };
+ };
};
2.1 SNP_GET_REPORT
diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index ed6fc14f6b00..1bffd9b1b7dc 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_s = 1;
+module_param(rate_s, int, 0444);
+MODULE_PARM_DESC(rate_s, "The rate limit interval in seconds to limit requests to.");
+
+static int rate_burst = 2;
+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);
@@ -338,6 +349,16 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code,
if (rc)
return rc;
+retry:
+ /*
+ * Rate limit commands internally since the host can also throttle, and
+ * the guest shouldn't create a tight request spin that could end up
+ * getting this VM throttled more heavily.
+ */
+ if (!__ratelimit(&snp_dev->rs)) {
+ schedule_timeout_interruptible((rate_s * HZ) / 2);
+ goto retry;
+ }
/*
* Call firmware to process the request. In this function the encrypted
* message enters shared memory with the host. So after this call the
@@ -347,6 +368,14 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code,
rc = snp_issue_guest_request(exit_code, &snp_dev->input,
&arg->exitinfo2);
+ /*
+ * 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 (arg->vmm_error == SNP_GUEST_VMM_ERR_BUSY)
+ goto retry;
+
/*
* If the extended guest request fails due to having too small of a
* certificate data buffer, retry the same guest request without the
@@ -751,6 +780,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_s * HZ, rate_burst);
+
dev_info(dev, "Initialized SEV guest driver (using vmpck_id %d)\n", vmpck_id);
return 0;
--
2.39.0.246.g2a6d74b583-goog