[PATCH] x86/sev: Remove bogus virtual address check

[PATCH] x86/sev: Remove bogus virtual address check

[Ard Biesheuvel]

From: Ard Biesheuvel <ardb@kernel.org>

The AES-GCM crypto library operates strictly on virtual addresses, and
never performs any H/W offload, and so calling virt_addr_valid() is not
needed.

Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/x86/coco/sev/core.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 9ae3b11754e6..c4e2de3687a9 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -2249,15 +2249,6 @@ int snp_send_guest_request(struct snp_msg_desc *mdesc, struct snp_guest_req *req
 	u64 seqno;
 	int rc;
 
-	/*
-	 * 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.
-	 */
-	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.51.0.740.g6adb054d12-goog

Re: [PATCH] x86/sev: Remove bogus virtual address check

[Ard Biesheuvel]

(cc Eric)

On Fri, 10 Oct 2025, at 17:10, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The AES-GCM crypto library operates strictly on virtual addresses, and
> never performs any H/W offload, and so calling virt_addr_valid() is not
> needed.
>
> Cc: Borislav Petkov (AMD) <bp@alien8.de>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  arch/x86/coco/sev/core.c | 9 ---------
>  1 file changed, 9 deletions(-)
>

Ping?

> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
> index 9ae3b11754e6..c4e2de3687a9 100644
> --- a/arch/x86/coco/sev/core.c
> +++ b/arch/x86/coco/sev/core.c
> @@ -2249,15 +2249,6 @@ int snp_send_guest_request(struct snp_msg_desc 
> *mdesc, struct snp_guest_req *req
>  	u64 seqno;
>  	int rc;
> 
> -	/*
> -	 * 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.
> -	 */
> -	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.51.0.740.g6adb054d12-goog

Re: [PATCH] x86/sev: Remove bogus virtual address check

[Borislav Petkov]

On Fri, Oct 10, 2025 at 05:10:37PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> The AES-GCM crypto library operates strictly on virtual addresses, and
> never performs any H/W offload, and so calling virt_addr_valid() is not
> needed.
> 
> Cc: Borislav Petkov (AMD) <bp@alien8.de>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  arch/x86/coco/sev/core.c | 9 ---------
>  1 file changed, 9 deletions(-)
> 
> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
> index 9ae3b11754e6..c4e2de3687a9 100644
> --- a/arch/x86/coco/sev/core.c
> +++ b/arch/x86/coco/sev/core.c
> @@ -2249,15 +2249,6 @@ int snp_send_guest_request(struct snp_msg_desc *mdesc, struct snp_guest_req *req
>  	u64 seqno;
>  	int rc;
>  
> -	/*
> -	 * 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.
> -	 */
> -	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 */
> -- 

This came from:

  7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping of guest request buffers")

and there was some speculation about the potential of using a crypto
accelerator which wants addresses in linear mapping...

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH] x86/sev: Remove bogus virtual address check

[Ard Biesheuvel]

On Tue, 31 Mar 2026, at 15:16, Borislav Petkov wrote:
> On Fri, Oct 10, 2025 at 05:10:37PM +0200, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel <ardb@kernel.org>
>> 
>> The AES-GCM crypto library operates strictly on virtual addresses, and
>> never performs any H/W offload, and so calling virt_addr_valid() is not
>> needed.
>> 
>> Cc: Borislav Petkov (AMD) <bp@alien8.de>
>> Cc: Tom Lendacky <thomas.lendacky@amd.com>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> ---
>>  arch/x86/coco/sev/core.c | 9 ---------
>>  1 file changed, 9 deletions(-)
>> 
>> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
>> index 9ae3b11754e6..c4e2de3687a9 100644
>> --- a/arch/x86/coco/sev/core.c
>> +++ b/arch/x86/coco/sev/core.c
>> @@ -2249,15 +2249,6 @@ int snp_send_guest_request(struct snp_msg_desc *mdesc, struct snp_guest_req *req
>>  	u64 seqno;
>>  	int rc;
>>  
>> -	/*
>> -	 * 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.
>> -	 */
>> -	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 */
>> -- 
>
> This came from:
>
>   7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping of 
> guest request buffers")
>
> and there was some speculation about the potential of using a crypto
> accelerator which wants addresses in linear mapping...
>

Sure, but that speculation was entirely misguided, so we can remove this again.

Re: [PATCH] x86/sev: Remove bogus virtual address check

[Ard Biesheuvel]

(add Eric back to cc)

Please keep Eric on cc - I added him for a reason, thanks.


On Tue, 31 Mar 2026, at 15:18, Ard Biesheuvel wrote:
> On Tue, 31 Mar 2026, at 15:16, Borislav Petkov wrote:
>> On Fri, Oct 10, 2025 at 05:10:37PM +0200, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>> 
>>> The AES-GCM crypto library operates strictly on virtual addresses, and
>>> never performs any H/W offload, and so calling virt_addr_valid() is not
>>> needed.
>>> 
>>> Cc: Borislav Petkov (AMD) <bp@alien8.de>
>>> Cc: Tom Lendacky <thomas.lendacky@amd.com>
>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>>> ---
>>>  arch/x86/coco/sev/core.c | 9 ---------
>>>  1 file changed, 9 deletions(-)
>>> 
>>> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
>>> index 9ae3b11754e6..c4e2de3687a9 100644
>>> --- a/arch/x86/coco/sev/core.c
>>> +++ b/arch/x86/coco/sev/core.c
>>> @@ -2249,15 +2249,6 @@ int snp_send_guest_request(struct snp_msg_desc *mdesc, struct snp_guest_req *req
>>>  	u64 seqno;
>>>  	int rc;
>>>  
>>> -	/*
>>> -	 * 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.
>>> -	 */
>>> -	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 */
>>> -- 
>>
>> This came from:
>>
>>   7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping of 
>> guest request buffers")
>>
>> and there was some speculation about the potential of using a crypto
>> accelerator which wants addresses in linear mapping...
>>
>
> Sure, but that speculation was entirely misguided, so we can remove this again.

Re: [PATCH] x86/sev: Remove bogus virtual address check

[Alexey Kardashevskiy]

On 1/4/26 00:21, Ard Biesheuvel wrote:
> (add Eric back to cc)
> 
> Please keep Eric on cc - I added him for a reason, thanks.
> 
> 
> On Tue, 31 Mar 2026, at 15:18, Ard Biesheuvel wrote:
>> On Tue, 31 Mar 2026, at 15:16, Borislav Petkov wrote:
>>> On Fri, Oct 10, 2025 at 05:10:37PM +0200, Ard Biesheuvel wrote:
>>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>>
>>>> The AES-GCM crypto library operates strictly on virtual addresses, and
>>>> never performs any H/W offload, and so calling virt_addr_valid() is not
>>>> needed.
>>>>
>>>> Cc: Borislav Petkov (AMD) <bp@alien8.de>
>>>> Cc: Tom Lendacky <thomas.lendacky@amd.com>
>>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>>>> ---
>>>>   arch/x86/coco/sev/core.c | 9 ---------
>>>>   1 file changed, 9 deletions(-)
>>>>
>>>> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
>>>> index 9ae3b11754e6..c4e2de3687a9 100644
>>>> --- a/arch/x86/coco/sev/core.c
>>>> +++ b/arch/x86/coco/sev/core.c
>>>> @@ -2249,15 +2249,6 @@ int snp_send_guest_request(struct snp_msg_desc *mdesc, struct snp_guest_req *req
>>>>   	u64 seqno;
>>>>   	int rc;
>>>>   
>>>> -	/*
>>>> -	 * 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.
>>>> -	 */
>>>> -	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 */
>>>> -- 
>>>
>>> This came from:
>>>
>>>    7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping of
>>> guest request buffers")

Nah, this is because of
db10cb9b574675402b virt: sevguest: Fix passing a stack buffer as a scatterlist target


>>>
>>> and there was some speculation about the potential of using a crypto
>>> accelerator which wants addresses in linear mapping...

If the pr_warn() above is removed, then we get this BUG_ON back:

===
static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
                               unsigned int buflen)
{
#ifdef CONFIG_DEBUG_SG
         BUG_ON(!virt_addr_valid(buf));
#endif
         sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
}
===

So if you really insist on removing my pr_warn(), then post a patch removing the BUG_ON too. Thanks,

>>>
>>
>> Sure, but that speculation was entirely misguided, so we can remove this again.

-- 
Alexey

Re: [PATCH] x86/sev: Remove bogus virtual address check

[Ard Biesheuvel]

[ replying a second time since the first one seems to have evaporated -
apologies if you are seeing two replies that look vaguely but not
exactly the same]

On Tue, 31 Mar 2026, at 23:30, Alexey Kardashevskiy wrote:
> On 1/4/26 00:21, Ard Biesheuvel wrote:
>> (add Eric back to cc)
>>
>> Please keep Eric on cc - I added him for a reason, thanks.
>>
>>
>> On Tue, 31 Mar 2026, at 15:18, Ard Biesheuvel wrote:
>>> On Tue, 31 Mar 2026, at 15:16, Borislav Petkov wrote:
>>>> On Fri, Oct 10, 2025 at 05:10:37PM +0200, Ard Biesheuvel wrote:
>>>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>>>
>>>>> The AES-GCM crypto library operates strictly on virtual addresses,
>>>>> and never performs any H/W offload, and so calling
>>>>> virt_addr_valid() is not needed.
>>>>>
...
>>>>
>>>> This came from:
>>>>
>>>>    7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping
>>>>    of guest request buffers")
>
> Nah, this is because of db10cb9b574675402b virt: sevguest: Fix passing
> a stack buffer as a scatterlist target
>

Is that change still needed after

  f3476bc77057 ("virt: sev-guest: Use AES GCM crypto library")

If not, should we revert db10cb9b574675402b too?

Using the crypto API for simple operations where the algorithm is known
at build time was always a mistake. But moving stack allocations to the
heap just to placate a clunky API that can only be used meaningfully in
an asynchronous manner in the first place is just pointless.

Re: [PATCH] x86/sev: Remove bogus virtual address check

[Alexey Kardashevskiy]

On 1/4/26 18:29, Ard Biesheuvel wrote:
> [ replying a second time since the first one seems to have evaporated -
> apologies if you are seeing two replies that look vaguely but not
> exactly the same]
> 
> On Tue, 31 Mar 2026, at 23:30, Alexey Kardashevskiy wrote:
>> On 1/4/26 00:21, Ard Biesheuvel wrote:
>>> (add Eric back to cc)
>>>
>>> Please keep Eric on cc - I added him for a reason, thanks.
>>>
>>>
>>> On Tue, 31 Mar 2026, at 15:18, Ard Biesheuvel wrote:
>>>> On Tue, 31 Mar 2026, at 15:16, Borislav Petkov wrote:
>>>>> On Fri, Oct 10, 2025 at 05:10:37PM +0200, Ard Biesheuvel wrote:
>>>>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>>>>
>>>>>> The AES-GCM crypto library operates strictly on virtual addresses,
>>>>>> and never performs any H/W offload, and so calling
>>>>>> virt_addr_valid() is not needed.
>>>>>>
> ...
>>>>>
>>>>> This came from:
>>>>>
>>>>>     7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping
>>>>>     of guest request buffers")
>>
>> Nah, this is because of db10cb9b574675402b virt: sevguest: Fix passing
>> a stack buffer as a scatterlist target
>>
> 
> Is that change still needed after
> 
>    f3476bc77057 ("virt: sev-guest: Use AES GCM crypto library")

huh. You're right, looks like it is not, I missed that.

> If not, should we revert db10cb9b574675402b too?

Nah, we do not want these structures on stack anyway (they might get too big in the future).

> Using the crypto API for simple operations where the algorithm is known
> at build time was always a mistake. But moving stack allocations to the
> heap just to placate a clunky API that can only be used meaningfully in
> an asynchronous manner in the first place is just pointless.

True.

Reviewed-by: Alexey Kardashevskiy <aik@amd.com>
Tested-by: Alexey Kardashevskiy <aik@amd.com>

or should I reply with these to the original mail?

Thanks,


-- 
Alexey

Re: [PATCH] x86/sev: Remove bogus virtual address check

[Ard Biesheuvel]

On Wed, 1 Apr 2026, at 10:03, Alexey Kardashevskiy wrote:
> On 1/4/26 18:29, Ard Biesheuvel wrote:
>> On Tue, 31 Mar 2026, at 23:30, Alexey Kardashevskiy wrote:
>>> On 1/4/26 00:21, Ard Biesheuvel wrote:
>>>> (add Eric back to cc)
>>>>
>>>> Please keep Eric on cc - I added him for a reason, thanks.
>>>>
>>>>
>>>> On Tue, 31 Mar 2026, at 15:18, Ard Biesheuvel wrote:
>>>>> On Tue, 31 Mar 2026, at 15:16, Borislav Petkov wrote:
>>>>>> On Fri, Oct 10, 2025 at 05:10:37PM +0200, Ard Biesheuvel wrote:
>>>>>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>>>>>
>>>>>>> The AES-GCM crypto library operates strictly on virtual addresses,
>>>>>>> and never performs any H/W offload, and so calling
>>>>>>> virt_addr_valid() is not needed.
>>>>>>>
>> ...
>>>>>>
>>>>>> This came from:
>>>>>>
>>>>>>     7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping
>>>>>>     of guest request buffers")
>>>
>>> Nah, this is because of db10cb9b574675402b virt: sevguest: Fix passing
>>> a stack buffer as a scatterlist target
>>>
>> 
>> Is that change still needed after
>> 
>>    f3476bc77057 ("virt: sev-guest: Use AES GCM crypto library")
>
> huh. You're right, looks like it is not, I missed that.
>
>> If not, should we revert db10cb9b574675402b too?
>
> Nah, we do not want these structures on stack anyway (they might get 
> too big in the future).
>
>> Using the crypto API for simple operations where the algorithm is known
>> at build time was always a mistake. But moving stack allocations to the
>> heap just to placate a clunky API that can only be used meaningfully in
>> an asynchronous manner in the first place is just pointless.
>
> True.
>
> Reviewed-by: Alexey Kardashevskiy <aik@amd.com>
> Tested-by: Alexey Kardashevskiy <aik@amd.com>
>
> or should I reply with these to the original mail?
>

Thanks. I think it should be fine like this.

Re: [PATCH] x86/sev: Remove bogus virtual address check

[Borislav Petkov]

On Wed, Apr 01, 2026 at 10:12:56AM +0200, Ard Biesheuvel wrote:
> 
> On Wed, 1 Apr 2026, at 10:03, Alexey Kardashevskiy wrote:
> > On 1/4/26 18:29, Ard Biesheuvel wrote:
> >> On Tue, 31 Mar 2026, at 23:30, Alexey Kardashevskiy wrote:
> >>> On 1/4/26 00:21, Ard Biesheuvel wrote:
> >>>> (add Eric back to cc)
> >>>>
> >>>> Please keep Eric on cc - I added him for a reason, thanks.
> >>>>
> >>>>
> >>>> On Tue, 31 Mar 2026, at 15:18, Ard Biesheuvel wrote:
> >>>>> On Tue, 31 Mar 2026, at 15:16, Borislav Petkov wrote:
> >>>>>> On Fri, Oct 10, 2025 at 05:10:37PM +0200, Ard Biesheuvel wrote:
> >>>>>>> From: Ard Biesheuvel <ardb@kernel.org>
> >>>>>>>
> >>>>>>> The AES-GCM crypto library operates strictly on virtual addresses,
> >>>>>>> and never performs any H/W offload, and so calling
> >>>>>>> virt_addr_valid() is not needed.
> >>>>>>>
> >> ...
> >>>>>>
> >>>>>> This came from:
> >>>>>>
> >>>>>>     7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping
> >>>>>>     of guest request buffers")
> >>>
> >>> Nah, this is because of db10cb9b574675402b virt: sevguest: Fix passing
> >>> a stack buffer as a scatterlist target
> >>>
> >> 
> >> Is that change still needed after
> >> 
> >>    f3476bc77057 ("virt: sev-guest: Use AES GCM crypto library")
> >
> > huh. You're right, looks like it is not, I missed that.
> >
> >> If not, should we revert db10cb9b574675402b too?
> >
> > Nah, we do not want these structures on stack anyway (they might get 
> > too big in the future).
> >
> >> Using the crypto API for simple operations where the algorithm is known
> >> at build time was always a mistake. But moving stack allocations to the
> >> heap just to placate a clunky API that can only be used meaningfully in
> >> an asynchronous manner in the first place is just pointless.
> >
> > True.
> >
> > Reviewed-by: Alexey Kardashevskiy <aik@amd.com>
> > Tested-by: Alexey Kardashevskiy <aik@amd.com>
> >
> > or should I reply with these to the original mail?
> >
> 
> Thanks. I think it should be fine like this.

And now let's invite the folks from

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

to the party so that the circle is complete. :-)

-- 
Regards/Gruss,
    Boris.

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