💾 Archived View for dioskouroi.xyz › thread › 29366862 captured on 2021-11-30 at 20:18:30. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
Is this secure? (i.e. does this prevent a malicious VM from fully taking over the host, writing arbitrary GPU memory, reading arbitrary GPU memory, corrupting other GPU memory or state, crashing the GPU)
Apparently the web people decided to create WebGPU instead of adopting Vulkan in part due to security issues, and I see no mention of security on the Mesa documentation.
My understanding of WebGPU isn't that it was adopted over Vulkan due to security issues but because Apple (who essentially designed it) doesn't want to touch anything related to Khronos due to some litigation between them. Which is probably why WebGPU is made under W3C instead of Khronos (who made WebGL).
That was the alleged (but false) reason they picked WGSL over SPIR-V, not the justification for designing WebGPU. Vulkan’s C API isn’t really compatible at all with JavaScript and has memory safety concerns and so forth. WebGPU has a slightly restricted, but vastly nicer interface. Plus there are a bunch of downsides to require browsers to emulate Vulkan over DirectX or Metal.
Apple is so toxic for the ecosystem. This is Oracle level unpleasantness.
The difference is they've gone from being a niche nobody making contrarian decisions like Firewire over USB to a market trend setter removing headphone jacks and adding phone notches
When did Apple choose FireWire over USB? Apple has never shipped a computer with FireWire which did not also have USB.
There was a period in time where Macbooks had FireWire 800 and USB 2. Apple chose not to be first with USB 3, so the choice was more expensive, fast FireWire or cheap and slow USB 2 devices. FireWire was significantly faster than USB 2, USB 3 was faster than FireWire. Eventually Apple dropped FireWire completely, and added Thunderbolt connectors. That did anger quite a few people who were invested in expensive FireWire devices. My favorite Macbook Pro was a 2015 13" it had USB 2 ports and two thunderbolt ports for high speed devices. Honestly, the only thing I ever used the thunderbolt port for was driving extra displays.
Things have improved by now, but my experience with the earlier USB 3 devices is that compared to their FireWire counterparts they were extremely flaky — wildly inconsistent transfer rates, intermittent disconnections, and general weirdness, especially for sustained workloads. I could see FireWire being preferred over USB 3 for that alone, even if USB 3 was faster on paper.
My experience with Firewire was that not a single peripheral I owned was compatible. So yeah, I probably would have preferred a few more USB ports instead of a dedicated plug for the iPod I don't own.
USB 3 was a horrible janky mess for many years, with the early chipsets (and/or chipset drivers) being highly unstable. I recall being entirely unsurprised that Apple stayed clear of it during that time.
I still have my Firewire to Thunderbolt adapter in my random adapter drawer... worked a charm for my Firewire external hard drives and mixing desk. It did take quite a while for stable USB 3 peripherals to come out, and by that time I was ready to upgrade those 1 TB hard drives to 4.
edit: forgot the Firewire-... sorry, ieee1394-connected MiniDV camcorder!
Apple was one of the pioneers of Firewire originally wanting to replace ADB with it
They never "left out" USB but they strongly preferred Firewire and their devices (such as the original iPod) came in Firewire first
The iPod used Firewire because it would have taken ages to sync using USB 1.x.
Security definitely played the biggest role in WebGPU's design process. The other goal was identifying the common feature set of D3D12, Metal and Vulkan. The resulting API is the result of those two goals.
(disclaimer: I haven't been part of the WebGPU design process, only followed it closely through the publicly available meeting notes and discussions).
It’s no more secure than the security isolation guarantees given by the GPU driver stack to a regular process. No more guarantees are provided than that.
I’d consider the VMM as even more untrusted than before when VirGL is used, with always assuming that the guest has code exec in the VMM. With all the implications that this entails.
I wouldn't consider any qemu based vmm a security boundary. I think of VM code as running with the same permissions/access as the qemu process itself.
Whenever I see questions regarding virtualization security I sometimes wonder what percentage of malware is VM-aware. It would make sense to leverage software that users have a false sense of security in. That's not to say most virtualization solutions can't provide a fair amount of isolation and thwart non-sophisticated attacks, but they aren't air-tight by any stretch.
I love watching the QEMU ecosystem develop. I use it for running a handful of VMs on a host server: a Windows machine to run my label printers and their terrible software, opnsense to be my router, and then a couple test beds that I use to try new software in a clean environment.
Someday maybe it'll be possible to accelerate guest Windows DirectX graphics without hardware support for SRIOV. That'll be great for my CAD workloads.
> Someday maybe it'll be possible to accelerate guest Windows DirectX graphics without hardware support for SRIOV. That'll be great for my CAD workloads.
Maybe you could already try to use DXVK on the windows guest, plus this Vulkan passtrough.
I know that some Windows users successfully use dxvk to sidestep drivers issues: it's mostly a drop-in DLL.
Edit: although I don't think there is a windows driver for this yet. Given recent progress made on building mesa on windows, that might change soon.
KVM maintainer here, is there a report of the EFAULT issue with AMD processors?
Author here. :D
The issue is triggered with some code that is not yet upstream in QEMU, so we do not know whether the bug is in the kernel, or whether it is in a problem with this new QEMU code.