WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] vmx: last branch recording MSR emulation
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Thu, 09 Aug 2007 14:05:37 +0100
Cc: Xin B Li <xin.b.li@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 09 Aug 2007 06:01:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2E0CBF6.13E11%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <46BB28E4.76E4.0078.0@xxxxxxxxxx> <C2E0CBF6.13E11%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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