Rendered at 21:46:54 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
msm_ 1 days ago [-]
Wow, this is serious. Makes you think, that even though QubesOS attack surface is so tiny (well-designed to be secure) there are still vulnerabilities to be found.
Worth noting that (as I understand) this vulnerability occurs only when doing copy-to-VM from Dom0:
>Note that the VM variant of `qvm-copy-to-vm` is not affected, as its
version of the error reporting function does not use `system()`:
Since you should not use Dom0 for regular work, and definitely not for interacting with likely-to-be-infected VMs, the scope of this attack is smaller than it sounds. On the flip side, when it works, it elevates privileges straight to Dom0.
deathanatos 1 days ago [-]
> 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)
zzo38computer 1 days ago [-]
The "system" function (and also "popen" function) are helpful, although they should be used carefully. You should only use it where the entire input (rather than merely a part of it) comes from a trusted source from the local user (and documented in a clear way that it does this), such as being entered interactively or from a user configuration file, or in some cases a entirely hard-coded string (although in such a case, often one of the exec functions works better), and to ensure that the security boundary is correct (e.g. you should probably avoid it if it is setuid). If it is necessary to pass additional data then you might use environment variables, pipes, temporary files, etc.
Strings passed to system or popen should not be constructed by combining other strings; they should be directly unchanged from whatever trusted source it comes from.
The specific use documented in the article is a situation where I should think that you should not call the shell (since the command includes untrusted input, and also because there might be a better way to display the error message).
There are additional possible security issues with such things though, whether you use the shell or execute directly, some of which are due to the use of text rather than binary data for communication (although changing that won't solve everything).
deathanatos 17 hours ago [-]
Well, so there's two other problems with system (and popen):
1. IME security teams want to run dumb linters over the code that look for such things. While uses such as the ones you describe are secure, the linter might be blunter than that. I'm not sure that's necessarily a bad thing: "this use of system(3) is secure" has a cognitive tax at review time, and as the code changes; often, I prefer the stance of "don't make me think" with regards to security: i.e., do the simple, trivially secure thing, not the complex, secure under the just-right conditions thing. Then we don't have to persuade (potentially non-technical) security teams, non-technical auditors, linters, etc. that are going over the code with blunt instruments.
2. (And much more minor) the entire execution of sh is often just wasted performance that an exec(2) removes.
(& yes, you are also right that even an exec(2), mishandled, can have its problems in some circumstances. But typically when the pattern is system("<shell that just runs what we'd exec(2)>"), then whatever those problems are, system(3) is going to share them.)
Topfi 1 days ago [-]
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.
nickzana 1 days ago [-]
I believe this is a vulnerability that occurs when copying data from dom0, which is a more common task. Generally the Qubes model recommends copying data from more trusted VMs to less trusted VMs, and dom0 still runs some system-wide processes in many default configurations.
For example when you take a screenshot with xfce4-screenshooter, the file is saved to dom0, and you have to use qvm-copy-to-vm to move it to a (less trusted) qube to do something with it. That's the most frequent use case, at least for me.
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…
chmod775 1 days ago [-]
That's an impressive amount of maturity and composure Adam demonstrates there after receiving a response like that.
sdcfgy 1 days ago [-]
I think it's pretty much spot on myself and applies to more than virtualization based on the last point. It really suggests that further complexity and abstraction is not a good security posture. And I agree with this from extensive experience (embedded, defence).
Regarding the two decades since and the numerous exploitable x86-64 and hypervisor bugs suggests he wasn't wrong and that the tone was appropriate for the severity of the problem.
dvdkon 1 days ago [-]
Sadly complexity is unavoidable for most real-world usecases. Just see how so many people interested in de-Googled phones balk at the prospect of losing access to banking apps. Telling them to go use an OS that doesn't support Bluetooth isn't going to work, but hopefully you wouldn't say that means they should give up all hope of security.
Abstraction has served us well in managing complexity before. I wouldn't abandon it out of misplaced idealism.
sdcfgy 1 days ago [-]
Hey I'm quite happy to run my banking over TN3270 :)
rpdillon 1 days ago [-]
> tone was appropriate
TDR said:
> You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write operating
systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.
This comment wouldn't survive HN scrutiny. It's a strawman argument, and doesn't address the core point at all: does virtualization improve or degrade security, when taken as a whole?
Adam's response is great, and TDR is smart, but he's been a lightning rod for 20 years for a reason: he was doing hot takes before they were even called that, and this is a great example.
majorchord 18 hours ago [-]
Theo and Linus' prolonged public attitudes are exactly why I boycott OpenBSD and Linux.
seethishat 9 hours ago [-]
Theo is probably autistic.
I work with a lot of great engineers with similar behavior. Their arguments are not personal, although they seem to be. They are just very passionate and care deeply about certain things (in this case operating systems security).
If you can get past the aggressive/offensive language they use and develop a relationship with them, they can be reasonable and helpful. That's been my experience.
Yeah, I'm with Theo on this one. Conventional OS security between Ring-0 and everything else is well understood; the problem has become too much code in Ring-0, a great fraction of which has its own interfaces across the security boundary, and the Unix security model just doesn't scale.
No capabilities, or even a sane and useful way of adding capabilities with everything in ring 0, and the flat integer namespacing of users and groups just doesn't work for what userspace needs to do today - hence namespaces, which have introduced their own problems, because (no surprise) trying to graft a tree structure onto a flat integer namespace after the fact is a mess.
Virtualization tried to sidestep all that, but to make it fast the cost has been more driver interfaces to host ring-0 - remember what the original was? - and screwing around a whole bunch with particularly arcane facets of the core ring-0 security boundary, e.g. page tables.
It is a mess.
pornel 1 days ago [-]
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.
1718627440 1 days ago [-]
The only point of system(3) is to invoke the OS shell, if you do not want that use exec(3).
XMPPwocky 1 days ago [-]
Looks like this has nothing to do with the hypervisor, it's not a traditional VM escape
zvmaz 1 days ago [-]
All I see is rudeness, insults, and arrogance sparkled with inklings of technical arguments. Worthless.
iugtmkbdfil834 1 days ago [-]
But, and this is the important part, is he wrong?
matherial 1 days ago [-]
Being right is not the most important part. If you're right but don't convince anyone, you've made no difference.
Theo was right that virtualization is a comparatively shoddy security boundary. At the same time, it's flexible and capable in ways that now define the shape of modern IT.
Could we have replicated that by other means? If yes, then it's on Theo and other knee-jerk critics that they never proposed a better approach and settled for insulting people. If not, then maybe virtualization was a necessary evil. Or maybe everyone else is an irredeemable idiot, but again - if we reach that conclusion, is the world better off?
sdcfgy 1 days ago [-]
Maybe if we didn't virtualize everything at machine level we'd have portable software that runs on the original virtualization method: processes.
Stares at Go as about the only step in that direction...
iugtmkbdfil834 1 days ago [-]
I did not claim it was most important, but he clearly called out issues that haunt us still, because we did not fix the basic initial issues ( and we are actively making it worse now with AI slop -- we because, while I use llms, I am not arrogant enough to offer my contributions to emulation, virtualization and other foundational stuff ). The point is that he called it and all of us should do some soul searching as to why his words were ignored. Because if he was ignored because 'he was mean about it', the we are kinda screwed long, because anyone with a brain that can comprehend the issue, will likely have little patience for anyone, who can't see it or won't want see to see it for some contrived semi-social reason.
systemf_omega 1 days ago [-]
LLM slop account. Admittedly this one was harder to spot.
matherial 1 days ago [-]
You're chasing ghosts, son.
tucnak 1 days ago [-]
Oh shit, you're right!
matherial 1 days ago [-]
They aren't, they're one of the people who latch on longstanding and neutral syntax (em-dashes, "it's not $foo") as a proof of LLM text. I don't blame them because HN has a lot of people trying to pass gen AI stuff as their own, and you need quick heuristics... but I'd encourage people at least do it right. Pay for Pangram or something.
pixl97 1 days ago [-]
Or as the new saying goes
"HN: Professionally identifying 230% of posts from 2017 as LLM generated".
That said Panagram is trash for the opposite reason. Not that some people talked like LLMs before LLMs, but now a lot of people talk like LLMs because of LLMs.
zvmaz 1 days ago [-]
I don't really know as the argument is mainly about how stupid people are... The technical argument is one paragraph ended with an insult, not much to make an educated and civilized opinion.
iugtmkbdfil834 1 days ago [-]
<< You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write operating
systems or applications without security holes, can then turn around
and suddenly write virtualization layers without security holes.
Allow me to start by saying that you are wrong about 'mainly about'. The argument starts with an insult, but insult is minimal and it moves directly into the technical details. But, note that how much you are wrong about the paragraph, because what you want to focus is the insult. You are so wrong about it you effectively invert the proportions of presence of technical data to insult..
negura 23 hours ago [-]
it's not right nor wrong, it's irrelevant. this exploit has nothing to do with the Xen hypervisor which underlies the virtualization in QubesOS
ipdashc 14 hours ago [-]
I feel like he is. VM breakouts are vastly rarer than kernel LPEs, aren't they?
Betelbuddy 1 days ago [-]
This community lives on not understanding that...form over function always...
iugtmkbdfil834 1 days ago [-]
But is the world a better place with that particular understanding being the norm. Would we, as a whole, be better served if function was what actually mattered? Wouldn't that be nice?
zvmaz 1 days ago [-]
Can I insult you and then complain that you focus too much on form?
Betelbuddy 1 days ago [-]
Only If I deserved it :-)
eli 1 days ago [-]
What if that isn’t the most important part
throwa356262 1 days ago [-]
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.
edelbitter 1 days ago [-]
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.
fallat 1 days ago [-]
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!
12995816 1 days ago [-]
Peak Theo! This refreshing truth telling has been eradicated in 2026.
Topfi 1 days ago [-]
It has? News to me. Go on any major thread on this page, you’ll witness similarly strong pushback visa-vi buying into corporate backed hype, akin to the overconfidence in virt security he pointed at back then.
nython 1 days ago [-]
Vi doesn't require a visa but the trip is one way only.
(Vis-a-vis)
Topfi 1 days ago [-]
You know, given my French grades, I really should stop using such phrases…
grommz 1 days ago [-]
The founder Joanna Rutkowska left QubesOS in 2018. All the code involved in this bug was committed by her successor Marek Marczykowski-Górecki.
Joanna seems to be a genuine good guy, she once wrote a paper titled "Intel x86 considered harmful". 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.
woodruffw 1 days ago [-]
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).
upboundspiral 24 hours ago [-]
The paper X86 considered harmful was about how the BIOS / Intel management Engine (now also AMD PSP), are completely opaque.
If the lowest layer is hidden, proprietary, there are infinite vectors for state actors to include their desired backdoors.
woodruffw 22 hours ago [-]
My understanding is that IME and PSP come more from the world of corporate compliance than anything else. In other words they exist for x86 because x86 gets deployed in corporate settings, and any ISA that attempts to occupy a similar niche will meet a similar fate.
(Compare ARM’s TrustZone, etc.)
jervant 1 days ago [-]
> good guy,
> she
tdb7893 21 hours ago [-]
I feel like "guy" is weird in that I often hear people say "you guys" (and similar phrases) to groups of women but "guy" on its own is referring to a man at least 99% of the times I hear it. I'm curious if other people actually use it completely non-gendered (it's definitely gendered in the places I've lived in the US).
throwawayffffas 12 hours ago [-]
It's always gendered in the singular, very rarely people may use the singular in a non gendered way and usually this conversation that we are having follows.
zby 1 days ago [-]
I am still impressed by QubesOS track and I use it for my dedicated 'financials' laptop.
IMHO the thing that is holding back QubesOS is the lack of hardware acceleration for graphics - maybe now when dual monitor setups are getting popular this could be a workaround for the security considerations?
jwrallie 1 days ago [-]
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.
tom_alexander 1 days ago [-]
> 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.
These are all possible using light containers. For example, on FreeBSD I will spin up a jail which runs wireguard, and then I'll bridge that to another a jail. That 2nd jail is running entirely off wireguard without any other way to access the network. Since it is a jail, it is isolated. And backing up is as simple as a zfs snapshot and zfs send. I assume the same is possible on Linux.
majorchord 18 hours ago [-]
I would argue non-safe binaries are not safe in a container either. And even with full VMs, there have been an embarrassing number of escape exploits over the years.
fsflover 1 days ago [-]
> I wish a similar distro would be made based on KVM
Hardware graphics acceleration can work, it just needs a bit of fiddling and opens a few attack vectors. I don't legitimately know if there has ever been a viable attack through a shared pci device though.
madushan1000 23 hours ago [-]
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.
throwawayffffas 11 hours ago [-]
They use Xens pci passthrough, you can setup a pci device to be assigned to a vm.
The vm runs it's own driver and has direct access to the device, you typically have to hide the device from dom0 for it to work flawlessly and hardware support is required. But I believe the kernels do not interact with each other in a direct way.
I used to have crashes on trying to restart a vm with a pci device attached probably related to resetting the device. But they seem to have resolved now days.
artyomsv 1 days ago [-]
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.
progval 1 days ago [-]
The driver could run in a VM and only display applications from that VM or a subset of VMs.
Joel_Mckay 1 days ago [-]
Most GPU drivers are an order of magnitude more complex than a CPU kernel.
There is also the fact most GPU are a bodged on architecture, and fundamentally impossible to really secure in the case of CUDA rootkits.
Fast, but a bad design. This is why we can't have nice things. =3
Allwinkt 1 days ago [-]
The worst part is that in 2020 they explicitly documented that the remote filename is attacker controlled,but still allowed it to reach system()
That is C security 101: never pass untrusted input through a shell. This should have been caught in review!
user_7832 1 days ago [-]
Mini tangent: Could someone explain to me why Qubes is used for security, when (from what I understand) Jails on BSD is significantly more robust/safe/has a much smaller exposed area? Is it just "everyone's using linux already; here's a safer linux"?
zvmaz 1 days ago [-]
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).
Qubes uses VMs, Jails use a shared kernel. So I wouldn’t say Jails are safer nor that they have a smaller exposed area with regard to host isolation than VMs.
polotics 1 days ago [-]
I'm still very impressed by qubes, and glad I'm not such a target that I feel I need the level of opsec it affords (on all my laptops).
Maybe someday AI-assisted killchains will be so widespread that Qubes is the minimal level for the (few?) still-local users of compute.
I would not have copied anything from dom0 to any another qube, the impact is low.
negura 22 hours ago [-]
> 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.
throwawayffffas 12 hours ago [-]
Very small attack surface, I have been using qubes for years, never had to copy a file from dom0 to a vm.
bawolff 1 days ago [-]
its kind of fascinating that all this paranoia falls to a shell escaping issue with system().
_pdp_ 1 days ago [-]
Most security bugs are due to improper string validation and use.
edelbitter 18 hours ago [-]
(Obviously a take that does not get very far in lower level programming, but from the comfort of some abstractions away:) I like to think of buffer overruns, command injections and path traversal as all the same category of bug: type confusion. Nothing special. An no excuse to risk any of them, if the logic implementing them is expected to be called just O(1) times anyway.
ferrule 22 hours ago [-]
Error reporting backchannels are often overlooked attack vectors. Pretty wild to see Qubes OS, of all systems, fall to such a subtle vector.
dhruvrrp 23 hours ago [-]
Tangentially, their steps listed to verify PGP signature is the prime example of why PGP has such dismal adoption.
TacticalCoder 1 days ago [-]
I do really like the following in the bulletin:
> Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. For more information, see How to import and authenticate the Qubes Master Signing Key.
It looks like Qubes is ran by people who take security seriously, which is refreshing.
inigyou 1 days ago [-]
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.
leonidasrup 1 days ago [-]
How well is QMSK protected from a serious attacker?
Topfi 1 days ago [-]
That is sphincter tightening to read. Have to point out how amazingly well their bulletins handle communication. Clearly describes the issues, how users are to act, etc. in, what I feel, is an easy to grasp language, even if one’s not in the weeds that much. In fairness though, I do still have some past memories concerning Qubes architecture from way back, so maybe my assessment is wrong and this is still not that straight forward to grasp for most.
Naru41 1 days ago [-]
If it's `untrusted_filename`, it should at least accept the length of the string as an argument.
Allwinkt 1 days ago [-]
The worst part is that in 2020 they explicitly documented that the remote filename is attacker controlled,but still allowed it to reach system()
This is C security 101: never pass untrusted input through a shell. This should have been caught in the review!
palata 1 days ago [-]
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.
vlovich123 1 days ago [-]
This should be made structurally impossible through type safety rather relying on code review.
charcircuit 2 days ago [-]
Another example for why system() is so dangerous to use.
I also don't understand why it needs to show the dialog in dom0. If you have the option to handle attacker controlled input on the unprivileged side, you should do that instead of putting a lot of logic on the privileged side.
delamon 1 days ago [-]
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.
HackerThemAll 1 days ago [-]
> 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.
danielheath 1 days ago [-]
If you're going to put the graphics and NIC into separate VMs, surely the secure screen can be another of those semi-privileged VMs rather than part of dom0
charcircuit 1 days ago [-]
It's for an the "File copy/move error" error dialog.
devhunt-org 12 hours ago [-]
It’s a good reminder that security boundaries are only as strong as the small utilities around them. The vulnerability is especially interesting because the dangerous behavior isn't in the main virtualization layer, but in something as mundane as error reporting.
crest 1 days ago [-]
Really an attacker controlled system() call?!?
iberator 1 days ago [-]
This os is supposed to be run on bare metal AFIK for same reason
ka3ki 1 days ago [-]
it's kinda doomed at this point
forest_brothers 11 hours ago [-]
[flagged]
kurdman_007 10 hours ago [-]
[dead]
kimberlysatterf 1 days ago [-]
[dead]
myshapeprotocol 21 hours ago [-]
[dead]
hneqy2wqls 1 days ago [-]
[dead]
ka3ki 1 days ago [-]
[flagged]
Cider9986 1 days ago [-]
GrapheneOS is highly usable and secure.
anArbitraryOne 1 days ago [-]
My username checks out
12995816 1 days ago [-]
Peculiar stuff. I'm always skeptical of these security Linux distributions, but this bug is so bad that it seems like an infiltration of Qubes at best or Qubes being a honeypot at worst.
Worth noting that (as I understand) this vulnerability occurs only when doing copy-to-VM from Dom0:
>Note that the VM variant of `qvm-copy-to-vm` is not affected, as its version of the error reporting function does not use `system()`:
Since you should not use Dom0 for regular work, and definitely not for interacting with likely-to-be-infected VMs, the scope of this attack is smaller than it sounds. On the flip side, when it works, it elevates privileges straight to Dom0.
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)
Strings passed to system or popen should not be constructed by combining other strings; they should be directly unchanged from whatever trusted source it comes from.
The specific use documented in the article is a situation where I should think that you should not call the shell (since the command includes untrusted input, and also because there might be a better way to display the error message).
There are additional possible security issues with such things though, whether you use the shell or execute directly, some of which are due to the use of text rather than binary data for communication (although changing that won't solve everything).
1. IME security teams want to run dumb linters over the code that look for such things. While uses such as the ones you describe are secure, the linter might be blunter than that. I'm not sure that's necessarily a bad thing: "this use of system(3) is secure" has a cognitive tax at review time, and as the code changes; often, I prefer the stance of "don't make me think" with regards to security: i.e., do the simple, trivially secure thing, not the complex, secure under the just-right conditions thing. Then we don't have to persuade (potentially non-technical) security teams, non-technical auditors, linters, etc. that are going over the code with blunt instruments.
2. (And much more minor) the entire execution of sh is often just wasted performance that an exec(2) removes.
(& yes, you are also right that even an exec(2), mishandled, can have its problems in some circumstances. But typically when the pattern is system("<shell that just runs what we'd exec(2)>"), then whatever those problems are, system(3) is going to share them.)
For example when you take a screenshot with xfce4-screenshooter, the file is saved to dom0, and you have to use qvm-copy-to-vm to move it to a (less trusted) qube to do something with it. That's the most frequent use case, at least for me.
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…
Regarding the two decades since and the numerous exploitable x86-64 and hypervisor bugs suggests he wasn't wrong and that the tone was appropriate for the severity of the problem.
Abstraction has served us well in managing complexity before. I wouldn't abandon it out of misplaced idealism.
TDR said:
> You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.
This comment wouldn't survive HN scrutiny. It's a strawman argument, and doesn't address the core point at all: does virtualization improve or degrade security, when taken as a whole?
Adam's response is great, and TDR is smart, but he's been a lightning rod for 20 years for a reason: he was doing hot takes before they were even called that, and this is a great example.
I work with a lot of great engineers with similar behavior. Their arguments are not personal, although they seem to be. They are just very passionate and care deeply about certain things (in this case operating systems security).
If you can get past the aggressive/offensive language they use and develop a relationship with them, they can be reasonable and helpful. That's been my experience.
No capabilities, or even a sane and useful way of adding capabilities with everything in ring 0, and the flat integer namespacing of users and groups just doesn't work for what userspace needs to do today - hence namespaces, which have introduced their own problems, because (no surprise) trying to graft a tree structure onto a flat integer namespace after the fact is a mess.
Virtualization tried to sidestep all that, but to make it fast the cost has been more driver interfaces to host ring-0 - remember what the original was? - and screwing around a whole bunch with particularly arcane facets of the core ring-0 security boundary, e.g. page tables.
It is a mess.
Theo was right that virtualization is a comparatively shoddy security boundary. At the same time, it's flexible and capable in ways that now define the shape of modern IT.
Could we have replicated that by other means? If yes, then it's on Theo and other knee-jerk critics that they never proposed a better approach and settled for insulting people. If not, then maybe virtualization was a necessary evil. Or maybe everyone else is an irredeemable idiot, but again - if we reach that conclusion, is the world better off?
Stares at Go as about the only step in that direction...
"HN: Professionally identifying 230% of posts from 2017 as LLM generated".
That said Panagram is trash for the opposite reason. Not that some people talked like LLMs before LLMs, but now a lot of people talk like LLMs because of LLMs.
Allow me to start by saying that you are wrong about 'mainly about'. The argument starts with an insult, but insult is minimal and it moves directly into the technical details. But, note that how much you are wrong about the paragraph, because what you want to focus is the insult. You are so wrong about it you effectively invert the proportions of presence of technical data to insult..
Especially as more and more virtualization functions move into hardware, not using them as a second security barrier seems foolish.
.. 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.
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!
Joanna seems to be a genuine good guy, she once wrote a paper titled "Intel x86 considered harmful". 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.
> 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).
If the lowest layer is hidden, proprietary, there are infinite vectors for state actors to include their desired backdoors.
(Compare ARM’s TrustZone, etc.)
> she
IMHO the thing that is holding back QubesOS is the lack of hardware acceleration for graphics - maybe now when dual monitor setups are getting popular this could be a workaround for the security considerations?
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.
These are all possible using light containers. For example, on FreeBSD I will spin up a jail which runs wireguard, and then I'll bridge that to another a jail. That 2nd jail is running entirely off wireguard without any other way to access the network. Since it is a jail, it is isolated. And backing up is as simple as a zfs snapshot and zfs send. I assume the same is possible on Linux.
There is an Issue for that: https://github.com/QubesOS/qubes-issues/issues/7051
I'm pretty sure all the major GPU drivers in mesa now supports this feature.
Wonder why QubesOS hasn't adopted this yet.
The vm runs it's own driver and has direct access to the device, you typically have to hide the device from dom0 for it to work flawlessly and hardware support is required. But I believe the kernels do not interact with each other in a direct way.
I used to have crashes on trying to restart a vm with a pci device attached probably related to resetting the device. But they seem to have resolved now days.
There is also the fact most GPU are a bodged on architecture, and fundamentally impossible to really secure in the case of CUDA rootkits.
Fast, but a bad design. This is why we can't have nice things. =3
[1] https://doc.qubes-os.org/en/latest/introduction/faq.html#is-...
Maybe someday AI-assisted killchains will be so widespread that Qubes is the minimal level for the (few?) still-local users of compute.
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.
> Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. For more information, see How to import and authenticate the Qubes Master Signing Key.
It looks like Qubes is ran by people who take security seriously, which is refreshing.
I also don't understand why it needs to show the dialog in dom0. If you have the option to handle attacker controlled input on the unprivileged side, you should do that instead of putting a lot of logic on the privileged side.
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.