Message ID | 20220315182415.3900464-1-james.morse@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | arm64: Mitigate spectre style branch history side channels | expand |
On Tue, Mar 15, 2022 at 06:23:53PM +0000, James Morse wrote: >Hi Greg, > >Here is the state of the current v5.4 backport. Now that the 32bit >code has been merged, it doesn't conflict when KVM's shared 32bit/64bit >code needs to use these constants. > >I've fixed the two issues that were reported against the v5.10 backport. > >I had a go at bringing all the pre-requisites in to add proton-pack.c >to v5.4. Its currently 39 patches: >https://git.gitlab.arm.com/linux-arm/linux-jm.git /bhb/alternative_backport/UNTESTED/v5.4.183 >(or for web browsers: >https://gitlab.arm.com/linux-arm/linux-jm/-/commits/bhb/alternative_backport/UNTESTED/v5.4.183/ >) I've queued it up. >I've not managed to bring b881cdce77b4 "KVM: arm64: Allocate hyp vectors >statically" in, as that depends on the hypervisor's per-cpu support. Its >this patch that means those 'smccc_wa' templates are needed. >I estimate it would be 60 patches in total if we go this way, I don't >think its a good idea: >All this still has to work around 541ad0150ca4 ("arm: Remove 32bit KVM >host support") and 9ed24f4b712b ("KVM: arm64: Move virt/kvm/arm to >arch/arm64") being missing. >I think this approach creates more problems than it solves as the >files have to be in different places because of 32bit. It also creates >a significantly larger testing problem: I'm not looking forward to >working out how to test KVM guest migration over the variant-4 KVM ABI >changes in 29e8910a566a. I think that the workaround you mention later on for this issue makes sense cost/benefit-wise. >This version of the backport still adds the mitigation management code >to cpu_errata.c, because that is where this stuff lived in v5.4. > >If you prefer, I can try adding proton-pack.c as a new empty file. >I think this would only confuse matters as the line-numbers would >never match, and there is an interaction with the spectre-v2 mitigations >that live in cpu_errata.c. > >There is one patch not present in mainline 'KVM: arm64: Add templtes for >BHB mitigation sequences'. Thank you!
Hi Sasha, On 3/16/22 3:41 PM, Sasha Levin wrote: > On Tue, Mar 15, 2022 at 06:23:53PM +0000, James Morse wrote: >> Hi Greg, >> >> Here is the state of the current v5.4 backport. Now that the 32bit >> code has been merged, it doesn't conflict when KVM's shared 32bit/64bit >> code needs to use these constants. >> >> I've fixed the two issues that were reported against the v5.10 backport. >> >> I had a go at bringing all the pre-requisites in to add proton-pack.c >> to v5.4. Its currently 39 patches: >> https://git.gitlab.arm.com/linux-arm/linux-jm.git /bhb/alternative_backport/UNTESTED/v5.4.183 >> (or for web browsers: >> https://gitlab.arm.com/linux-arm/linux-jm/-/commits/bhb/alternative_backport/UNTESTED/v5.4.183/ >> ) > > I've queued it up. Just to clarify - you've queued this series that I posted, not the above 'UNTESTED' branch where I tried (unsuccessfully) to bring in the prerequisites. (The position of your comment made me jump!) The background is Greg commented on the BHB list that he thought it would be better to bring in the prerequisites, I said I'd have a go. As described here, I think it just creates new problems. Thanks, James
On Wed, Mar 16, 2022 at 05:38:34PM +0000, James Morse wrote: >Hi Sasha, > >On 3/16/22 3:41 PM, Sasha Levin wrote: >>On Tue, Mar 15, 2022 at 06:23:53PM +0000, James Morse wrote: >>>Hi Greg, >>> >>>Here is the state of the current v5.4 backport. Now that the 32bit >>>code has been merged, it doesn't conflict when KVM's shared 32bit/64bit >>>code needs to use these constants. >>> >>>I've fixed the two issues that were reported against the v5.10 backport. >>> >>>I had a go at bringing all the pre-requisites in to add proton-pack.c >>>to v5.4. Its currently 39 patches: >>>https://git.gitlab.arm.com/linux-arm/linux-jm.git /bhb/alternative_backport/UNTESTED/v5.4.183 >>>(or for web browsers: >>>https://gitlab.arm.com/linux-arm/linux-jm/-/commits/bhb/alternative_backport/UNTESTED/v5.4.183/ >>>) >> >>I've queued it up. > >Just to clarify - you've queued this series that I posted, not the above 'UNTESTED' branch >where I tried (unsuccessfully) to bring in the prerequisites. > >(The position of your comment made me jump!) Yes, sorry, the series :)
On Wed, Mar 16, 2022 at 11:41:07AM -0400, Sasha Levin wrote: > On Tue, Mar 15, 2022 at 06:23:53PM +0000, James Morse wrote: > > Hi Greg, > > > > Here is the state of the current v5.4 backport. Now that the 32bit > > code has been merged, it doesn't conflict when KVM's shared 32bit/64bit > > code needs to use these constants. > > > > I've fixed the two issues that were reported against the v5.10 backport. > > > > I had a go at bringing all the pre-requisites in to add proton-pack.c > > to v5.4. Its currently 39 patches: > > https://git.gitlab.arm.com/linux-arm/linux-jm.git /bhb/alternative_backport/UNTESTED/v5.4.183 > > (or for web browsers: > > https://gitlab.arm.com/linux-arm/linux-jm/-/commits/bhb/alternative_backport/UNTESTED/v5.4.183/ > > ) > > I've queued it up. Thanks for merging these, and James, thanks for the backports! I agree, this way is a bit "simpler", but thanks for trying the other way as well. Does this mean that the 4.19 and older backports will be easier? greg k-h
Hi Greg, On 3/17/22 10:00 AM, Greg KH wrote: > On Wed, Mar 16, 2022 at 11:41:07AM -0400, Sasha Levin wrote: >> On Tue, Mar 15, 2022 at 06:23:53PM +0000, James Morse wrote: >>> Hi Greg, >>> >>> Here is the state of the current v5.4 backport. Now that the 32bit >>> code has been merged, it doesn't conflict when KVM's shared 32bit/64bit >>> code needs to use these constants. >>> >>> I've fixed the two issues that were reported against the v5.10 backport. >>> >>> I had a go at bringing all the pre-requisites in to add proton-pack.c >>> to v5.4. Its currently 39 patches: >>> https://git.gitlab.arm.com/linux-arm/linux-jm.git /bhb/alternative_backport/UNTESTED/v5.4.183 >>> (or for web browsers: >>> https://gitlab.arm.com/linux-arm/linux-jm/-/commits/bhb/alternative_backport/UNTESTED/v5.4.183/ >>> ) >> >> I've queued it up. > > Thanks for merging these, and James, thanks for the backports! I agree, > this way is a bit "simpler", but thanks for trying the other way as > well. > Does this mean that the 4.19 and older backports will be easier? It means they'll be based on the versions I posted on before. But: the last review comment that needs addressing is the A76 ID macros that came in with an errata workaround, but the workaround wasn't backported. I need to work out how easy that is to do. Thanks, James