Messages in this thread | | | Subject | Re: [PATCH] KVM: VMX: Forbid userspace MSR filters for x2APIC | From | Alexander Graf <> | Date | Tue, 20 Oct 2020 11:48:07 +0200 |
| |
On 20.10.20 11:27, Paolo Bonzini wrote: > > On 19/10/20 19:45, Graf (AWS), Alexander wrote: >>> + * In principle it would be possible to trap x2apic ranges >>> + * if !lapic_in_kernel. This however would be complicated >>> + * because KVM_X86_SET_MSR_FILTER can be called before >>> + * KVM_CREATE_IRQCHIP or KVM_ENABLE_CAP. >>> + */ >>> + for (i = 0; i < ARRAY_SIZE(filter.ranges); i++) >>> + if (range_overlaps_x2apic(&filter.ranges[i])) >>> + return -EINVAL; >> >> What if the default action of the filter is to "deny"? Then only an >> MSR filter to allow access to x2apic MSRs would make the full >> filtering logic adhere to the constraints, no? > > Right; or more precisely, that is handled by Sean's patch that he had > posted earlier. This patch only makes it impossible to set up such a > filter.
What I'm saying is that a "filter rule" can either mean "allow" or "deny". Here you're only checking if there is a rule. What you want to filter for is whether there is a denying rule (including default fallback) for x2apic after all rules are in place.
Imagine you add the following filter:
{ count: 1, default_allow: false, ranges: [ { flags: KVM_MSR_FILTER_READ, nmsrs: 1, base: MSR_EFER, bitmap: { 1 }, }, ], }
That filter would set all x2apic registers to "deny", but would not be caught by the code above. Conversely, a range that explicitly allows x2apic ranges with default_allow=0 would be rejected by this patch.
Alex
Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879
| |