Messages in this thread | | | Subject | Re: [PATCH 1/2] VMware detection support for x86 and x86-64 | From | Zachary Amsden <> | Date | Thu, 25 Sep 2008 13:48:14 -0700 |
| |
On Wed, 2008-09-24 at 22:23 -0700, Alok Kataria wrote: > On Wed, 2008-09-24 at 22:04 -0700, H. Peter Anvin wrote: > > Alok Kataria wrote: > > >>> > > >> You accessed a bloody I/O port! > > >> > > >> If you think it's harmless because it was an IN, you're sorely mistaken. > > > > > > Hi Peter, > > > > > > It would be really helpful if you could explain me when can this go > > > wrong or what kinds of problems can this cause on native hardware. > > > > > > > You accessed an unknown I/O port. > > > > This means you caused an unknown action in an unknown peripheral device. > > > > This could cause ANYTHING to happen.
Peter's right. The hardware device simply sees an I/O request to a port and a read / write. The actual internal implementation may not even see whether it is a R/W, and may do anything. Some of our virtual hardware is activated in strange ways, reads where you would expect writes, etc.
For example, a device made by Exploder Technologies has two ports, 3686, and 3687. Read access to port 3686 returns the status register and any access at all to port 3687 moves the robot arm, activating the thermonuclear self destruct device and destroying the earth. I have such a device in my basement, but I have to be careful not to issue any I/O to port 3687 on it, whether it is writes OR reads.
A less contrived example is a LFSR that returns a new cryptographically random value on every read. Reading a register would cause a state change in the hardware, and this could be fatal to something that requires exact synchronization of tokens, perhaps securID type applications.
All that said, we've never encountered an I/O device that uses this ISA port for anything at all. However, some old broken hardware might misdecode bus addresses and try to service the I/O request anyway. So while it might be an acceptible way for us to use in VMware tools where it only ever makes sense to install in a VM anyway, it could be considered non-appropriate for general kernel application.
The whole backdoor thing is also broken because it requires non-architectural side effects to operate (IN instructions can not arbitrarily change all GPRs). This can confuse applications which are very smart and try to single step over the instruction by emulating it, logging the port I/O, then restoring GPRs to the state before execution and writing the 1 register affected by the IN. Such clever debuggers and profiling tools have been written.
Zach
| |