4 ms·

Yeah, it supports it. Pretty much every desktop/laptop GPU from the past 15-20 years supports this in fact. I actually remember John Carmack lamenting back in

Yeah, it supports it. Pretty much every desktop/laptop GPU from the past 15-20 years supports this in fact. I actually remember John Carmack lamenting back in ~2009 that these MMUs were ubiquitous already and that he wanted to more directly use the MMUs to implement virtual memory for IdTech4's MegaTexture feature, but couldn't get the GPU vendors to expose them in usable ways for application developers. Mantle/Vulkan/DX12/Metal was in a lot of ways a reaction to the thought 'well because of the ubiquitous MMUs in GPUs, user code can only crash their on GPU context, so it can't hurt to give them access to a lower level, video game console-esque API. At most they crash themselves and that was always allowed'. > Is this the IOMMU (which isn't generally supported, except on high end hardware [0]) or something else? No it's another MMU on the GPU itself. An IOMMU when combined with a GPU is a third MMU between the GPU and physical memory so you can give more or less raw GPU access to a VM securely.

nextaccountic 4y ago
... but why does, when my X11 (happens in wayland too iirc) system has some kind of bug, one window displays the contents of another (with some graphical corruption)? my supposition was that a buffer of one program ending up in a VRAM associated with another program can only happen if there is no MMU, otherwise, what's the point also: do you happen to know why do Qubes folks think that it's okay for two mutually untrusted programs run on the CPU, but can't accept that two untrusted programs can run on the GPU without eveasdropping on each other? even with IOMMU it seems. it gives me the impression that safely sharing the GPU is a work in progress / not very secure
- monocasa 4y ago
  > ... but why does, when my X11 (happens in wayland too iirc) system has some kind of bug, one window displays the contents of another (with some graphical corruption)? > my supposition was that a buffer of one program ending up in a VRAM associated with another program can only happen if there is no MMU, otherwise, what's the point Because the compositor is running entirely in one GPU user context with access to the different windows. The different applications can't access each other, but the compositor can see all of their final display buffers. > also: do you happen to know why do Qubes folks think that it's okay for two mutually untrusted programs run on the CPU, but can't accept that two untrusted programs can run on the GPU without eveasdropping on each other? even with IOMMU it seems. > gives me the impression that safely sharing the GPU is a work in progress / not very secure Defense in depth from not trusting MMU hardware that slightly changes it's interface to drivers every year and is different for every manufacturer, combined with the lack of documentation on said hardware. An IOMMU doesn't really address the problem because it doesn't provide a way to split a GPU, only to give it as a whole to another context. So for instance an IOMMU doesn't enable the ability to access the GPU from multiple VMs simultaneously either.

nextaccountic 4y ago

... but why does, when my X11 (happens in wayland too iirc) system has some kind of bug, one window displays the contents of another (with some graphical corruption)? my supposition was that a buffer of one program ending up in a VRAM associated with another program can only happen if there is no MMU, otherwise, what's the point also: do you happen to know why do Qubes folks think that it's okay for two mutually untrusted programs run on the CPU, but can't accept that two untrusted programs can run on the GPU without eveasdropping on each other? even with IOMMU it seems. it gives me the impression that safely sharing the GPU is a work in progress / not very secure

monocasa 4y ago
> ... but why does, when my X11 (happens in wayland too iirc) system has some kind of bug, one window displays the contents of another (with some graphical corruption)? > my supposition was that a buffer of one program ending up in a VRAM associated with another program can only happen if there is no MMU, otherwise, what's the point Because the compositor is running entirely in one GPU user context with access to the different windows. The different applications can't access each other, but the compositor can see all of their final display buffers. > also: do you happen to know why do Qubes folks think that it's okay for two mutually untrusted programs run on the CPU, but can't accept that two untrusted programs can run on the GPU without eveasdropping on each other? even with IOMMU it seems. > gives me the impression that safely sharing the GPU is a work in progress / not very secure Defense in depth from not trusting MMU hardware that slightly changes it's interface to drivers every year and is different for every manufacturer, combined with the lack of documentation on said hardware. An IOMMU doesn't really address the problem because it doesn't provide a way to split a GPU, only to give it as a whole to another context. So for instance an IOMMU doesn't enable the ability to access the GPU from multiple VMs simultaneously either.