Timeline for Spectre/meltdown on a GPU
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 11, 2018 at 11:11 | comment | added | LvB | 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. | |
| Jan 10, 2018 at 12:13 | comment | added | Andre Holzner | 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. Also point 8 is in contradiction with the claim in the first sentence that GPUs are not vulnerable. | |
| Jan 10, 2018 at 10:09 | comment | added | MSalters | @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. | |
| S Jan 10, 2018 at 9:12 | history | suggested | muru | CC BY-SA 3.0 |
clarified what a GPU is not, typo in e.g.
|
| Jan 10, 2018 at 9:12 | comment | added | LvB | @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) | |
| Jan 10, 2018 at 5:54 | review | Suggested edits | |||
| S Jan 10, 2018 at 9:12 | |||||
| Jan 10, 2018 at 1:05 | comment | added | Jules | @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. | |
| Jan 9, 2018 at 10:18 | comment | added | MSalters | 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. | |
| Jan 8, 2018 at 17:04 | comment | added | LvB | 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. | |
| Jan 8, 2018 at 14:48 | comment | added | Maarten Bodewes | 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. | |
| Jan 8, 2018 at 14:39 | history | edited | Maarten Bodewes | CC BY-SA 3.0 |
added 13 characters in body
|
| Jan 8, 2018 at 14:16 | history | edited | Uwe Keim | CC BY-SA 3.0 |
Some spelling/casing corrections.
|
| Jan 8, 2018 at 11:06 | history | answered | LvB | CC BY-SA 3.0 |