Re: [Xen-devel] x2APIC MSR range (XSA-108 follow-up)

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

On Mon, Oct 13, 2014 at 8:45 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> All,
>
> during the embargo period of XSA-108 Matt pointed out that restricting
> the emulated MSR range to 0x800-0x8ff isn't necessarily the ultimately
> correct thing to do (as also noted in commit 61fdda7acf's description):
> The x2APIC MSR range really is being specified as 0x800-0xbff, as
> opposed to the range considered for virtualization purposes
> (0x800-0x8ff). In order to determine proper behavior here we'd like to
> get clarification from you, particularly also in the light of probing real
> hardware pointing out the existence of (at least) MSRs 0xa00-0xa02.

The original x2apic patch for Xen was a ported version of the KVM
implementation for x2apic.  Unfortunately, it lacked the changes to
apic_reg_read() to prevent accesses to the reserved registers which is
what led to XSA 108.  The check in KVM is:

+       if (offset > 0x3f0 || !(rmask & (1ULL << (offset >> 4)))) {
+               printk(KERN_ERR "KVM_APIC_READ: read reserved register %x\n",
+                               offset);
+               return 1;
+       }
+

In apic_reg_read() who's logical cousin in Xen would probably be
vlapic_read_aligned().  Having checks closer to the actual access
seems more robust than relying on higher level code to do the right
thing.  Am happy to send a patch if this seems reasonable.

> With what we currently do (kind of supported by their values at least
> not differing across physical CPUs on the probed systems) their values
> are getting passed through to guests. The alternative of forcing #GP
> for accesses to them as one could imply from the spec seems
> undesirable: Guests may imply their existence based on CPU model.

This range is not documented publicly AFAIK so I think this risk is
pretty low.  I think the risk of passing through reserved MSRs that
may one day have security implications is something not to take
lightly either.

Regards,

Anthony Liguori

> Hence the only apparent reasonable alternative would be to provide
> proper virtualization for these registers, requiring to know their
> purpose.
>
> Thanks, Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel