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 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
To recover guard on NULL dereference, a simple change is to
use a different L4 entry...
It’s a bit concerning there is something mapped there,
since it is the NULL page and will prevent us catching NULL
On 5/2/08 09:13, "Xin, Xiaohui"
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()
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
Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
To: Xin, Xiaohui;
Subject: Re: [Xen-devel][PATCH]Fix a
bug in sahf emulation in real mode code
hadn’t hit very many SAHF instructions just yet! Or was this actually
causing weird behaviours for some OSes?
5/2/08 07:35, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx>
patch fixes a bug in the sahf emulation in real mode
Signed-off-by Xin Xiaohui
Signed-off-by Tian Kevin
Xen-devel mailing list