pdfs

interface that UWP exposes for GUI applications because it's just too hard otherwise. For example, in the excellent description of this officially undocumented mess at [2] and [3], the author notes: "What is interesting here is that there does not seem to be any general mechanisms for restricting access to syscalls globally, which means that the attack surface can be quite large. Indeed, even if it is possible for the Kernel to know if the execution comes from inside a Silo, each syscall must set up its checks (or not). In addition, some syscalls do not directly block access to Silos, but rather implement a different logic between a host and Silo context." Another author at [4] finds all sorts of unexpected behaviours from this complex use of call interception, filter drivers, etc, such as endpoint security software not being aware of silos and use of filter drivers like BFS, etc, and not properly restricting or logging activities of "sandboxed" processes as developers and users of endpoint security software may expect. Even if someone reverse engineered an adequate understanding of silos and whatever else Microsoft call "Process Isolation", they'd also potentially have to then learn the completely different Hyper-V isolation approach, as well as Mandatory Integrity Levels (MILs), as well as old school Windows ACL permissions, as well as the newish "Virtual Secure Mode" (VSM)[7]. It'd be like setting up a Linux system that has every Linux Security Module (LSM) enabled at once because SELinux is just too simple on its own. [1] https://learn.microsoft.com/en-us/windows/win32/procthread/j... [2] https://blog.quarkslab.com/reversing-windows-container-episo... [3] https://blog.quarkslab.com/reversing-windows-container-part-... [4] https://www.deepinstinct.com/blog/contain-yourself-staying-u... [5] https://ht3labs.com/Brokering-File-System-January-2025-Patch... [6] https://learn.microsoft.com/en-us/windows/win32/secauthz/imp... [7] https://github.com/tpn/pdfs/blob/master/Battle%20of%20SKM%20...

et so much about Popek and Goldberd that they have come to believe some magical properties about "CPU virtualization"? (before anyone nitpicks, x86 sans VT-x _is_ Popek virtualizable but only for usermode code; non-user mode is a bit more complicated to manage, but still falls short compared to what VMs do in terms of hardware emulation these days). Even if you are assuming a state-of-the-art virtualizer with hyperdrivers and hyperbuses and whatever... it's still literally the same concept. The VM host is _emulating_ the hardware shown to the guest OS. It just emulates hardware that is much simpler and much more efficient to emulate because it was designed for VMs in mind. And, guess what, you can also apply the same idea to a purely software-based virtualizer to simplify it in the same way, too! (what layman's call paravirtualization). Obviously if you assume a virtualizer doing passthrough of any kind.... then the VM is directly accessing the hardware... but that is my point! It is now directly accessing hardware that it could not access before. As a summary: "CPU virtualization" is not even remotely in the same order of magnitude of headache-inducing-paranoia as allowing direct access to hardware is. The CPU running the VM guest's code is kind of an indisputable fact of virtualization at all, hardware-based or software-based. The VM guest's code directly accessing the host hardware ... is simply not. > If the device supports SR-IOV or S-IOV then they had to engineer the product to meet the spec. Are you claiming here that A) the spec defines how hardware should internally multiplex itself? (not true) and B) that the spec claims that hardware must be secure , therefore all hardware is secure! (not true and a very strange argument to make, anyway). In any case, happy to see you are now accepting my thesis that this is about giving VMs direct access to hardware, and that therefore it is now up to the hardware to really enforce this isolation. Or not. What else is there left to discuss? > This is exactly what every modern browser does You quoted my sentence fully so I know you read it yet you totally miss the point again. I said: JavaScript VM generating native CPU code _vs_ directly executing native CPU code directly from the internet. Your argument summarizes to: "This is what V8 does, which is to generate native CPU code". I know. That's why I put it as the baseline. You have made no counterargument whatsoever. > This also isn't true. Peer to Peer DMA support has been commonplace in consumer PCI-E devices (mainly NVME, network HBAs, and GPUs) for years now and has been available in datacenter, etc for a decade at least. I did admit that there is some hardware that is already used to interfacing with more or less user level code (like GPUs), but this is the _exception_ rather than the rule. And even if it is true, it still doesn't contradict my argument which is that : this is still about VMs having direct access to hardware that they didn't have before! No matter how you frame it, it increases the attack surface by an order of magnitude. Even for GPUs, now your GPU also require protection from the guest driver, where before it was the same as the host's. ("peer to peer" DMA commonplace in consumer hardware??? I don't know what you're talking about. DirectStorage developers would like a word with you...) > Also minor nit but the 80286 (the 3rd gen of 8086 CPUs, released less than 4 years after the original 8086) had an integrated MMU with proper segmentation support. Which is exactly why I mentioned the 8086, because it has no MMU and no protected mode... so really don't see what's your argument here. > Again this is just not true. They provide a framework for segmentation of hardware and enforcing isolation of those segments. That is absolutely intended for "preventing and constraining" access to hardware outside of what the host configures. This is absolutely ridiculous. Do you think that guest VMs can communicate directly with hardware and that SR-IOV is about "preventing and constraining" it? What virtualization actually is: https://github.com/tpn/pdfs/blob/master/A%20Comparison%20of%....