The Guest Request supports 3 types of messages now, the largest is
the extended variant of MSG_REPORT_REQ: sizeof(snp_ext_report_req)==112.
These used to be allocated on stack and then moved to the SNP guest
platform device (snp_guest_dev) for the reason explained in

commit db10cb9b5746 ("virt: sevguest: Fix passing a stack buffer as
a scatterlist target"):

aesgcm_encrypt() and aesgcm_decrypt() are used for guest messages and
might potentially use a crypto accelerator which requires DMA buffers
to be in the linear mapping.

Add a comment, pr_warn() and return -EINVAL when the buffers are not
in linear mapping.

Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
---
Changes:
v4:
* ditched BUG_ON and ifdef
---
 arch/x86/coco/sev/core.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 818ae7b1694b..0b714df62445 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -1941,6 +1941,16 @@ int snp_send_guest_request(struct snp_msg_desc *mdesc, struct snp_guest_req *req
 	u64 seqno;
 	int rc;
 
+	/*
+	 * enc_payload() calling aesgcm_encrypt() can potentially offload to HW
+	 * which involves DMA so the data to encrypt in the SG list has to be
+	 * in linear mapping.
+	 */
+	if (!virt_addr_valid(req->req_buf) || !virt_addr_valid(req->resp_buf)) {
+		pr_warn("AES-GSM buffers must be in linear mapping");
+		return -EINVAL;
+	}
+
 	guard(mutex)(&snp_cmd_mutex);
 
 	/* Check if the VMPCK is not empty */
-- 
2.49.0

On Mon, May 5, 2025 at 7:14 AM Alexey Kardashevskiy <aik@amd.com> wrote:
>
> The Guest Request supports 3 types of messages now, the largest is
> the extended variant of MSG_REPORT_REQ: sizeof(snp_ext_report_req)==112.
> These used to be allocated on stack and then moved to the SNP guest
> platform device (snp_guest_dev) for the reason explained in
>
> commit db10cb9b5746 ("virt: sevguest: Fix passing a stack buffer as
> a scatterlist target"):
>
> aesgcm_encrypt() and aesgcm_decrypt() are used for guest messages and
> might potentially use a crypto accelerator which requires DMA buffers
> to be in the linear mapping.
>
> Add a comment, pr_warn() and return -EINVAL when the buffers are not
> in linear mapping.
>
> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>

Reviewed-by: Dionna Glaze <dionnaglaze@google.com>

> ---
> Changes:
> v4:
> * ditched BUG_ON and ifdef
> ---
>  arch/x86/coco/sev/core.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
> index 818ae7b1694b..0b714df62445 100644
> --- a/arch/x86/coco/sev/core.c
> +++ b/arch/x86/coco/sev/core.c
> @@ -1941,6 +1941,16 @@ int snp_send_guest_request(struct snp_msg_desc *mdesc, struct snp_guest_req *req
>         u64 seqno;
>         int rc;
>
> +       /*
> +        * enc_payload() calling aesgcm_encrypt() can potentially offload to HW
> +        * which involves DMA so the data to encrypt in the SG list has to be
> +        * in linear mapping.
> +        */

The grammar here is a bit off. Would recommend

+       /*
+        * enc_payload() calls aesgcm_encrypt(), which can potentially
offload to HW.
+        * The offload's DMA SG list of data to encrypt has to be in
linear mapping.
+        */



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