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?
3source? I mean what makes you think a GPU has the most of what a CPU makes attackable?– LvBJan 8, 2018 at 10:47
13Meltdown 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 8, 2018 at 12:41
23GPU'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 BodewesJan 8, 2018 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.– BergiJan 8, 2018 at 15:21
4Uninitialized 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.– user253751Jan 9, 2018 at 2:42
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.
10Note 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). Jan 8, 2018 at 15:41
2@MaartenBodewes The kernel mapping part probably refers to Meltdown.– MayaJan 8, 2018 at 17:14
2Unless your machine has — and is using — an IOMMU, there's nothing, in principle, stopping the GPU from DMAing kernel memory.– al45tairJan 8, 2018 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.– HectorJan 8, 2018 at 20:22
3Spectre 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. Jan 9, 2018 at 19:09
A GPU (Graphical Processing Unit) is not vulnerable to spectre/meltdown attacks.
This is due to various reasons:
- A GPU is a completely differently designed processor.
- It does not run privileged code (e.g. kernel code).
- It does not run the OS.
- It is optimized for Vector calculations.
- Its micro code is build completely differently.
- It (most often) does not have protection for privileged code (like the execution rings on a CPU).
- 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.
- There is only limited research on this done by security experts, so no one is sure if it's not vulnerable.
- 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).
- 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).
- 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.
13Points 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. Jan 8, 2018 at 14:48
2using 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.– LvBJan 8, 2018 at 17:04
3This 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.– MSaltersJan 9, 2018 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.– JulesJan 10, 2018 at 1: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)– LvBJan 10, 2018 at 9:12
Nvidia has released updates today (Jan 9 2018) dealing with the issues. So I would assume there are risks since they have created updates.
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
2Note the gcloud employs GPU virtualization, so the threat is indeed real. Jan 9, 2018 at 17:55
7These are mitigations for vulnerabilities in driver code that runs on the cpu not gpu Jan 9, 2018 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." nvidia.custhelp.com/app/answers/detail/a_id/4609– rsanchezJan 9, 2018 at 22:36
3Current defense strategies against Spectre include replacing all indirect branches in the kernel with retpolines. 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. Jan 10, 2018 at 2:13
1As 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.– TonnyJan 10, 2018 at 15:35
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.