Hacker News Reader

Comment by anonypla | Hacker News Reader

Personally I think QubeOS is probably the best option in terms of Privacy and Security at this stage. If your hardware can handle it (16GB RAM would be best).

I would seriously consider QubeOS over PureOS if privacy and security are your concerns.

It works pretty well and I've been using it for a while now on not so recent hardware without much issues.

Their compartmentalization and seamless virtualization is just amazing and I don't think any other distro offers this with so much convenience.

View on HN

Qubes is fantastic but as a PSA the hypervisor's kernel doesn't support newer GPUs such as AMD rx5000 (AFAIK rx580 is the newest supported one). Learned this the hard way. Qubes 4.1 will bring the support, once it's complete https://github.com/QubesOS/qubes-issues/milestone/20

Any notes on the VM integration in general? Been looking forward to a "Windows subsystem for Linux" style thing where I can run Visual studio and games without actually having to deal with Windows as a primary OS =P

Proton - Valve's branch of Wine is probably your best option for running Windows games on Linux right now. That is of course unless you also want all the security that comes with Qubes. If you want to use a VM, VMware had a reasonably well working implementation of 3D acceleration when I last tried it 4 or 5 years ago.

I love qubes my only gripe is that they use the zen hypervisor instead of a minimal formally verified os such as sel4 which I think would go a long way in strengthening the isolation between “domains/containers/etc”.

Xen, not Zen.

What are your problems with Xen? They explain their choice very well: https://www.qubes-os.org/faq/#why-does-qubes-use-xen-instead....

SEL4 would be a better choice because it is formally verified, there is a much smaller chance of vulnerabilities in SEL4 vs Xen because of this.

From the above link:

What about safe languages and formally verified microkernels?

In short: these are non-realistic solutions today. We discuss this in further depth in our Architecture Specification document: https://www.qubes-os.org/attachment/wiki/QubesArchitecture/a....

Interestingly enough they only mention it being unreasonable for x86, it would be interesting to see SEL4 supported for ARM (of which SEL4 already has a verified kernel for).

The paper discusses more fundamental issues than just x86 architecture:

* Usermode drivers need to be formally verified to prevent malicious DMA. Adding IOMMU/SMMU to the microkernel will complicate the current proofs.

* All user processes that manage resources, like filesystem, network and memory management, must also be formally verified. These are currently unproven.

What is the response of QubeOS to the famous Theo de Radt critique[1] that virtualisation is basically adding another layer (hypervisor) of possible exploits just below the existing one (kernel)?

[1]: https://news.ycombinator.com/item?id=8393940

Just compare the number of lines of code between the Linux kernel and Xen. You will see how much lower probability of a bug becomes if you use the latter.

Rutkowska wrote various posts about it. She does not answer your question directly and precisely, but provides considerations that make clear why she considers Qubes' approach an improvement over the status quo.

On Formally Verified Microkernels (and on attacking them) - https://blog.invisiblethings.org/2010/05/03/on-formally-veri...

The Linux Security Circus: On GUI isolation - https://blog.invisiblethings.org/2011/04/23/linux-security-c...

I think she had other posts on another blog as well, but unfortunately I don't remember the address. And I don't know if it still exists.

What is Theo de Raadt's model with regards to X11 security on OpenBSD? Does it work out of the box?

OpenBSD doesn't do GUI isolation. xinput grabs all. But file system is limited (unveil) and what apps can do (pledge)

Reply on news.ycombinator.com