Re: [PATCH 1/2] VMware detection support for x86 and x86-64

[Zachary Amsden <zach@vmware.com>]

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