Re: [PATCH v7 00/23] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth
From: Marc Zyngier <maz@kernel.org>
Date: 2021-02-08 15:13:25
Also in:
kvmarm, lkml
Hi Will, On 2021-02-08 14:32, Will Deacon wrote:
Hi Marc, On Mon, Feb 08, 2021 at 09:57:09AM +0000, Marc Zyngier wrote:quoted
It recently came to light that there is a need to be able to override some CPU features very early on, before the kernel is fully up and running. The reasons for this range from specific feature support (such as using Protected KVM on VHE HW, which is the main motivation for this work) to errata workaround (a feature is broken on a CPU and needs to be turned off, or rather not enabled). This series tries to offer a limited framework for this kind of problems, by allowing a set of options to be passed on the command-line and altering the feature set that the cpufeature subsystem exposes to the rest of the kernel. Note that this doesn't change anything for code that directly uses the CPU ID registers.I applied this locally, but I'm seeing consistent boot failure under QEMU when KASAN is enabled. I tried sprinkling some __no_sanitize_address annotations around (see below) but it didn't help. The culprit appears to be early_fdt_map(), but looking a bit more closely, I'm really nervous about the way we call into C functions from __primary_switched. Remember -- this code runs _twice_ when KASLR is active: before and after the randomization. This also means that any memory writes the first time around can be lost due to the D-cache invalidation when (re-)creating the kernel page-tables.
Well, we already call into C functions with KASLR, and nothing explodes
with that, so I must be doing something else wrong.
I do have cache maintenance for the writes to the shadow registers, so
that
part should be fine. But I think I'm missing some cache maintenance
around
the FDT base itself, and I wonder what happens when we go around the
loop.
I'll chase this down now.
Thanks for the heads up.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel