8 ms·
just as a meta idea, i'm mystified that systems folks find it impossible to create protected mode operating systems that are protected, and then we all engage i
by fsckboy 2y ago
just as a meta idea, i'm mystified that systems folks find it impossible to create protected mode operating systems that are protected, and then we all engage in wasteful kluges like VMs.
i'm not anti-VM, they're great technology, i just don't think it should be the only way to get protection. VMs are incredibly inefficient... what's that you say, they're not? ok, then why aren't they integrated into protected mode OSes so that they will actually be protected?
- bigbones 2y agoBecause it would defeat the purpose. Turns out we don't trust the systems folks all that much
- Veserv 2y ago[flagged]
- elric 2y agoHah, I was going to post the same quote when I read the parent comment. Glad to see I'm not the only grump who remembers TDR quotes. But he's right. And with the endless stream of leaky CPUs and memory (spectre, rowhammer, etc) he's even more right now than he was 17 years ago. There are all kinds of things being done to mitigate multi-tenant security risks in the Confidential Computing space (with Trusted Execution Environments, Homomorphic Encryption, or even Secure Multiparty Computation), but these are all incredibly complex and largely bolted on to an insecure base. It's just really, *really*, hard to make something non-trivial fully secure. "It depends on your threat model" used to be a valid statement, but with everyone running all of their code on top of basically 3 platforms owned by megacorps, I'm not sure even that is true anymore.
- tptacek 2y agoMicroarchitectural attacks are an even bigger problem for shared-kernel multitenant systems!
- tptacek 2y agoThis Theo quote from 18 years ago gets brought up a lot. It's referring to a different era in virtualization (it practically predates KVM, and certainly widespread use of KVM). You can more or less assume he's talking about running things under VMWare. In the interim: * The Linux virtualization interface has been standardized --- everything uses the same small KVM interface * Security research matured and, in particular, mobile device jailbreaking have made the LPE attack surface relevant, so people have audited and fuzzed the living hell out of KVM * Maximalist C/C++ hypervisors have been replaced by lightweight virtualization, which codebases are generally written in memory-safe Rust. At the very least, the "nearly full kernel" thing is totally false now; that "extra" kernel (the userland hypervisor) is now probably the most trustworthy component in the whole system. I would be surprised if even Theo stuck up for that argument today, but if he did, I think he'd probably get rinsed.
- Veserv 2y agoAre you claiming it has no security vulnerabilities? If yes, care to present a proof. If no, then please estimate how big of a bug bounty would result in a reported critical vulnerability. If I put up a 1 G$ bug bounty, do you think somebody would be able to claim it within a year? How about 10 M$? Please justify this in light of Google only offering 250 k$ [1] for a vulnerability that would totally compromise the security foundation of the multi-billion (trillion?) dollar Google Cloud. Please also justify why the number you present is adequate for securing the foundation of the multi-trillion dollar cloud industry. I will accept that element on its face if you say the cost would be 10 G$, but then I will demand basic proof such as formal proofs of correctness. [1] https://security.googleblog.com/2024/06/virtual-escape-real-reward-introducing.html https://security.googleblog.com/2024/06/virtual-escape-real-...
- tptacek 2y agoI have no idea who you're talking to, but nobody on this thread has claimed anything has "no security vulnerabilities". If you think there isn't an implicit 7-figure bounty on KVM escapes, we are operating from premises too far apart for further discussion to be productive. My bigger problem though: I gave you a bunch of substantive, axiomatic arguments, and you responded to none of them. Of the three of them, which were you already aware of? How did your opinion change after learning about the other ones? You cited a 2007 Theo argument in 2024, so I'm going to have trouble with the idea that you were aware of all of them; again, I think even Theo would be correcting your original post. later You've written about the vulnerability brokers you know in other posts here; I assume we can just have a substantive, systems based debate about this claim, without needing to cite Theo or Joanna Rutkowska or whatever.
- fsflover 2y agoShow me a recent escape from VT-d and then you will have a point.
- Veserv 2y agoVT-x. You should get the name of the technology right before defending it. VT-d is the I/O virtualization technology. When did it become customary to defend people making claims of security instead of laughing in their face even though history shows them such claims to be a endless clown parade? How about you present the extraordinary evidence needed to support the extraordinary claim that there are no vulnerabilities? I will accept simple forms of proof such as a formal proof of correctness or a unclaimed 10 M$ bug bounty that has never been claimed.
- tptacek 2y agoNot an especially impressive flex, but I'm not above trying to dunk on people for misspelling things either, so I'm not going to high-horse you about it (obviously i am). The history of KVM and hardware virtualization is not an endless clown parade. Find a vulnerability researcher to talk to about OpenBSD sometime, though. https://isopenbsdsecu.re/ https://isopenbsdsecu.re/
- Veserv 2y agoOpenBSD is not secure by any measure. That Theo happens to be right about the endless clown parade is independent of his ability to develop a secure operating system. I mean, jeez, even Joanna Rutkowska acknowledges the foundations are iffy enough to only justify claiming “reasonably secure” for Qubes OS. You are making a extraordinary claim of security which stands diametrically opposed to the consensus that things are easily hacked. You need to present extraordinary evidence to support such a claim. You can see my other reply for what I would consider minimal criteria for evidence.
- tptacek 2y agoSo far all I'm seeing here are appeals to the names of people who I don't believe agree with your take. You're going to need to actually defend the argument you made.
- toast0 2y agoWindows has Virtualization Based Security [1], where if your system has the right hardware and the right settings, it will use the virtualization support to get you a more protected environment. IO-MMU seems like it was designed for virtualization, but you can use it in a non-virtualized setting too, etc. [1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs https://learn.microsoft.com/en-us/windows-hardware/design/de...
- ploxiln 2y agoThe industry tends to do this everywhere: we have a system to contain things, we made a mess of it, now we want to contain separate instances of the systems. For example, in AWS or GCP, you can isolate stuff for different environments or teams with security groups and IAM policies. You can separate them with separate VPCs that can't talk to each other. In GCP you can separate them with "projects". But soon that's not enough, companies want separate AWS accounts for separate teams or environments, and they need to be grouped under a parent org account, and you can have policies that grant ability to assume roles cross-account ... then you need separate associated groups of AWS accounts for separate divisions! It really never ends, companies will always want to take whatever nested mess they have, and instead of cleaning it up, just nest it one level further. That's why we'll be running wasm in separate processes in separate containers in separate VMs on many-core servers (probably managed with another level of virtualization, but who can tell).
- deleted 2y ago[deleted]
- dale_glass 2y agoSecurity is easier when the attack surface is limited. An OS provides a huge amount of functionality and offers access to vast amounts of complex shared resources. Anywhere in that there can be holes. A VM is conceptually simpler. We don't have to prove there's no way to get to a root exploit from a myriad services running as root but available to a normal application. We're concerned about things like that a VM won't access a disk belonging to another. Which is a far simpler problem.
- Bognar 2y agoVMs as an isolation concept at the processor level are actually quite efficient, but unfortunately we use that to run whole operating systems which impose their own inefficiency. Micro-VMs that just run a process without an OS (or with an OS shim) are possible but we don't yet have good frameworks for building and using them.