[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |