On 24 November 2010 19:34, SJP Lists <sjp.lists@flashbsd.net> wrote:
quoted text
> On 24 November 2010 01:12, Brad Tilley <brad@16systems.com> wrote:
>> carlopmart wrote:
>>
>>>  Advantages are very clear for me: provisioning, administration tasks,
>>> etc ... But I will to know disadvantages. What is your opinion from the
>>> point of view of security?
>>
>> I use virtualization for many things (mainly for the productivity
>> advantages that you list), but it has always bothered me because
>> virtualization is pretending.
>>
>> In Java, for example, the VM pretends about a lot of things that are not
>> true in the physical world. This makes it easy and convenient for
>> programmers. The problem is that they come to believe that the pretend
>> things are real and then make assumptions (when dealing with physical
>> machines) that are incorrect.
>
> Yes, the virtualization of the programmable interval timer is one
> example where pretending makes for some crazy situations.  Only a few
> nights ago, I patched a Debian ESXi 4.1 VM and when it rebooted it
> would not boot, stating that the PIT was not functioning.
>
> Time keeping is weird in x86 virtualization.  I've seen Windows ESX
> VM's with time that not only stops and then suddenly jumps forwards,
> but even goes back!
>
> Seen the madness of a virtualized NTP server?  VMware have a
> Timekeeping whitepaper that is sugar coated to say the least.
>
> All anyone need do is watch the advisories for VMware to soon realise
> that the choice is a trade off, where the drawbacks (security and
> weirdness) are as big as the benefits.
>
> And again, I say look at the Google research that found all
> implementations vulnerable.  If security matters less than the cost of
> dedicated hardware, then use it.

Oh and another thing, a colleague of mine and myself noticed on
separate occasions with different VM's and OS' under what probably
would have been ESX 3.5 at the time, that a scheduled task would not
run if the console was not open / have focus!

I also noticed that while time appeared to completely stand still in a
Windows VM under ESX, it could be made to tick again by generating
lots of interrupts.  Vigorous mouse movement barely made a difference,
however performing a file system search got the clock counting faster
than realtime.

I now wonder if this is due to dropped interrupts or lost ticks as
VMware refer to in [1], a document which describes the time keeping
weirdness that needs to be dealt with to get around the fact that the
x86 architecture was not designed from the ground up for this type of
virtualization.

So what other weird complexities do that need to employ to get around
other quirks?

Sorry, but as far as I am concerned, virtualization presents a new and
complex attack surface that no guest OS could control.  So if you're
using OpenBSD for a security focused role, I'd forget x86
virtualization.


Shane

[1] http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf