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
|
Home