From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v6 24/29] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs Date: Wed, 30 Sep 2015 13:50:59 +0100 Message-ID: <560BDAB3.70701@citrix.com> References: <1441368548-43465-1-git-send-email-roger.pau@citrix.com> <1441368548-43465-25-git-send-email-roger.pau@citrix.com> <5600420C02000078000A4234@prv-mh.provo.novell.com> <5609664D.8060604@citrix.com> <560A555402000078000A6625@prv-mh.provo.novell.com> <560A6124.2090404@citrix.com> <560A7EFA02000078000A6846@prv-mh.provo.novell.com> <560A6714.7060303@citrix.com> <560A851202000078000A68AA@prv-mh.provo.novell.com> <560A69DB.9060505@citrix.com> <560A888D02000078000A68DD@prv-mh.provo.novell.com> <560A99C0.5050202@citrix.com> <560ACA7302000078000A6C93@prv-mh.provo.novell.com> <560AB5C6.6080404@citrix.com> <560AD65F02000078000A6CF6@prv-mh.provo.novell.com> <560AC129.1040309@citrix.com> <560BCF9102000078000A7016@prv-mh.provo.novell.com> <560BC970.1060300@citrix.com> <560BE9A502000078000A716C@prv-mh.provo.novell.com> <560BD345.5090301@citrix.com> <560BF31D02000078000A71BF@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZhGqg-0004Le-CQ for xen-devel@lists.xenproject.org; Wed, 30 Sep 2015 12:51:06 +0000 In-Reply-To: <560BF31D02000078000A71BF@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , =?windows-1252?Q?Roger_Pau_Monn=E9?= Cc: George Dunlap , xen-devel@lists.xenproject.org, Stefano Stabellini , Ian Campbell , Tim Deegan List-Id: xen-devel@lists.xenproject.org On 30/09/15 13:35, Jan Beulich wrote: >>>> On 30.09.15 at 14:19, wrote: >> El 30/09/15 a les 13.54, Jan Beulich ha escrit: >>>>>> On 30.09.15 at 13:37, wrote: >>>> /* >>>> * Using VCPU_HVM_MODE_64B implies that the vCPU is launched >>>> * directly in long mode, so the type of the cached part >>>> * of the TR register is set to describe a 64-bit TSS (Busy). >>>> * The cached part of the CS register will also have the L bit >>>> * set (64-bit code segment). >>> I'd leave out mentioning TR here (or else it'll be odd not to mention >>> e.g. LDTR too). Perhaps just "..., so the cached parts of the segment >>> registers get set to match that environment"? >> That sounds fine. I'm going to update the patch and the FreeBSD part in >> order to test it. Since we also spoke about adding sanity checks, I >> wonder whether I should add those checks now, or leave them for a later >> patch. IMHO those checks are only useful for developers. > Fundamentally, checks done here should include everything that > would otherwise lead to the domain getting killed due to failed > VMENTRY. I.e. both sets below may need extending. > >> For VCPU_HVM_MODE_32B: >> - rIP within CS limit. >> - Check that CS.DPL == SS.DPL. >> - rSP within SS limit. >> >> TBH I don't think we should enforce the last two checks, starting with >> an invalid stack should be fine as long as the user knows it. Maybe >> print a warning/debug message in this case? > I wouldn't check ESP at all. As to the two DPLs to, I don't think you > could launch a guest with these disagreeing. > >> For VCPU_HVM_MODE_64B: >> - Check that cr0 has paging enabled. >> - Check that cr4 has pae enabled. >> - Check that efer has the LMA/LME bits set. >> >> Those should be always enforced for long mode. > Agreed, plus RIP being canonical. LMA is a read-only bit with inconsistent semantics between Intel and AMD. In particular, on Intel, LMA is not visible until LME has been set, which means that the typical setup of mov $MSR_EFER, %ecx rdmsr bts $_EFER_LME, %eax wrmsr Causes Xen to observe LME but not LMA when intercepting the wrmsr. I think all you need to check is CR0.PG, CR4.PAE and EFER.LME (and guest X86_FEATURE_LM). LMA will then leak through in subsequent rdmsr's ~Andrew