[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 10:47:17 +0000
  • Delivery-date: Tue, 18 Mar 2008 03:48:37 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AciIBgTbUv10I0dQRSWDUmWTZvY2cwAA2Hm8AABl+TAAA81x3gABF9GAAACYnvIAHcI14AAPIBRjAAE/9bAAAW0NBgAAbQgAAAEh33c=
  • Thread-topic: [Xen-devel] [PATCH]Fix the bug of guest os installationfailure and win2k boot failure

That example is not a security hole, though. The worst the process can do is
shoot itself in the foot. The time slot exists for execution by the real
processor too, does it not?

 -- Keir

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

> Hi, Keir, 
>     I think it is a common problem because there is always a time slot for all
> instruction emulation. In the time slot, an attacker could replace the old
> instruction with a new one. Just for example, if one thread issues a "push
> reg" operation, and during the time slot, another thread can replace it with a
> "pop reg" operation. Because there is no mechanism for us to check whether the
> instruction has been changed during that time slot. This may cause the guest
> OS doesn't work well. So, I think this kind of issue may not only happen with
> I/O emulations. :-)
>     
> Best regards,
> -- Dongxiao
> 
> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: 2008年3月18日 18:03
> To: Xu, Dongxiao; Cui, Dexuan; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH]Fix the bug of guest os installationfailure
> and win2k boot failure
> 
> On 18/3/08 09:35, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> wrote:
> 
>>     Do you mean that in a multi-thread process, one thread issues an I/O
>> operation, and in the time slot that just after the processor has fetched the
>> instruction, validated the access, but before Xen re-fetches the instruction
>> for emulation, another thread steals that I/O instruction and replace it with
>> a new one? Maybe we can regard it as a kind of attack...
> 
> We could regard it as that, since that is what it would be. :-)
> 
>>     This could be happen in theory, but I think other instruction emulation
>> may also have this problem.
> 
> Which other instruction emulations? Can you give an example?
> 
>> In your last sentence, do you mean that we still
>> need to do an entire I/O permission check (including CPL, IOPL, and TSS I/O
>> bitmap) in x86_emulate() for safety consideration? Thanks! :-)
> 
> Yes. Like I said: the CPL-IOPL check is very cheap, the TSS bitmap check is
> a little more expensive but probably relatively rare. And in any case the
> I/O port access latency is largely dominated by the VMEXIT/VMENTRY times.
> Also the devices we emulate are mostly managed by mmio.
> 
>  -- 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®.