Qubes is based on Xen. There are templates for Fedora, Debian and others. Windows can be a guest VM. Windows as a host is only a theoretical consideration for a theoretical port. [Hypervisor Abstraction Layer (HAL)]
What convinced me of Qubes is, that for Linux a single explorable wifi driver is enough to already own everything, while with Qubes this code runs in a dedicated NetVM. For implementation details, see this pdf. https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf It has a chapter "Secure GUI". Elmar Stellnberger: > No actually it is not Qubes what I am using. > I am using full blown qemu virtualization including a virtual wrapper > device for the graphics. It is for sure that even here the weakest point > is the emulation of the graphics card. I have even heard about HTML5 > code directly bugging your hardware via graphics acceleration (though > this is rather theoretical because it would likely need to be customized > to a certain graphics card). Nonetheless the weakness of Qubes is even > more the GUI dom where all other doms connect to and which has direct > access to the graphics hardware. Unfortunately I could not find any > details on how it is implemented in deed. > Additionally I found it somewhat irritating that the basic description > of the Qubes project talks so much about using Windows as a host. I > would never trust software which is entirely closed source. Please do > also note the following statement found in the intro when considering to > use Qubes: > "Sure, a single kernel exploit destroys this all" > > If you remember what I have told you about MAC systems then it was that > a single public accessible system call which is implemented faulty would > still compromise your system. Now consider that all current operating > systems including Windows, Linux and FreeBSD are huge monolitic > constructs making use of just two privilege levels/ security rings: user > and kernel mode. At the introduction of the i386 (which is now still > long ago) Intel suggested that at least three privilege levels would be > necessary to build a secure system: the innermost for memory and process > management, a middle ring for device and hardware drivers and the > outermost one for user space programs. According to my knowledge and to > what is public none of the operating system developers have followed > these precautions until today (Xen is a different case as it uses three > rings but not in the way as described above; actually it would need to > make use of all four rings provided by the protected mode interface to > be secure in theory - Nonetheless just believe me that things are not as > theoretical in practice as this description may make you believe.). > > Regards, > Elmar > > On 29.11.2015 22:05, Patrick Schleizer wrote: >> Elmar Stellnberger: >>> If you wanna ask me for my security solution it is qemu based and puts >>> the most vulnerable system components like browsers and email programs >>> into a virtual machine namely qemu which is maintained by the Open >>> Source commnunity. >> >> Sounds like Qubes. >> >> Cheers, >> Patrick >> >
