Xin, Xiaohui
2008-Feb-05 07:35 UTC
[Xen-devel][PATCH]Fix a bug in sahf emulation in real mode code
The patch fixes a bug in the sahf emulation in real mode code. Signed-off-by Xin Xiaohui xiaohui.xin@intel.com Signed-off-by Tian Kevin <Kevin.tian@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Feb-05 08:46 UTC
Re: [Xen-devel][PATCH]Fix a bug in sahf emulation in real mode code
Obviously we hadn¹t hit very many SAHF instructions just yet! Or was this actually causing weird behaviours for some OSes? -- Keir On 5/2/08 07:35, "Xin, Xiaohui" <xiaohui.xin@intel.com> wrote:> The patch fixes a bug in the sahf emulation in real mode code. > > Signed-off-by Xin Xiaohui xiaohui.xin@intel.com > Signed-off-by Tian Kevin <Kevin.tian@intel.com> > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Xin, Xiaohui
2008-Feb-05 09:13 UTC
RE: [Xen-devel][PATCH]Fix a bug in sahf emulation in real mode code
We got this fix, since we found EPT code cannot boot Windows guest when VMXASSIST is disabled. At first, we were quite curious why shadow can boot the same Windows guest, it should met the same SAHF instructions, which is used in MBR of that Windows image. At the error point, the regs->rflags is 0x202, and Xen search the page table for 0x202. For EPT we did not map the lower end of the monitor page table, that’s why we get hap_page_fault() from the fixup_page_fault() there. And for shadow, seems there is already mapped in the page table, and fortunately the data write to there doesn’t cause any error. But it’s apparently not correct. :-) Thanks Xiaohui ________________________________ From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] Sent: 2008年2月5日 16:47 To: Xin, Xiaohui; xen-devel@lists.xensource.com Subject: Re: [Xen-devel][PATCH]Fix a bug in sahf emulation in real mode code Obviously we hadn’t hit very many SAHF instructions just yet! Or was this actually causing weird behaviours for some OSes? -- Keir On 5/2/08 07:35, "Xin, Xiaohui" <xiaohui.xin@intel.com> wrote: The patch fixes a bug in the sahf emulation in real mode code. Signed-off-by Xin Xiaohui xiaohui.xin@intel.com Signed-off-by Tian Kevin <Kevin.tian@intel.com> ________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Feb-05 09:17 UTC
Re: [Xen-devel][PATCH]Fix a bug in sahf emulation in real mode code
It’s a bit concerning there is something mapped there, since it is the NULL page and will prevent us catching NULL dereferences. -- Keir On 5/2/08 09:13, "Xin, Xiaohui" <xiaohui.xin@intel.com> wrote:> We got this fix, since we found EPT code cannot boot Windows guest when > VMXASSIST is disabled. > At first, we were quite curious why shadow can boot the same Windows guest, it > should met the same SAHF instructions, which is used in MBR of that Windows > image. > At the error point, the regs->rflags is 0x202, and Xen search the page table > for 0x202. For EPT we did not map the lower end of the monitor page table, > that’s why we get hap_page_fault() from the fixup_page_fault() there. > And for shadow, seems there is already mapped in the page table, and > fortunately the data write to there doesn’t cause any error. But it’s > apparently not correct. J > > > Thanks > Xiaohui > > > > From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > Sent: 2008年2月5日 16:47 > To: Xin, Xiaohui; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel][PATCH]Fix a bug in sahf emulation in real mode code > > Obviously we hadn’t hit very many SAHF instructions just yet! Or was this > actually causing weird behaviours for some OSes? > > -- Keir > > On 5/2/08 07:35, "Xin, Xiaohui" <xiaohui.xin@intel.com> wrote: > The patch fixes a bug in the sahf emulation in real mode code. > > Signed-off-by Xin Xiaohui xiaohui.xin@intel.com > Signed-off-by Tian Kevin <Kevin.tian@intel.com> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2008-Feb-05 14:18 UTC
RE: [Xen-devel][PATCH]Fix a bug in sahf emulation in real mode code
We''re also surprised to see such behavior and confused how that mapping gets added into monitor page table. Immediately then we found it''s due to the shadow linear mapping to support 3-on-4 case, where a dummy L3 page is allocated and copied with 4 guest L3 entries. Then ml4e[0] is filled with that dummy L3 frame which satisfying shadow linear mapping, but also allows NULL pointer dereference. Actually for 0x202 case, some IDT entry in guest was touched but that vector is just not used. Ideally this should also cause page fault on 4-on-4 case, but we guess that MBR for 64bit windows may be different with no SAHF used. To recover guard on NULL dereference, a simple change is to use a different L4 entry... Thanks, Kevin ________________________________ From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser Sent: 2008年2月5日 17:17 To: Xin, Xiaohui; xen-devel@lists.xensource.com Subject: Re: [Xen-devel][PATCH]Fix a bug in sahf emulation in real mode code It’s a bit concerning there is something mapped there, since it is the NULL page and will prevent us catching NULL dereferences. -- Keir On 5/2/08 09:13, "Xin, Xiaohui" <xiaohui.xin@intel.com> wrote: We got this fix, since we found EPT code cannot boot Windows guest when VMXASSIST is disabled. At first, we were quite curious why shadow can boot the same Windows guest, it should met the same SAHF instructions, which is used in MBR of that Windows image. At the error point, the regs->rflags is 0x202, and Xen search the page table for 0x202. For EPT we did not map the lower end of the monitor page table, that’s why we get hap_page_fault() from the fixup_page_fault() there. And for shadow, seems there is already mapped in the page table, and fortunately the data write to there doesn’t cause any error. But it’s apparently not correct. :-) Thanks Xiaohui ________________________________ From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] Sent: 2008年2月5日 16:47 To: Xin, Xiaohui; xen-devel@lists.xensource.com Subject: Re: [Xen-devel][PATCH]Fix a bug in sahf emulation in real mode code Obviously we hadn’t hit very many SAHF instructions just yet! Or was this actually causing weird behaviours for some OSes? -- Keir On 5/2/08 07:35, "Xin, Xiaohui" <xiaohui.xin@intel.com> wrote: The patch fixes a bug in the sahf emulation in real mode code. Signed-off-by Xin Xiaohui xiaohui.xin@intel.com Signed-off-by Tian Kevin <Kevin.tian@intel.com> ________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel