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%....

writing AVX2 code. Yes, that's why I said you _might_ make _some_ different decisions, such as in any algorithm that doesn't scale cleanly to 256 bits, but still ends up faster when the CPU offers full 256 bit ALUs (so 256 bit and 128 bit ops have the same performance). One real-world example would be something that uses a vector-width lookup table, say for a shuffle mask. With 2 possibilities for each DWORD element, a 128-bit shuffle mask only needs 16 entries, but 256-bit masks need 256 and they are twice as large (8 KiB in total!). With fast 256-bit units you might suck up this penalty, since it might end up faster overall, but with 128-bit units you might be better off going with the much smaller table and 128-bit lookups, at the same total throughput. > Remember that its not a pure win on Intel systems either: use of any YMM register begins to downclock the whole chip, Well not really anymore. Most (all?) recent chips don't downclock for use of 256-bit registers (not counting "high lane powerup"). Only some server chips downclock for "heavy" AVX2 use, which really means a lot of back-to-back FMAs or other heavy FP operations. In general the penalty for 256-bit instructions is small on recent cores (a larger penalty is paid for AVX-512), and compilers generally use them freely (the same is not true for 512-bit) and effectively. --- [1] https://github.com/tpn/pdfs/blob/master/Fast%20Bit%20Compres... [2] I think there must be some small changes, since the LSD was re-enabled, implying that they fixed the bug where registers could be corrupted when using the high half of the GP byte registers.