tag:blogger.com,1999:blog-8388514.post3849905137248545717..comments2011-11-20T18:01:13.904-08:00Anthony Liguorihttp://www.blogger.com/profile/14951928049865210496noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-8388514.post-7421583561641597422011-11-20T18:01:13.904-08:002011-11-20T18:01:13.904-08:00Awesome post! I have gradually become fan of your information and would like to suggest putting some new updates to make it more effective.cheap printinghttp://www.leafletprinting.co.uknoreply@blogger.comtag:blogger.com,1999:blog-8388514.post-37970982956384006262011-10-26T19:59:32.673-07:002011-10-26T19:59:32.673-07:00This has been so enlightening. I´ve discovered your website today and i´m enjoying it so much. It is full of smart advices!organic pet foodhttp://www.jemsnaturalliving.com/index.php/all-natural-pet-food-necessitiesnoreply@blogger.comtag:blogger.com,1999:blog-8388514.post-42679883672205615082011-06-27T23:53:26.286-07:002011-06-27T23:53:26.286-07:00KVM fits the definition of a Type 1 hypervisor for two reasons: I&#39;st- it runs in kernel mode on bare metal and uses a hardware virtualizer. II&#39;nd, KVM guests spend almost all their time running in direct execution mode.Rackmount LCDhttp://www.rackmountsales.com/noreply@blogger.comtag:blogger.com,1999:blog-8388514.post-91397781421317218142010-04-20T14:27:27.963-07:002010-04-20T14:27:27.963-07:00Hmm ... I found this post after reading the wiki entry on hypervisors and was curious about the practical reasons for making a distinction between both types of hypervisors. From what I can see, the distinction is at best of academic interest?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8388514.post-74381573477115041962008-12-06T17:55:00.000-08:002008-12-06T17:55:00.000-08:00As far as this security debate about gaining access to type-2 hypervisors and being able to control both the host and all guests is what I find semantic since if you gain controlling access to a type-1 hypervisor you can have the same level of control. As stated, currently accepted definitions of a type-1 hypervisor still includes software running in a read/write fashon, which means it can be hacked and controlled, meaning that such a scenario is not limited to only type-2 hypervisors, nor makes such access any more a threat when comparing types of hypervisors.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8388514.post-76916093891700190732008-07-24T10:03:00.000-07:002008-07-24T10:03:00.000-07:00Type 1 should be BIOS level hypervisor, and not at Linux kernel which is an OS kernel too. If someone programmed a BIOS level hypervisor, then it is an absolute Type 1 hypervisor. I think product such as Xen (runs on linux) is just like a hypervisor software runs on Windows Server 2008 Core or just plain Windows Server Hyper-V which is on TYpe 2.Mindframewww.mindframehacker.comnoreply@blogger.comtag:blogger.com,1999:blog-8388514.post-5576739533889906792007-12-20T17:31:00.000-08:002007-12-20T17:31:00.000-08:00Hi, Anthony -<BR/><BR/>I think we are disconnecting. It is rare with any sort of classification system not to have exceptions. I am unfamiliar with KVM but am fine with exceptions. <BR/><BR/>What I was hoping for was a useful alternative to Type I/II that addresses the security differences I described. I suspect security isn't your bag, which is fine since this was a random hit on a google search for me.<BR/><BR/>Note that one of your colleagues from IBM uses these types in his extensive collection of attributes about the main players over at it20.com.<BR/><BR/>I won't bother you any more.<BR/><BR/>Regards,<BR/><BR/>Pete LindstromAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-8388514.post-51654550524245158982007-12-19T20:36:00.000-08:002007-12-19T20:36:00.000-08:00Hi Pete,<BR/><BR/><I>It seems pretty straightforward to me - in one scenario, user processes are running on the physical system at the same level as hypervisor processes with no need to "escape" a VM first. In the other scenario, user processes run in one or more VMs.</I><BR/><BR/>When you say, "user", you mean that some user can log into the host and run arbitrary things. However, it's very important to realize that there's no requirement with something like KVM that the host have anything more than a single init process than launches guests. In this case, there would have to be a control partition that interacts with this "single init process" but no other process could actually launch in the host environment.<BR/><BR/>So in this model, I believe KVM qualifies as a "Type I" hypervisor by your definition. However, how can KVM be both a Type I and Type II hypervisor? <BR/><BR/>This all gets back to my original point. The terms "Type I" and "Type II" are really meaningless outside the context of discussing the formal requirements for full virtualization of a hardware/software system. This is, in my opinion, a strict interpretation of the Goldberg/Popek paper and the only one that makes sense.Anthony Liguorihttp://www.blogger.com/profile/14951928049865210496noreply@blogger.comtag:blogger.com,1999:blog-8388514.post-84332068059958916902007-12-18T11:59:00.000-08:002007-12-18T11:59:00.000-08:00Anthony -<BR/><BR/>I'm not sure I understand how you've interpreted Goldberg - his definition is pretty basic and your concerns seem like semantic ones. <BR/><BR/>I do agree, however, that things are ambiguous today (and poised to get even more ambiguous in the near term)with diffs btwn type I/II and also VMM/hypervisor for that matter.<BR/><BR/>It seems pretty straightforward to me - in one scenario, user processes are running on the physical system at the same level as hypervisor processes with no need to "escape" a VM first. In the other scenario, user processes run in one or more VMs.<BR/><BR/>While the micro/macro argument can be independent of virtualization, it is not clear to me how the reverse could be true, so I still assume that it is applicable.<BR/><BR/>I welcome a better distinction or way to talk about these differences with more clarity, but have only seen type I/II and VMM/hypervisor used in academic literature and the trade press.<BR/><BR/>I don't see how you can say it doesn't matter from a security perspective, especially given all the attention that being "isolated" gets (my interpretation of Type II means there is user space that doesn't get isolated the same way).<BR/>I believe this is highly applicable to use cases where virtual machines are being deployed/used on the client-side.<BR/><BR/>Pete LindstromAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-8388514.post-68032808533834879352007-12-17T20:10:00.000-08:002007-12-17T20:10:00.000-08:00Hi Pete,<BR/><BR/>I think you've just highlighted the biggest misconception around--that's Type I and Type II have anything to do with any real product out there.<BR/><BR/>Goldberg differentiated between hardware requirements to allow full virtualization and then the requirements of a software interface. This has nothing to do with "hypervisors".<BR/><BR/>What you're really trying to argue is that virtualization is better done with a micro-kernel than a monolithic kernel because of the inherently smaller TCB. I won't get into the whole micro/macro kernel debate here but suffice to say that that argument is totally independent of virtualization.Anthony Liguorihttp://www.blogger.com/profile/14951928049865210496noreply@blogger.comtag:blogger.com,1999:blog-8388514.post-63723556959958470822007-12-17T14:09:00.000-08:002007-12-17T14:09:00.000-08:00Anthony -<BR/><BR/>Delineating type 1 vs. type 2 hypervisors goes at least as far back as Robert Goldberg's Harvard Thesis in 1973 - Architectural Principles of Virtual Computer Systems. I am not sure I see how you can come to the conclusion that the difference is insignificant.<BR/><BR/>From a security perspective, I think there are pretty important differences. If you compromise a host OS (type 2), you can gain access to both VMs and hypervisor processes and code. While this may be possible in a type 1 environment, there is a significantly smaller attack surface to contend with.<BR/><BR/>Pete LindstromAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-8388514.post-60137074903973644672007-10-09T08:55:00.000-07:002007-10-09T08:55:00.000-07:00Well, if you modify any project enough<BR/>it can be turned into something else. I'm<BR/>not sure that's meaningful.Johnhttp://www.blogger.com/profile/06852503973350767763noreply@blogger.comtag:blogger.com,1999:blog-8388514.post-15096140122156165082007-10-08T18:10:00.000-07:002007-10-08T18:10:00.000-07:00It really depends on how you define "control" OS. With KVM, the host is Linux. With Xen, the host is a custom microkernel. You certainly could have an extremely small host userspace with KVM and launch a single guest with access to all hardware and the ability to launch other guests. This guest would be then be the "control" OS and you could, in theory, reboot it.<BR/><BR/>So it's more a configuration issue than anything. It's not something fundamental to the VMM technology.Anthony Liguorihttp://www.blogger.com/profile/14951928049865210496noreply@blogger.comtag:blogger.com,1999:blog-8388514.post-59543700485942693972007-10-08T17:25:00.000-07:002007-10-08T17:25:00.000-07:00I must admit I never knew everyone was<BR/>mis-using the terms, interesting. For<BR/>me the distinction is really about one<BR/>thing: if the "control" OS is rebooted,<BR/>do the VMs continue to exist in any<BR/>meaningful way?<BR/><BR/>This makes LDOMs (and Xen, if they<BR/>hadn't failed at the implementation) type-1, and KVM etc. type-2. I suppose it's kind of unfortunate the meaning has changed but I'm sure you know by now that complaining about shifts in meaning is always, always, futile :)Johnhttp://www.blogger.com/profile/06852503973350767763noreply@blogger.com