On Wed, Jan 13, 2010 at 7:43 AM, J.C. Roberts <list-...@designtools.org>
wrote:
> On Tue, 12 Jan 2010 10:41:15 +0200 "Ciprian Dorin, Craciun"
> <ciprian.crac...@gmail.com> wrote:
>
>> B B So I bet that the initial poster expected an (authoritative) answer
>> that should have came in the form of an advice based on experience or
>> at least something useful... (Not lmgtfy, which I'm sure he already
>> did, but did not found a good enough answer (as in authoritative)...)
>
> You are missing the point. Virtualization has been discussed to death
> for *YEARS* and all of it is in the misc@ list archives.
Sorry didn't knew... (I should have checked the mailing list...)
> Here's the short version of those years of discussion:
>
> 1.) Since you can't trust the skill of most developers to write a
> perfectly secure operating systems, trusting them to write a perfectly
> secure software emulation of hardware is insane.
Sorry, but you guys from OpenBSD have proved that you <<can trust
the skills of **some** developers to write an __supposed__ perfectly
secure operating system>>, so why not trust other developers to write
a __supposed__ secure software emulation with the help of hardware.
(Let me say it more simply: we have trust in you, but why don't you
have the disposition to trust in others?)
> 2.) If systems and application software runs fine on real hardware, but
> fails to run on emulated/virtualized hardware, then the problem is in
> the virtualization software. --In other words, take questions and
> complaints to the vendor of your virtualization software.
Agree. This is the same as with software: if software runs
perfectly on one version of OpenBSD, but not on another it does not
mean that its the fault of the new version. (But Xen is not all about
emulation, it cooperates with the guest kernel, so in this case the
blame could be on both sides.)
> 3.) Many of the benefits you gain by running a stable and secure
> operating system like OpenBSD are lost when you run it as a "guest" on
> top of some other insecure "host" operating system.
This is only true if either:
* there is a security bug in the virtualization software (highly
improbable, and maybe easibly fixed);
* you let the host operating system front the Internet; (but you
could just filter out all the traffic from the exterior to the host,
and use one of the guests (OpenBSD) as a gateway);
> 4.) Most Virtualization Software fails to emulate hardware perfectly.
(Again we are not speaking of emulation, we are speaking of
cooperation between the hypervisor and the guest kernel.)
> 5.) Most Virtualization Software expects the "host" operating system to
> have specific features, and hence, it's not easily portable, or it is
> not portable at all.
>
> 6.) Most Virtualization Software wants to use fancy hardware features
> and/or have direct access to hardware. If your vitualization software
> is by-passing the restrictions enforced by the "host" operating system,
> then the "host" operating systems is not able to do it's job.
No, (in general) the requirement of virtualization is not to
bypass the restrictions imposed by OS to hardware.
> Virtualization can be very useful in certain situations, yet you not
> only need to fully understand and accept the implications and risks of
> virtualization, but *you* also need to test it in *your* environment to
> determine if it meets *your* requirements. Anything less is irrelevant!
One important use of virtualization software (like Xen for
example), is to allow experimentation. For example I don't have 4
pieces of hardware to be able to also host a Linux server (for
personal stuff), experiment with OpenBSD or Plan9, and also give one
of my friends a small VPN and download host. So I use Xen and turn one
computer into many. (As you see it's not the security aspect I'm
interested but the consolidation aspect...) (Yes very lame I know, but
sometimes money does beat security...)
> If you're too lazy to do the weeks or months of research work on your
> own, then you really should not use virtualization. Unfortunately, most
> people just believe the constant bullshit from the virtualization
> vendors, or ask irrelevant questions on various mailing lists.
(I hope I've touched this subject above.)
> Lastly, Bret Lambert is one of the OpenBSD developers, so you can
> consider his "lmgtfy" reply as "authoritative" --He's humorously telling
> you to do your own work. There is no other way.
> --
> J.C. Roberts
Thanks for the time and the responses,
Ciprian.
