| 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
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 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. 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'. Thanks, James Anshuman Khandual (1): arm64: Add Cortex-X2 CPU part definition James Morse (18): arm64: entry.S: Add ventry overflow sanity checks arm64: entry: Make the trampoline cleanup optional arm64: entry: Free up another register on kpti's tramp_exit path arm64: entry: Move the trampoline data page before the text page arm64: entry: Allow tramp_alias to access symbols after the 4K boundary arm64: entry: Don't assume tramp_vectors is the start of the vectors arm64: entry: Move trampoline macros out of ifdef'd section arm64: entry: Make the kpti trampoline's kpti sequence optional arm64: entry: Allow the trampoline text to occupy multiple pages arm64: entry: Add non-kpti __bp_harden_el1_vectors for mitigations arm64: entry: Add vectors that have the bhb mitigation sequences arm64: entry: Add macro for reading symbol addresses from the trampoline arm64: Add percpu vectors for EL1 arm64: proton-pack: Report Spectre-BHB vulnerabilities as part of Spectre-v2 KVM: arm64: Add templates for BHB mitigation sequences arm64: Mitigate spectre style branch history side channels KVM: arm64: Allow SMCCC_ARCH_WORKAROUND_3 to be discovered and migrated arm64: Use the clearbhb instruction in mitigations Joey Gouly (1): arm64: add ID_AA64ISAR2_EL1 sys register Rob Herring (1): arm64: Add part number for Arm Cortex-A77 Suzuki K Poulose (1): arm64: Add Neoverse-N2, Cortex-A710 CPU part definition arch/arm/include/asm/kvm_host.h | 7 + arch/arm/include/uapi/asm/kvm.h | 6 + arch/arm64/Kconfig | 9 + arch/arm64/include/asm/assembler.h | 33 +++ arch/arm64/include/asm/cpu.h | 1 + arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/include/asm/cpufeature.h | 40 +++ arch/arm64/include/asm/cputype.h | 16 ++ arch/arm64/include/asm/fixmap.h | 6 +- arch/arm64/include/asm/kvm_host.h | 5 + arch/arm64/include/asm/kvm_mmu.h | 6 +- arch/arm64/include/asm/mmu.h | 8 +- arch/arm64/include/asm/sections.h | 5 + arch/arm64/include/asm/sysreg.h | 17 ++ arch/arm64/include/asm/vectors.h | 73 ++++++ arch/arm64/include/uapi/asm/kvm.h | 5 + arch/arm64/kernel/cpu_errata.c | 385 +++++++++++++++++++++++++++- arch/arm64/kernel/cpufeature.c | 21 ++ arch/arm64/kernel/cpuinfo.c | 1 + arch/arm64/kernel/entry.S | 213 +++++++++++---- arch/arm64/kernel/vmlinux.lds.S | 2 +- arch/arm64/kvm/hyp/hyp-entry.S | 64 +++++ arch/arm64/kvm/hyp/switch.c | 8 +- arch/arm64/kvm/sys_regs.c | 2 +- arch/arm64/mm/mmu.c | 12 +- include/linux/arm-smccc.h | 5 + virt/kvm/arm/psci.c | 34 ++- 27 files changed, 912 insertions(+), 75 deletions(-) create mode 100644 arch/arm64/include/asm/vectors.h