Раньше (AFAIK) можно было только вторую видяху пробросить, а в новом xen'е (см. соседнюю новость) можно и основную прокинуть. И спокойно запускать 3D с полный использованием GPU.

Думаю что рутковской они похрену - у нее другие игрушки. Ей бы правильнее было сменить фамилию на Руткитская, лучше бы отражало суть дела :)

выдержка из Faq на офф сайте:
"How about running applications like games that required 3D support.

Those won’t fly. We do not provide OpenGL virtualization for AppVMs. This is mostly a security decision, as implementing such feature would most likely introduce lots of complexity to the GUI virtualization infrastructure. However, Qubes allows for use of accelerated graphics (OpenGL) in Dom0’s Window Manager, so all the fancy desktop effects should still work under Qubes."

так что похоже что нет

VirtualPC
- это от микрософта, отличается недостатоком фич по сравнению с VmWare
VmWare
- мегалидер, но не опенсорное
QEMU & KVM
- опенсорсные, примерно одно и то же, обязательно требует аппаратную поддержку
XEN
- опенсорсная, отличается от KVM тем, что может работать на процессорах без аппаратной поддержки виртуализации

На совсем уж общем уровне, разумеется - виртуализация и в африке виртуализация. Вот только в деталях отличия могут быть и достаточно ощутимые. А то болид F1, горбатый запор, мерс и древняя самобеглая коляска - номинально все как бы автомобили, с 4-я колесами, рулем, мотором и так далее. Но вот есть небольшие (или большие) отличия в деталях...

Это мягко говоря совсем не факт. Особенно со столь абсолютистским подходом (даже msdos был на сях в массе своей, если не глючу).

Этого не будет потому что на ассемблере писать проги во-первых, не кроссплатформенно (на этом, вообще, можно закончить), также очень медленно, и получатся они точно менее стабильные безопасные и очень не факт что более эффективные. Вот ты с такими высказываниями, которые говорят о уровне познаний, любой суперкомпьютер превратишь ассемблером в тормознейший недобук.

C - портабельный ассемблер, вот на нем надо писать. И на C++. А конкурентов у них нет, и в ближайшее время не предвидится.

Скорее на профессиональной интуиции.

3.2. Xen vs. KVM security architecture comparison

Most Xen advocates would dismiss KVM immediately by saying that itʼs not a true bare-metal hypervisor, but rather more of a type II hypervisor added on top of (fat and ugly) Linux kernel. The KVM fans would argue that while Xen itself might indeed be much smaller than Linux with KVM, however that itʼs not a fair comparison, because one needs to also count Xenʼs Dom0 code as belonging to TCB, and that Dom0 uses a pretty much regular Linux system, which in the end comes down to pretty comparable code bases we need to trust
(Linux + KVM vs. Xen + Linux).

Both of those arguments are oversimplifications, however.
The thin vs. fat hypervisor argument
In KVM architecture each VM is just another type of a Linux usermode process. The exception being that such a “VM process” doesnʼt have access to the standard Linux system call interface, but instead can interact with the kernel via VMX or SMX intercepts. In that case the kernel actually becomes the hypervisor for all the VM processes. One should note, however, that the VM hypervisor interface in that case is much simpler than in case of a regular process kernel interface.

However itʼs not entirely true. Particularly the hypervisor still uses (or is free to use) the whole Linux kernel infrastructure, with all its drivers and internal interfaces. This makes the line between what code in the Linux kernel is, and what is not, used for handling various VM-generated events, to be blurry. This is not the case when we consider a true bare-metal hypervisor like Xen. In Xen, at no point does the execution path jump
out of the hypervisor to e.g. Dom03 . Everything is contained within the hypervisor.

Consequently itʼs easier to perform the careful security code audit of the Xen hypervisor, as itʼs clear which code really belongs to the hypervisor.

At the same time the above argument cannot be automatically transfered to Xenʼs Dom0 code.

The main reason is that it is possible to move all the drivers and driver backends out of Dom04 . The same is true for moving the IO Device Emulator (ioemu) out of Dom05 .
The only element (that is accessible to VMs) that must be left in Dom0 is the XenStore daemon, that is responsible for managing a directory of system-wide parameters (e.g. where is each of the backend driver located). That represents a very minimal amount of code that needs to be reviewed.

The I/O Emulation vs. PV drivers

KVM uses full virtualization approach for all its virtual machines. This means that every virtual machine in KVM must have an associated I/O emulator. KVM uses the open source qemu emulator for this purpose. In KVM architecture the I/O emulator is running on the host, although as an unprivileged non-root process.

Xen, on the other hand, allows for both fully virtualized, as well as para-virtualized virtual machines. This offers an option of either removing the I/O emulator completely from the system (in case the user wants to use only PV guests, as they donʼt need an I/O emulation), or to host the I/O emulators in dedicated minimal PV domains. Xen provides even a dedicated mechanism for this, the so called “stub-domains”.

The I/O emulator is a complex piece of software, and thus it is reasonable to assume that it contains bugs and that it can be exploited by the attacker. In fact both Xen and KVM assume that the I/O emulator can be compromised and they both try to protect the rest of the system from a potentially compromised I/O emulator. They differ, however, in the way the try to protect the system from a compromised I/O emulator.

KVM uses standard Linux security mechanisms to isolate and contain the I/O emulator process, such as address space isolation and standard ACL mechanisms. Those can be further extended by using e.g. SELinux sandboxing. This means that the isolation quality that KVM provides cannot be significantly better than what a regular Linux kernel can provide to isolate usermode processes6.

Xen uses virtualization for the I/O emulator isolation, specifically para virtualization, just in the very same way as it is used for regular VM isolation, and doesnʼt relay on Linux to provide any isolation.

Driver domains support

A very essential feature for the Qubes OS is the ability to sandbox various drivers, so that even in the case of a bug in a driver, the system could be protected against compromise. One example here could be a buggy WiFi driver or 802.11 stack implementation that could be exploited by an attacker operating at an airport lounge or in a hotel. Another example could be a bug in the disk driver or virtual filesystem backend, that
could be exploited by the attacker from one of the (lesser-privileged) VM in order to compromise other (more-privileged) VMs.

In other to mitigate such situations, Qubes architecture assumes existence of several so called driver domains. A driver domain is an unprivileged PV-domain that has been securely granted access to certain PCI device (e.g. the network card or disk controller) using Intel VT-d. This means that e.g. all the networking code (WiFi drivers, stack, TCP/IP stack, DHCP client) is located in an unprivileged domain, rather than in Dom0.

This brings huge security advantages -- see the specific discussions about network domain and disk domain later in this document.

KVM, on the other hand, doesnʼt have support for driver domains. One could argue it would be possible to add a support for driver domains (that is for hosting PV driver backends in unprivileged domains) using Linux shared memory, because KVM allows to use VT-d for secure device assignment to unprivileged VMs, but that would probably require substantial coding work. More importantly, because KVM doesnʼt support PV domains, each driver domain would still need to make use of the I/O emulator running on the host. As explained in the previous paragraph, this would diminish the isolation strength of a driver domain on a KVM
system.

Summary

We believe that the Xen hypervisor architecture better suits the needs of our project. Xen hypervisor is very small comparing to Linux kernel, which makes it substantially easier to audit for security problems. Xen allows to move most of the “world-facing” code out of Dom0, including the I/O emulator, networking code and many drivers, leaving very slim interface between other VMs and Dom0. Xenʼs support for driver domain is crucial in Qubes OS architecture.

KVM relies on the Linux kernel to provide isolation, e.g. for the I/O emulator process, which we believe is not as secure as Xenʼs isolation based on virtualization enforced by thin hypervisor. KVM also doesnʼt support driver domains.

Вот чему чему а интуиции руткитской :) по части безопасности имхо можно доверять. На ее счету обнаружение нескольких потенциальных дыр в висте, нестандартные фокусы с руткитами юзающими виртуализацию и так далее.В общем то спец своего дела.И вон тут кто-то нафлудил обоснование чем по ее мнению xen защищеннее.Дизайн ее системки оверпараноидален и обладает нехилым оверхедом (достаточно посмотреть на скрине сколько памяти сожрано) но можно отметить и интересные решения.От параноиков для параноиков :).

p.s. как извеснтно, лучший способ защиты - это нападение. ИМХО есть смысл юзать виртуализацию первым, до того как это сделают хаксоры.Пусть лучше они сношаются с пониманием куда попали, поисками невидимого админа, незаметным мониторингом, откатами снапшотов и прочая чем наоборот когда админ даже и не заметит что у его системы - двойное дно.

P. S. Да, я видел эту недоось не надо домашненьком компе с работающим Konqueror-ом, а в условиях ее применения по назначению. И не раз, и не два, а больше года.

И как по вашему Linux изолирует допустим OpenOffice.org или Firefox-а от других приложений запустившего их пользователя, если через какую-то непоправленную дыру в этих программах злонамеренный код получит управление ? Изоляция от других пользователей не в счет, в Qubes рассматривается именно изоляция отдельных видов приложений одного пользователя.

Запусти 2 скрипта, в одном:

#!/bin/bash

    while true
         do
           sleep(10);
           echo "Sleep";
    done;

во втором

#!/bin/bash

killall -9 sleep || sleep 1 && killall -9 sleep && killall -9 sleep;

------

Всё пипец, вторая программа нарушила работу первой, галактико вАпасности, Линюкс дырявый!!!!