lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YjCJejmCTOYZkVj5@kroah.com>
Date:   Tue, 15 Mar 2022 13:41:30 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     James Morse <james.morse@....com>
Cc:     Pavel Machek <pavel@...x.de>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, Catalin Marinas <catalin.marinas@....com>
Subject: Re: [PATCH 5.10 38/58] KVM: arm64: Allow indirect vectors to be used
 without SPECTRE_V3A

On Tue, Mar 15, 2022 at 12:27:29PM +0000, James Morse wrote:
> On 3/15/22 12:20 PM, James Morse wrote:
> > On 3/11/22 6:42 AM, Greg Kroah-Hartman wrote:
> > > On Fri, Mar 11, 2022 at 12:48:59AM +0100, Pavel Machek wrote:
> > > > What is going on here?
> > > > 
> > > > > commit 5bdf3437603d4af87f9c7f424b0c8aeed2420745 upstream.
> > > > 
> > > > Upstream commit 5bdf is very different from this. In particular,
> > > > 
> > > > >   arch/arm64/kvm/hyp/smccc_wa.S    |   66 +++++++++++++++++++++++++++++++++++++++
> > > > 
> > > > I can't find smccc_wa.S, neither in mainline, nor in -next. And it
> > > > looks buggy. I suspect loop_k24 should loop 24 times, but it does 8
> > > > loops AFAICT. Same problem with loop_k32.
> > 
> > Yup, that's a bug. Thanks for spotting it!
> > I'll post a replacement for this patch.
> 
> Looking more closely at this: when I originally did this the 'new' code for stable was
> in a separate patch to make it clear it was new code. Here it looks like Greg has merged
> it into this patch.

I did?  I don't recall doing that at all, sorry.  But getting the 5.10
arm64 tree into the stable queue was not easy from what I recall.

> I'm not sure what the 'rules' are for this sort of thing, obviously Greg gets the last say.
> 
> I'll try and restructure the other backports to look like this, it is certainly simpler
> than trrying to pull all the prerequisites for all the upstream patches in.

I tried to also take a lot of prerequisite patches for the cpu id stuff,
to make those merges easier, so I have no problem with taking what is in
Linus's tree to make backports simpler.  But it's a balencing act,
especially for tougher stuff like this :(

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ