From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: [PATCH] x86: guest_walk_tables() should check invalid bits on large page entries Date: Mon, 28 Mar 2011 09:11:59 +0100 Message-ID: <4D905EEF02000078000389A0@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part2804F8DF.1__=" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2804F8DF.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The PSE handling doesn't check bits 1...8 (or 1...9 for non-PAE guests) being zero, thus allowing bad (not 2Mb/4Mb aligned) large pages to be handled. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/guest_walk.c +++ b/xen/arch/x86/mm/guest_walk.c @@ -231,9 +231,28 @@ guest_walk_tables(struct vcpu *v, struct /* _PAGE_PSE_PAT not set: remove _PAGE_PAT from flags. */ flags &=3D ~_PAGE_PAT; =20 +#define GUEST_L2_GFN_ALIGN (1 << (GUEST_L2_PAGETABLE_SHIFT - \ + GUEST_L1_PAGETABLE_SHIFT)) + if ( gfn_x(start) & (GUEST_L2_GFN_ALIGN - 1) & ~0x1 ) + { +#if GUEST_PAGING_LEVELS =3D=3D 2 + /* + * Note that _PAGE_INVALID_BITS is zero in this case, = yielding a + * no-op here. + * + * Architecturally, the walk should fail if bit 21 is set = (others + * aren't being checked at least in PSE36 mode), but we'll = ignore + * this here in order to avoid specifying a non-natural, = non-zero + * _PAGE_INVALID_BITS value just for that case. + */ +#endif + rc |=3D _PAGE_INVALID_BITS; + } + /* Increment the pfn by the right number of 4k pages. =20 - * The ~0x1 is to mask out the PAT bit mentioned above. */ - start =3D _gfn((gfn_x(start) & ~0x1) + guest_l1_table_offset(va));= + * Mask out PAT and invalid bits. */ + start =3D _gfn((gfn_x(start) & ~(GUEST_L2_GFN_ALIGN - 1)) + + guest_l1_table_offset(va)); gw->l1e =3D guest_l1e_from_gfn(start, flags); gw->l1mfn =3D _mfn(INVALID_MFN); }=20 --=__Part2804F8DF.1__= Content-Type: text/plain; name="x86-guest-walk-pse-invalid.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-guest-walk-pse-invalid.patch" The PSE handling doesn't check bits 1...8 (or 1...9 for non-PAE guests)=0Ab= eing zero, thus allowing bad (not 2Mb/4Mb aligned) large pages to = be=0Ahandled.=0A=0ASigned-off-by: Jan Beulich =0A=0A--= - a/xen/arch/x86/mm/guest_walk.c=0A+++ b/xen/arch/x86/mm/guest_walk.c=0A@@ = -231,9 +231,28 @@ guest_walk_tables(struct vcpu *v, struct=0A = /* _PAGE_PSE_PAT not set: remove _PAGE_PAT from flags. */=0A = flags &=3D ~_PAGE_PAT;=0A =0A+#define GUEST_L2_GFN_ALIGN (1 << (GUEST_L2_PA= GETABLE_SHIFT - \=0A+ GUEST_L1_PAGETABLE_S= HIFT))=0A+ if ( gfn_x(start) & (GUEST_L2_GFN_ALIGN - 1) & ~0x1 = )=0A+ {=0A+#if GUEST_PAGING_LEVELS =3D=3D 2=0A+ /*=0A+ = * Note that _PAGE_INVALID_BITS is zero in this case, yielding = a=0A+ * no-op here.=0A+ *=0A+ * = Architecturally, the walk should fail if bit 21 is set (others=0A+ = * aren't being checked at least in PSE36 mode), but we'll ignore=0A+ = * this here in order to avoid specifying a non-natural, = non-zero=0A+ * _PAGE_INVALID_BITS value just for that = case.=0A+ */=0A+#endif=0A+ rc |=3D _PAGE_INVALID_BIT= S;=0A+ }=0A+=0A /* Increment the pfn by the right number of = 4k pages. =0A- * The ~0x1 is to mask out the PAT bit mentioned = above. */=0A- start =3D _gfn((gfn_x(start) & ~0x1) + guest_l1_table_= offset(va));=0A+ * Mask out PAT and invalid bits. */=0A+ = start =3D _gfn((gfn_x(start) & ~(GUEST_L2_GFN_ALIGN - 1)) +=0A+ = guest_l1_table_offset(va));=0A gw->l1e =3D guest_l1e_from_= gfn(start, flags);=0A gw->l1mfn =3D _mfn(INVALID_MFN);=0A } =0A --=__Part2804F8DF.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__Part2804F8DF.1__=--