On Mon, 8 Feb 2021 at 15:32, Will Deacon <w...@kernel.org> wrote: > > Hi Marc, > > On Mon, Feb 08, 2021 at 09:57:09AM +0000, Marc Zyngier wrote: > > 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. >
Not just cache invalidation - BSS gets wiped again as well. -- Ard.
