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@xxxxxxxxxx>
>>>>>>>
>>>>>>> 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@xxxxxxx>
> Tested-by: Alexey Kardashevskiy <aik@xxxxxxx>
>
> or should I reply with these to the original mail?
>

Thanks. I think it should be fine like this.