In this context, Dom0 is completely disconnected from the internet. It is used for running the Xen hypervisor. Dom0 doesn't run any apps at all (except for the window manager). It does not process external untrusted input. The VM template is based on the most recent version.
I'm very happy with Qubes OS, using it as a daily driver for many years. It helps to organize your digital life and gives a great sense of security and control over your computer. I tried to list its advantages here: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
I installed Qubes OS last year. First, the installation was not smooth. I had to play with the UEFI BIOS settings to get the installer work. It can be picky with respect to hardware. That’s OK, but it’s unclear what works and what doesn’t, and you have to spend time searching the internet. If you look at their FAQs and forum, you will find all sorts of known problems that may arise just around the installation and booting. Then, the updates sometimes failed (and were slow, but that was OK). The main problem was that after a short while, one day it stopped booting, and I had to spend time in forums again. It felt unpredictable and fragile.
For an operating system to be used as a daily driver, it has to be stable, and reliable. The laptop may be forced to shutdown, even during an update installation. Some functions should always work: boot, WiFi/ethernet, HDMI, etc.
I would love to replace desktop Linux with Qubes. I work in Qemu VMs anyways. I would probably give 4.2 another go.
I've been using QubesOS for years, and I highly recommend it. Not only for security (which of course), but also for the cleanliness of not polluting your computer with a myriad of dependencies for projects you just tried once.
And of course, the high-risk activities that we all have to do at some point (now at least their risk is limited to their virtual machine) :
- curl|bash or similar
- pip install, npm install etc
- run any random github project
- sudo install the drivers of my Brother printer
- install zoom
- plug random cheap USB devices to eg update their firmware
I think you don't understand. Qubes relies on software virtualization in conjunction with hardware assisted virtualization instruction sets. The aforementioned vulnerability existed in Qubes Xen.
I'm not an expert, but how could it affect the VT-d even in principle? AFAIK VM escape is impossible with software exploits in this case, only side-channel attacks are.
22 comments
[ 0.22 ms ] story [ 51.0 ms ] threadI worry that there will be issues with updates, and so on.
I'm very happy with Qubes OS, using it as a daily driver for many years. It helps to organize your digital life and gives a great sense of security and control over your computer. I tried to list its advantages here: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
Another report from a user: https://news.ycombinator.com/item?id=36267756
For an operating system to be used as a daily driver, it has to be stable, and reliable. The laptop may be forced to shutdown, even during an update installation. Some functions should always work: boot, WiFi/ethernet, HDMI, etc.
I would love to replace desktop Linux with Qubes. I work in Qemu VMs anyways. I would probably give 4.2 another go.
You can find information on recommended hardware that works smoothly here: https://forum.qubes-os.org/t/community-recommended-computers...
And HCL lists all known hardware-related problems: https://qubes-os.org/hcl
Impressive improvements, and I like the new interface! I probably test the battery usage and applications, see if I can switch my workflow to Qubes!
And of course, the high-risk activities that we all have to do at some point (now at least their risk is limited to their virtual machine) :
How is it about the containers?
Have you been living under a rock [0]?
>How is it about the containers?
Container security aka OS virtualization has been quite secure for a while now.
[0] https://www.csoonline.com/article/551445/significant-virtual...
I think you don't understand: Qubes relies on hardware, not software virtualization: https://en.m.wikipedia.org/wiki/Hardware-assisted_virtualiza...
I'm not an expert, but how could it affect the VT-d even in principle? AFAIK VM escape is impossible with software exploits in this case, only side-channel attacks are.
There is a documentation update pending merging in the official documentation that covers how to do use the Firewall in 4.2.
https://github.com/QubesOS/qubes-doc/blob/86a6f12e2a882dfffb...
https://www.redhat.com/en/blog/using-iptables-nft-hybrid-lin...