[Xen-devel] [PATCH]Fix the bug of guest os installation failure and win2k boot failure

["Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>]

Hi, Keir,

      This patch is to fix the problem of Linux guest installation failure and 
Windows 2000 boot failure.

ÂÂÂÂÂ In the early code, we use vmx_vmexit_handler() -> vmx_io_instruction() 
function to emulate I/O instructions. But now, we use vmx_vmexit_handler() -> 
handle_mmio -> hvm_emulate_one() -> x86_emulate() to emulate I/O instructions. 
Also nowadays, the realmode emulation code walks through the path: 
vmx_realmode() -> realmode_emulate_one() -> hvm_emulate_one() -> x86_emulate().

ÂÂÂÂÂ The I/O handle code in x86_emulate() checks the cpl and iopl value, and 
if cpl > iopl, it will generate a GP fault. This causes Linux guest 
installation failure and Windows 2000 boot failure. I think this check code may 
be not reasonable for two aspects: 

ÂÂÂÂÂ 1. If x86_emulate() is called from vmexit or from realmode emulation, I 
think this line of code is not needed, because:

ÂÂÂÂÂÂÂÂÂÂÂ a). In I/O emulation, the cpu has already checked the cpl, iopl, 
and also the I/O bitmap before vmx_vmexit_handler() is called,
ÂÂÂÂÂÂÂÂÂÂÂ b). For realmode, we shouldn't check the cpl and iopl, because any 
I/O operation is permitted in realmode.

ÂÂÂÂÂ 2. If x86_emulate() is called from multi.c, which emulates up to four 
instructions when dealing with PAE guest page tables. In this condition, the 
check is needed, but it is not correct, it should follow the code as follows, 
which is stated in the Intel SDM:

ãIf (cpl <= iopl)
ã Do I/O operation;
ãElse {
ã If (I/O permission bit for the port == 0)
ã Do I/O operation;
ã Else 
ã Generate GP fault;
ã} 

ÂÂÂÂÂ Now this patch remove the cpl and iopl check in I/O handler code in 
x86_emulate() function. And it checks the four instructions which would be 
emulated by multi.c, if any of them is IN/INS/OUT/OUTS, or REP IN/INS/OUT/OUTS, 
we will break that four-instruction emulation, and let the I/O instruction walk 
through the path of vmx_vmexit_handler() -> handle_mmio -> hvm_emulate_one() -> 
x86_emulate().

      Another way to solve this issue could be that, we put the entire io 
permission check in x86_emulate(), and use a flag to indicate whether we should 
do the check. If x86_emulate() is called by vmexit or realmode emulation, we 
skip this check; if it is called by multi.c, then we do the io permission 
check. But it may be a bit complex for hypervisor to read guest processâs TSS 
and find and check its io bitmap. 

BTW: Why the existence code doesn't check the LOCK prefix (which should cause 
#UD injected to guest)
      
      Welcome for your comment, thanks! 

Signed-off-by: Xu Dongxiao <dongxiao.xu@xxxxxxxxx>

Best Regards,
--Dongxiao

Attachment: io_check.patch
Description: io_check.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel