55

Are GPUs vulnerable to spectre/meltdown attacks, since they have most of what makes CPUs attackable? Is there any information in the VRAM, that would cause trouble if it was stolen?

Bálint
  • 613
  • 1
  • 5
  • 8
  • 3
    source? I mean what makes you think a GPU has the most of what a CPU makes attackable? – LvB Jan 08 '18 at 10:47
  • @LvB I mean hardware wise. They have cache too for instance. – Bálint Jan 08 '18 at 10:48
  • 13
    Meltdown and Spectre are considered critical vulnerabilities because they can expose kernel memory and sensitive data, which **are known** to hold sensitive data like passwords. Assuming a similar attack was possible on a GPU, normally there wouldn't be much to steal or tamper with. GPU memory holds pixel data or moving particle information when running games or rendering apps. In the event GPU is used as mathematical accelerator the question is how much secrets should that GPU hold. Even in cryptocurrency mining, all information processed by CPU is to be made public soon. – usr-local-ΕΨΗΕΛΩΝ Jan 08 '18 at 12:41
  • Even moreso considering the rate at which these exploits run, as in a couple of hundred cycles to extract a single bit. Sure, in principle, in a perfect world, a trillion iterations shouldn't be able to reveal one bit. So, in principle, that's kinda _possibly_ worrysome when you're e.g. thinking about someone running the exploit undetected 24/7 over a few weeks to eventually spy out your server's password. But for most people most of the time, and in particular for data on a GPU which lives fractions of seconds or minutes at most, really... who cares? – Damon Jan 08 '18 at 13:12
  • @Damon It's more of a theoretical question – Bálint Jan 08 '18 at 13:17
  • 1
    FWIW, [nVidia says their GPUs are not vulnerable](http://nvidia.custhelp.com/app/answers/detail/a_id/4609). – aland Jan 08 '18 at 14:28
  • 23
    GPU's can also be used to implement generic cryptographic primitives, many of which rely on cryptographic keys. Crypto keys are generally considered sensitive data. So I don't think you can safely state that the memory of the GPU never contains sensitive data, or even data that is not sensitive enough. What about a password used for password hashing? GPU's are a perfect fit for that. – Maarten Bodewes Jan 08 '18 at 14:53
  • 17
    @usr-local-ΕΨΗΕΛΩΝ Pixel data definitely can be sensitive. Even pixel data from the same process. Consider for example [why browsers "taint" canvases with cross-origin data](https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image). – Bergi Jan 08 '18 at 15:21
  • 4
    Uninitialized textures in WebGL used to be a popular attack vector (at least in research; not sure how much they were exploited in the wild) because they leak(ed?) pixel data from other processes. I expect Meltdown and Spectre would be very hard to exploit on a GPU even if they're applicable, because shaders don't have access to timing functions. – user253751 Jan 09 '18 at 02:42
  • Graphic Memory do not have any Protection, so a GPU program can access the complete Graphic memory. – 12431234123412341234123 Jan 09 '18 at 13:43
  • Pixel data can contain password text or sensitive images and information currently stored away in VRAM or being actively rendered. A high-impact vulnerability like this one makes a possible exploitation much stealthier, even if it is already feasible to retrieve pixel data through other (known) means. – oldmud0 Jan 10 '18 at 06:07

4 Answers4

45

First of all you would not normally expect kernel memory to be mapped in a GPU. Even if you did modern GPU's generally don't have much in the way of support for sharing memory between processes.

There have certainly been research papers on speculative execution inside of a GPU - Speculative Execution on GPU: An Exploratory Study; Liu, Eisenbeis, Gaudiot - but I don't believe it is actively done at a hardware level by any existing devices.

So whilst theoretically there is nothing to stop you building a GPU/OS setup that may allow it I doubt this is possible on any existing products.

Hector
  • 10,893
  • 3
  • 41
  • 44
  • 10
    Note that Spectre doesn't attack kernel memory *specifically*. So the fact that kernel memory is not mapped is not a reason in itself why Spectre won't work; it just means that the secrets within it are secure if the kernel memory is entirely off limits (deleted more complex comment). – Maarten Bodewes Jan 08 '18 at 15:41
  • 2
    @MaartenBodewes The kernel mapping part probably refers to Meltdown. – Maya Jan 08 '18 at 17:14
  • 2
    Unless your machine has — and is using — an IOMMU, there's nothing, in principle, stopping the GPU from DMAing kernel memory. – al45tair Jan 08 '18 at 18:11
  • 5
    @alastair - Whilst there is nothing in theory stopping it DMAing kernel memory as far as I understand DMA the driver would normally pin a specific region of memory and instruct the device to use that. So unless an exploit in the GPU driver/firmware were found user level GPU code could not read arbitrary addresses. – Hector Jan 08 '18 at 20:22
  • 3
    Spectre requires more than just speculative execution, it needs a full out of order superscalar processor (note that both the bounds check, and the second load probably hit the same alu, so I think at least 2 integer alu's are needed). GPU's probably won't evolve in this direction, since they're all about scaling with explicit parallelism, not exploiting implicit parallelism. That paper you reference is not actually about speculative execution inside a GPU, but essentially cross compiling some code to act *like* speculative execution in a gpu. – Steve Cox Jan 09 '18 at 19:09
  • 2
    ... Explicitly writing a speculative branch around a bounds check on privileged memory (how spectre works) would be extremely careless. Meltdown is really an entirely separate issue from spectre, and it's cause by a careless flaw in the specific design of a VIPT l1 cache and how it handles misses and page faults. It probably will only ever effect intel, now that its extremely famous and 'l1 cache design 101' will keep students informed on this fiasco forever. – Steve Cox Jan 09 '18 at 19:10
  • @SteveCox "Explicitly writing a speculative branch around a bounds check on privileged memory (how spectre works) would be extremely careless" You wouldn't do it on purpose, but in theory your compiler might optimise your code that way, and you almost certainly wouldn't think about it (at least not before Spectre was announced) – rjmunro Jan 10 '18 at 10:18
  • @rjmunro yeah i didn't want to get into that too much, but at that point, it's solidly not a hardware bug, and definitely a compiler implementation bug. No compiler should move an access before a bounds check. – Steve Cox Jan 10 '18 at 14:44
  • @Hector If you mean BARs, isn't that only for host to GPU DMA (i.e. the memory address that userspace sees that is mapped to a region in VRAM)? For GPU to host DMA, the GPU can write _anywhere_ it sees fit, not taking into account the regular 4 GiB limit in some situations. Only DMAR (with an IOMMU) can force it to only write to a specific region of memory. – forest Jun 17 '18 at 02:14
  • Oh, I think I get what you mean now. Actually, userspace could adjust the PCI BARs and use that to write to arbitrary VRAM. All that it requires is the ability to write to the PCI configuration space. It wouldn't necessarily be super efficient since you'd have to adjust the BARs every time you want a new some-dozen-megabyte window to write to, but it's absolutely possible. – forest Jun 17 '18 at 02:36
18

A GPU (Graphical Processing Unit) is not vulnerable to spectre/meltdown attacks.

This is due to various reasons:

  1. A GPU is a completely differently designed processor.
  2. It does not run privileged code (e.g. kernel code).
  3. It does not run the OS.
  4. It is optimized for Vector calculations.
  5. Its micro code is build completely differently.
  6. It (most often) does not have protection for privileged code (like the execution rings on a CPU).
  7. It does not have access to the CPU's registers (directly), it does have DMA (Direct Memory Access) but so do a lot of other devices.
  8. There is only limited research on this done by security experts, so no one is sure if it's not vulnerable.
  9. As for having the same parts, those parts are either shared between many devices or nowhere similar in design. a GPU's memory or example is differently mapped than a CPU's memory (although they share an electrical standard).
  10. The DMA access should be limited to the current execution level, since the Graphics card is normally controlled by the Kernel, no user level application can directly access it. Or send code to it. (Drivers exist to facilitate user level access and to limit what they can do. As to maximize the usable features. And not blow the card up (by setting illegal settings for example).
  11. Code that can run on the GPU is highly limited in what it can execute (instruction set is limited) DMA is for example only allowed indirectly (first load it into the Graphics cards memory than access is granted and visa versa).

tldr; GPUs are not CPUs and are not designed to be multi-user / application. They have some protection against abuse but most of this is not yet tested by security experts.

muru
  • 364
  • 1
  • 3
  • 14
LvB
  • 8,217
  • 1
  • 26
  • 43
  • 13
    Points 1, 5, 9 and 10 are only likely to avoid Spectre style attacks, and points 2, 3, 4, 6, 8 don't seem to avoid Spectre style attacks at all. E.g. the fact that kernel space memory is likely not accessible doesn't prevent attacks on the memory of other processes. I'm not so sure that the GPU is that limited anymore if you can implement cryptographic primitives on it. I think the absence of sharing memory between applications and speculative execution is much more important than all the points listed here. – Maarten Bodewes Jan 08 '18 at 14:48
  • 2
    using a GPU for Cryptographic primitives as a special use-case and usually will consume the while device for this use (blocking all other use) the kernel is supposed to limit access to the data on it . In order to utilize spectre / meltdown you need to predict memory actions, something you have some control over with a CPU (hence the vulnr.) but none with DMA (the DMA chip does however but thats out of scope). also for using a GPU as a processor you have to load the data into it and retrieve it from it. its a separated process that has no direct connection with the cpu. – LvB Jan 08 '18 at 17:04
  • 3
    This answer assumes a GPU from around 2005. A modern GPU with NVidia CUDA or OpenCL is a different beast. It runs arbitrary code, _by design_, and in violation of assumption 10. Also, "current execution level" is a CPU concept that does not exist in RAM or DMA, and GPU's can use main RAM directly over the PCIe bus. – MSalters Jan 09 '18 at 10:18
  • @MSalters - I haven't actually looked into this in detail, but are you really saying that a modern GPU can be fed code by a user level process that can arbitrarily instruct the card to use DMA to access any memory in the entire system? That seems like a serious flaw just waiting to be exploited, if true. – Jules Jan 10 '18 at 01:05
  • @MSalters, No, you can feed it user level code if the driver allows it (so a syscall has to allow the code transfer). and you can ask the driver to do the DMA for you. (so on linux it requires a kernel syscall as I understand it) – LvB Jan 10 '18 at 09:12
  • @Jules: Sort of. You feed the GPU code to the GPU driver, and it will prepare the RAM mappings. Since the GPU driver runs on the CPU in kernel mode, it already has access to all RAM, which automatically means it's part of the security infrastructure. A poor GPU driver could indeed allow access to all RAM. But that actually holds for _all_ drivers. – MSalters Jan 10 '18 at 10:09
  • on points 1 and 5: ARM processors also have a design different from x86 processors (although probably closer to x86 than GPU processors) yet ARM has published [a list of cores vulnerable to Spectre](https://developer.arm.com/support/security-update). Also point 8 is in contradiction with the claim in the first sentence that GPUs are not vulnerable. – Andre Holzner Jan 10 '18 at 12:13
  • ARM, a standard for RISC Generic computer processors, has several diffrent sets of Computer instructions. some more minimal than others. In order to be vulnerable to SPECTRE type attacks you need the predictive instruction sets like all CISC processors have. Most ARM processors do not have this feature so are not at risk. As to the difference in design. a GPU is designed for Vector type calculations (e.a. matrix calculations) a CPU is designed for Integer/ Floating Point calculations. This influences how many parts of the Processor function and how it uses memory. – LvB Jan 11 '18 at 11:11
17

Nvidia has released updates today (Jan 9 2018) dealing with the issues. So I would assume there are risks since they have created updates.

http://us.download.nvidia.com/Windows/390.65/390.65-win10-win8-win7-desktop-release-notes.pdf

Table 2.1 Security Updates for NVIDIA Software Vulnerabilities CVE ID NVIDIA Issue Number Description CVE-2017-5753 1975134 Computer systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis. For more information on this issue, see the NVIDIA GPU security updates for speculative side channel Security Bulletin posted on the NVIDIA Product Security page

And specifically mentions GeForce in the aforementioned post http://nvidia.custhelp.com/app/answers/detail/a_id/4611

Affected Products

Product                | OS
GeForce, Quadro, NVS   | Windows, Linux, FreeBSD, Solaris
Tesla                  | Windows, Linux
Viktor Mellgren
  • 279
  • 1
  • 7
  • 2
    Note the gcloud employs GPU virtualization, so the threat is indeed real. – user14717 Jan 09 '18 at 17:55
  • 7
    These are mitigations for vulnerabilities in driver code that runs on the cpu *not* gpu – Steve Cox Jan 09 '18 at 19:38
  • 7
    "NVIDIA’s core business is GPU computing. We believe our GPU hardware is immune to the reported security issue and are updating our GPU drivers to help mitigate the CPU security issue. As for our SoCs with ARM CPUs, we have analyzed them to determine which are affected and are preparing appropriate mitigations." http://nvidia.custhelp.com/app/answers/detail/a_id/4609 – rsanchez Jan 09 '18 at 22:36
  • 3
    Current defense strategies against Spectre include replacing *all* indirect branches in the kernel with [retpolines](https://stackoverflow.com/questions/48089426/what-is-a-retpoline-and-how-does-it-work). GPU drivers run on the CPU in kernel mode, so this is almost certainly about defending against the CPU vulnerability in privileged part of the drivers. – Peter Cordes Jan 10 '18 at 02:13
  • 1
    As far as I can understand the Nvidia technical notes on this the way the GPU deals with memory mapped via PICe onto the PC memory makes it possible to read the memory of another process on the PC (including memory belonging to another VM hosted on that PC) through the GPU. So yes. GPU's can apparently be affected, but as far as I can tell only if PCIe mapped memory is used. – Tonny Jan 10 '18 at 15:35
1

Fundamentally Meltdown and Spectre are side channel attacks which exploit the weaknesses of unprivileged and privileged processes sharing the same resources, the availability of resources being unprotected information, and where the unprivileged side can trick the privileged side into consuming resources in a way that depends on a secret, even though and because the request is ultimately canceled or rejected. The GPU certainly shares resources and unprivileged processes can run code there. If that code can detect resource conflicts and request data it's not supposed to (and won't) receive, I wouldn't rule out the possibility of similar attacks involving the GPU.

dawroq
  • 11
  • 3