[cap-talk] Virtual Machine Based Rootkits

[David Hopwood]

Jed at Webstart wrote:
>>At 03:13 PM 8/3/2006, Karp, Alan H wrote:
>>David Hopwood wrote:
>>
>>>That's not quite accurate; most VMMs are detectable, and
>>>AFAIK all VMMs that run on x86 hardware (VT, Pacifica or otherwise)
>>>are detectable.
>>
>>That's because x86 is not fully virtualizable.

No, it isn't just because of that. Most VMMs are detectable regardless of
whether the architecture is fully virtualizable or not.

An architecture is a specification, with some aspects that are nondeterministic
or unspecified. As long as the machine provided by the VMM meets the
specification (or at least, the parts of it relied on by supported guest
OSes and their user programs), then it works sufficiently well as a VMM,
regardless of whether it can be distinguished from a hardware implementation.

There is usually no attempt to make a VMM work *exactly* like the hardware.
Even if it were possible, what would be the point? Different hardware
implementations of an architecture (even just different steppings of
essentially the same chip) are distinguishable from each other, so why should
software implementations not be distinguishable?

So, if a malware writer wants to create a VMM that will not be detected,
they cannot rely on any existing VMM implementation being *undetectable*.
Rather, they will have to make assumptions about what detection methods
are likely to be used, and try to circumvent those.

>>Rutkowska is working on architectures that are.
> 
> Huh?  I thought the VT and Pacifica versions of "x86" are fully
> virtualizable.  Is that not true? My understanding is that all it
> takes to be "fully virtualizable" is to have all privileged operations
> trap in "user" mode.

That is the definition of "fully virtualizable", yes. However, despite
the name, "full" virtualizability is a rather weak property -- because
it does not imply that the processor behaves in a way that would be most
useful to a VMM when executing code in user mode. In principle, the same
code may behave quite differently in user mode than in kernel mode, so
that it is difficult for the former to emulate the latter, even though
the architecture is strictly speaking "fully virtualizable". Also, there
could be hardware features that are inherently difficult to emulate even
if the VMM is able to trap on them. If these are deprecated or very
uncommonly used features, a VMM writer might reasonably decide not to
implement them.

There are some x86 features that VT and Pacifica provide little or no
help in virtualizing. One of these is "V86 mode" (the mode used by a
protected-mode OS to run old 16-bit programs): a VMM must emulate this
mode "the hard way", using an interpreter or dynamic compiler. Another
is the VT/Pacifica-specific features themselves -- there was no
attempt (and it would have been much more complex) to make these
architectures *recursively* virtualizable.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>