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@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,


--
Alexey