From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/hvm: Further restrict access to x2apic MSRs Date: Fri, 17 Oct 2014 10:00:29 +0100 Message-ID: <5440DAAD.9040808@citrix.com> References: <1413482672-16865-1-git-send-email-andrew.cooper3@citrix.com> <20141017085406.GA30391@u109add4315675089e695.ant.amazon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141017085406.GA30391@u109add4315675089e695.ant.amazon.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: Matt Wilson Cc: Kevin Tian , Feng Wu , Jun Nakajima , Eddie Dong , Donald Dugger , Xen-devel , Jan Beulich , Yang Zhang , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 17/10/14 09:54, Matt Wilson wrote: > On Thu, Oct 16, 2014 at 07:04:32PM +0100, Andrew Cooper wrote: >> The x2apic specification reserves the entire MSR range 0x800-0xbff, while only >> the first 0x3f MSRs have defined purposes. >> >> Xen used to pass this entire range to hvm_x2apic_msr_{read,write}(), but the >> range was restricted somewhat by XSA-108 (c/s 61fdda7ac) to prevent guests >> being able to read pages adjacent to the domheap page backing the vlapic->regs >> array. >> >> While removing the vulnerability, a side effect of XSA-108 was that the MSR >> range 0x900-0xbff fell through the switch statement and ends up reading the >> hosts x2apic range. This behaviour is a problem in general, but specifically >> it turns out that MSRs 0xa00 and 0xa01 are implemented (but undocumented) on >> certain SandyBridge and IvyBridge systems. >> >> Experimentally, no operating system in XenServer's test suite (including all >> versions of Windows currently supported by Microsoft) ever peek at these MSRs, >> even on hosts where some of them are implemented. >> >> Therefore, direct the entire reserved range (0x840-0xbff) unconditionally at a >> side effect of this change is that hvm_x2apic_msr_read() can now no longer >> read beyond the bounds of the vlapic->regs array (which is 1/4 the size of the >> page backing it). > Further, Intel(R) 64 Architecture x2 APIC Specification 2.3.4 states: > > RDMSR and WRMSR operations to reserved addresses in the x2APIC mode > will raise a GP fault. > > Therefore RDMSR returning 0 for MSRs 0x840...0x8ff and not causing a > #GP was also not architecturally correct. > > Reviewed-by: Matt Wilson Ah - I had a nagging feeling I had forgotten to mention something in the commit message. If I need to respin the patch for any reason, I shall include this. If not, perhaps the committer would oblige on my behalf? ~Andrew