4 ms·

One thing I'm not seeing mentioned is the security implications of running a filesystem in VRAM. Unless things have changed, GPU VRAM is basically free-for-all

by Taek 4y ago

One thing I'm not seeing mentioned is the security implications of running a filesystem in VRAM. Unless things have changed, GPU VRAM is basically free-for-all and any application can do read/write operations anywhere in the memory bank. There are certain scenarios where this is okay but lots of scenarios where it is not (example: webgl)

londons_explore 4y ago
Webgl gets to read memory that isn't its own? That can't be right... There would be massive info leaks...
- flohofwoe 4y ago
  Yeah, it isn't right. In the very early WebGL days there have been a handful of implementation bugs where previous VRAM content was accidentally exposed in textures, but these things have been fixed quickly. AFAIK, most of this is now also taken care of down on the hardware and driver level.
monocasa 4y ago
Things have in fact changed. GPUs overwhelmingly have their own MMU to seperate different user contexts, including as accessed through their DMA engines. The few cases under Linux that don't such as the Raspberry PI's GPU instead use the kernel to wrap any submissions to the GPU where they can abstract and validate access to memory.
- nextaccountic 4y ago
  How can I search for whether my GPU supports this? My GPU is a Radeon HD 8670M, on a very recent laptop Is this the IOMMU (which isn't generally supported, except on high end hardware [0]) or something else? I think my GPU doesn't support IOMMU [0] https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardw...
  - monocasa 4y ago
    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.
userbinator 4y ago
VRAM is accessible via an aperture in physical address space (I believe it's bank-switched for GPUs with more VRAM than the aperture size), which normally isn't directly accessible to user-mode applications, much like most hardware on Linux.
flohofwoe 4y ago
WebGL goes to great lengths to not expose any 'junk' VRAM data or allow out-of-bounds access even on old GPUs. But for the last decade or so, GPUs and their drivers implement the same memory protection mechanisms as CPUs (and AFAIK WebGL was a major driving force in that area).
tenebrisalietum 4y ago
Use LUKS to encrypt it.

by Taek 4y ago

londons_explore 4y ago

Webgl gets to read memory that isn't its own? That can't be right... There would be massive info leaks...

flohofwoe 4y ago
Yeah, it isn't right. In the very early WebGL days there have been a handful of implementation bugs where previous VRAM content was accidentally exposed in textures, but these things have been fixed quickly. AFAIK, most of this is now also taken care of down on the hardware and driver level.

monocasa 4y ago

Things have in fact changed. GPUs overwhelmingly have their own MMU to seperate different user contexts, including as accessed through their DMA engines. The few cases under Linux that don't such as the Raspberry PI's GPU instead use the kernel to wrap any submissions to the GPU where they can abstract and validate access to memory.

nextaccountic 4y ago
How can I search for whether my GPU supports this? My GPU is a Radeon HD 8670M, on a very recent laptop Is this the IOMMU (which isn't generally supported, except on high end hardware [0]) or something else? I think my GPU doesn't support IOMMU [0] https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardw...
- monocasa 4y ago
  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.

userbinator 4y ago

VRAM is accessible via an aperture in physical address space (I believe it's bank-switched for GPUs with more VRAM than the aperture size), which normally isn't directly accessible to user-mode applications, much like most hardware on Linux.

flohofwoe 4y ago

WebGL goes to great lengths to not expose any 'junk' VRAM data or allow out-of-bounds access even on old GPUs. But for the last decade or so, GPUs and their drivers implement the same memory protection mechanisms as CPUs (and AFAIK WebGL was a major driving force in that area).

tenebrisalietum 4y ago

Use LUKS to encrypt it.