Hi Oliver, On Thu, 30 Jan 2025 at 21:47, Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > There are a few places where the idreg overrides are read w/ the MMU > off, for example the VHE and hVHE checks in __finalise_el2. And while > the infrastructure gets this _mostly_ right (i.e. does the appropriate > cache maintenance), the placement of the data itself is problematic and > could share a cache line with something else. > > Depending on how unforgiving an implementation's handling of mismatched > attributes is, this could lead to data corruption. In one observed case, > the system_cpucaps shared a line with arm64_sw_feature_override and the > cpucaps got nuked after entering the hyp stub... > I'd like to understand this part a bit better: we wipe BSS right before we parse the idreg overrides, all via the ID map with the caches enabled. The ftr_override globals are cleaned+invalidated to the PoC after we populate them. At this point, system_cpucaps is still cleared, and it gets populated only much later. So how do you reckon this corruption occurs? Is there a memory type mismatch between the 1:1 mapping and the kernel virtual mapping? > Even though only a few overrides are read without the MMU on, just throw > the whole lot into the mmuoff section and be done with it. > This is fine in principle, but I suspect that it could be anywhere as long as it is inside the kernel image, rather than memory like BSS that is part of the executable image but not covered by the file.
