[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] vmx: last branch recording MSR emulation



>>> Keir Fraser <keir@xxxxxxxxxxxxx> 09.08.07 14:49 >>>
>On 9/8/07 13:47, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> Finally, with LBR registers being used in Xen itself (optionally), you'd
>> expose
>> hypervisor internal information to HVM's, which is generally considered a
>> security risk.
>
>Well, that's due to the current rather stupid policy of defaulting HVM MSR
>reads to read the native MSR. MSR handling needs unifying and a big clean
>up, just like has now happened to the control registers. Same for CPUID
>(which has a similarly stupid policy to that of MSR reads).

I've been hearing you say this for quite a while, and from an abstract point of
view I would also agree. However, other than the control registers MSRs and
CPUID really have quite a bit of vendor specifics, and hence I'd be afraid that
unification here would not result in much better code. (An example of things
incorrectly done on both sides is the recent insertion of MSR_K8_* cases in
VMX code - how would an Intel CPU ever have K8-specific MSRs?)

The default of reading native registers is of course very questionable, but
it's been that way for so long that I didn't dare to kill this, as I'm 
suspecting
that booting some, if not all, OSes without this would not work. And the then
likely resulting incrementally adding of emulation for individual MSRs on an
empirical basis is something that I consider, as pointed out on other similar
occasions like the MMIO instruction decoder, very wrong for code that is no
longer in a proof-of-concept state.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.