On 08.10.2025 15:04, Andrew Cooper wrote: > On 08/10/2025 1:08 pm, Jan Beulich wrote: >> In preparation to add support for the CMCI LVT, which is discontiguous to >> the other LVTs, add a level of indirection. > > It's not the only extra LVT. > > AMD have Extended LVTs, which are necessary if we want to get virt-PMU > working. > > https://sandpile.org/x86/apic.htm is a recent addition which covers all > of this.
Hmm, yes, but these will need taking care of separately anyway. >> Rename the prior >> vlapic_lvt_mask[] while doing so (as subsequently a 2nd array will want >> adding, for use by guest_wrmsr_x2apic()). >> >> Signed-off-by: Jan Beulich <[email protected]> > > I'm afraid this introduces a vulnerability. > > APIC_LVR is a toolstack-provided value. Nothing bounds checks the > MAX_LVT value in it AFAICT, and previously this did not matter (from a > security point of view at least) because the loop bounds were constant. Oh, right, I should have thought of that. As you don't suggest anything, I'm going to simply add a check that the incoming value matches the one that's there already. There will still be a quirk due to MCG_CAP and APIC registers being loaded separately, with no defined ordering between them. Within our current infrastructure I don't really see how to deal with this kind of inter-dependency. Jan
