Hacker News

> well-designed to be secure

While I suppose this doesn't say the design isn't secure, system() is one of those calls that has no place in modern code. It is insecure by its design.

> Any user input that is employed as part of `command` should be carefully sanitized, to ensure that unexpected shell commands or command options are not executed. Such risks are especially grave when using system() from a privileged program.

(—man 3 system)

You are right, copying to dom0 is not best practices and warned against since anno dazumal, but given the user groups I remember not always being technically minded (journalists, dissidents, etc.) and ensuring qubeses isolation holds even when users do things they are discouraged from has always been part of the philosophy. Don’t trust users, don’t trust userland, don’t trust software and all that yazz.

I feel that, in fairness, one should at least read Adam’s response, though ideally all subsequent mails: https://marc.info/?l=openbsd-misc&m=119320496730314&w=2

Theos is a very opinionated and not necessarily wrong position, but I feel also a bit too reductive given we are eternally having to deal with compromises of some form. Also, lest we forget, it has been two decades in the interim and oh so much has changed. In any case, this originated from their code, not virtualization, so it doesn’t really apply either way…

The bug here is not related to virtualization, but a footgun as old as C stdlib: system() that doesn't take arguments separately, and instead relies on shell escaping by the application.

Looks like this has nothing to do with the hypervisor, it's not a traditional VM escape

All I see is rudeness, insults, and arrogance sparkled with inklings of technical arguments. Worthless.

Theo is a very insightful guy, but also very opinionated. I think the truth is somewhere in between.

Especially as more and more virtualization functions move into hardware, not using them as a second security barrier seems foolish.

Brutal

I hope when people read this though they understand this is a communication style; they're clearly trying to strongly discourage people from thinking they are suddenly protected. Effective? Maybe at one time, where "macho dev energy" was a thing. Today, not so much. You can tell they mean well because the intro sentence is actually pretty cheeky!

This is less of a virt/x86 bug and more of a "don't call system() on arbitrary user input" bug.

.. incidentally, OpenBSD also provides one of the clearest examples of how the excuse "calling system() is fine in my case, its totally not arbitrary user input" is deluded just the same, see CVE-2020-8794.

Peak Theo! This refreshing truth telling has been eradicated in 2026.

I dropped QubesOS once exactly for that reason in the past but now I’m running it again on a separate computer.

Even with all its drawbacks, there is something really nice about being able to run different applications over Tor, VPN or plain internet simultaneously, the ability to isolate non-safe binaries and being able to backup your VMs easily.

I wish a similar distro would be made based on KVM so that the standard kernel could be used. It would be great for compatibility.

This is sort of a solved problem with virtio native context. You can just run mesa driver in the virtual machine and proxy it's ioctl calls to host kernel gpu driver.

I'm pretty sure all the major GPU drivers in mesa now supports this feature.

Wonder why QubesOS hasn't adopted this yet.

Problem is not that nobody wants to do it, it is that GPU stack is exactly the kind of enormous driver surface Qubes exists to keep away from dom0. Second monitor does not really change that, somebody still has to trust the driver.

Is there some evidence that x86 is uniquely prone to exploitable memory corruption? I haven't seen it, if so.

> That's why Huawei and the Chinese government aren't even trying any more to make western CPU architectures secure, it's a hopeless cause.

I suspect there are much more boring reasons for this, ranging from licensing to geopolitics (i.e., it being useful/valuable to have a domestic base of engineers who can design an ISA).

> good guy,

> she

Qubes can be viewed as a Xen distribution, rather than a Linux distribution [1]. You may find the Qubes FAQ a good starting point (I'm reading it now because of your question, so thanks).

[1] https://doc.qubes-os.org/en/latest/introduction/faq.html#is-...

> I would not have copied anything from dom0 to any another qube, the impact is low.

You'd typically copy logs, to open issue tickets etc.

I own a Qubes T-shirt which I bought in person at FOSDEM. The design on the T-shirt consists of many copies of the QMSK in hexadecimal. All of their merch is like this.

How well is QMSK protected from a serious attacker?

Isn't it the case for all bugs? If they appear in the production software, it means that they passed the review. And obviously bugs shouldn't pass the review, but that's easier said than done.

This should be made structurally impossible through type safety rather relying on code review.

The code is sloppy. They check existance of kdialog binary using full path; next step they rely on PATH search by shell. If would've been much safer to just do execve directly.

> why it needs to show the dialog in dom0

I think it's the "secure screen" that cannot be manipulated by the malware in a VM. I'd expect a password entry dialog to also be handled like that.