[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Tue, 18 Mar 2008 08:46:03 +0000
  • Delivery-date: Tue, 18 Mar 2008 01:47:13 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AciIBgTbUv10I0dQRSWDUmWTZvY2cwAA2Hm8AABl+TAAA81x3gABF9GAAACYnvIAHcI14AAPIBRj
  • Thread-topic: [Xen-devel] [PATCH]Fix the bug of guest os installationfailure and win2k boot failure

We're on the same page now, except that I realised there is a TOCTTOU race
introduced by relying on the processor's permission check while re-fetching
the instruction from scratch in the hypervisor. This allows, in theory, a
multi-threaded process to rewrite the I/O-port accessing instruction after
the processor has fetched the instruction, and validated the access, but
before Xen re-fetches the instruction for emulation. Possibly we do not care
too much about this, since the process must already have some
I/O-port-access permissions, but equally I don't expect we fall into the
TSS-bitmap check all that often, it's not that hard to implement, and then
we are definitely safe.

 -- Keir

On 18/3/08 01:49, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> wrote:

> Hi, Keir, 
>     Now I understand what you mean. read_io, write_io, inject_hw_exception
> callbacks are not defined within the multi.c. So I/O instructions will not be
> emulated by it. Thanks for your comments. And the new patch is attached.
> 
> Best regards,
> -- Dongxiao
> 
> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: 2008年3月17日 19:21
> To: Cui, Dexuan; Xu, Dongxiao; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH]Fix the bug of guest os installationfailure
> and win2k boot failure
> 
> On 17/3/08 11:16, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> wrote:
> 
>>> I think you misunderstand. The shadow emulator *never* emulates I/O
>>> port accesses or exception deliveries. Those callback functions are
>>> simply not implemented and are left as NULL.
>> Those callback functions -- what are they? -- do you mean the following?
>> static struct x86_emulate_ops hvm_emulate_ops = {
>>     ....
>>     .read_io       = hvmemul_read_io,
>>     .write_io      = hvmemul_write_io,
>> ...
>> };
> 
> Yes indeed. Also, crucially, .inject_hw_exception. Without that
> x86_emulate() is unable to inject any exception into the guest, and will
> instead return X86EMUL_UNHANDLEABLE.
> 
>  -- Keir
> 
> 



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.