On Wed, 13 Jan 2010 08:31 +0200, "Ciprian Dorin, Craciun" <ciprian.crac...@gmail.com> wrote: > 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?)
Very few have demonstrated that they can be trusted. BTW, *any* virtualization software written for i386 is always going to have the potential for compromise because of the inherent flaws in that architecture. It was *not* designed with virtualization in mind. > > > > 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.) Wrong. If it works on real hardware and fails in virtualization the virtualization software is *always* to blame. > > > > 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); BWAAAAHAHHAHAHAHAHH. Have you ever actually worked with any virtualization software? There have been many documented security bugs in every virtualization software. Try Securityfocus or your favorite search engine. > * 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. BWAAAHAHAHAHAHAH! It *should* be a requirement, but rarely *is*. > > > > 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...) This is actually very true. But you need to be very aware of where it does and where it doesn't.
