Re: [PATCH 5.10 076/529] crypto: ccp: Use the stack for small SEV command buffers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 26, 2023 at 05:36:02PM +0200, Ben Hutchings wrote:
> On Wed, 2023-05-17 at 16:06 +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 17, 2023 at 04:02:35PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, May 17, 2023 at 02:56:21PM +0200, Ben Hutchings wrote:
> > > > On Fri, 2023-03-10 at 14:33 +0100, Greg Kroah-Hartman wrote:
> > > > > From: Sean Christopherson <seanjc@xxxxxxxxxx>
> > > > > 
> > > > > [ Upstream commit e4a9af799e5539b0feb99571f0aaed5a3c81dc5a ]
> > > > > 
> > > > > For commands with small input/output buffers, use the local stack to
> > > > > "allocate" the structures used to communicate with the PSP.   Now that
> > > > > __sev_do_cmd_locked() gracefully handles vmalloc'd buffers, there's no
> > > > > reason to avoid using the stack, e.g. CONFIG_VMAP_STACK=y will just work.
> > > > [...]
> > > > 
> > > > Julien Cristau reported a regression in ccp - the
> > > > WARN_ON_ONCE(!virt_addr_valid(data)) is now being triggered.  I believe
> > > > this was introduced by the above commit, which depends on:
> > > > 
> > > > commit 8347b99473a313be6549a5b940bc3c56a71be81c
> > > > Author: Sean Christopherson <seanjc@xxxxxxxxxx>
> > > > Date:   Tue Apr 6 15:49:48 2021 -0700
> > > >  
> > > >     crypto: ccp: Play nice with vmalloc'd memory for SEV command structs
> > > > 
> > > > Ben.
> > > > 
> > > 
> > > Thanks for letting me know, now queued up.
> > 
> > Nope, now dropped, it breaks the build :(
> 
> I've now looked further and found that we need both:
> 
> d5760dee127b crypto: ccp: Reject SEV commands with mismatching command buffer
> 8347b99473a3 crypto: ccp: Play nice with vmalloc'd memory for SEV command structs
> 
> (Not yet tested; I'll ask Julien if he can do that.)

Looks sane to me, both now queued up, thanks.

greg k-h



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux