4 ms·

> Unfortunately "install a piece of software" also includes allowing javascript to run in your browser. Per-process Spectre mitigations could be helpful there,

by hjek 5y ago

> Unfortunately "install a piece of software" also includes allowing javascript to run in your browser. Per-process Spectre mitigations could be helpful there, but I don't understand the technical details to know whether that would be possible to implement. It would be nice to disable mitigations on a video editor and for gaming.

pjmlp 5y ago
If gaming implies a MMO, a possible attack vector is attacking users to get hold of their gaming account details and do as they please.
- usrusr 5y ago
  The way I understand it (not that well, admittedly), per-process mitigations would be all about keeping that process from reading other memory areas, not about protecting that process from others. Which is better than the reverse if your intention is to allow some processes to run random js.
  - pjmlp 5y ago
    Yeah, but in the context of games, most likely it means threaded code written in C or C++. If anything Spectre has shown us that the only real mitigation is to go back to multiprocessing with IPC, with the extra hardware resources it entails, as the exploit exists regardless of the language for in-process memory.
  - genmud 5y ago
    The problem with spectre/meltdown is they don't use standard calls to ask for memory of other processes... that is the vulnerability. If you were do to do per process mitigation it would need to prevent certain process execution flows from happening, because the vulnerability is a problem with the CPU pulling memory from the way speculative execution works. This actually impacts things that are typically protected and is much more impactful than people think... for example, because the bug allows reading from nearly any memory address space, you could also pull in things like crypto keys from the OS or passwords from memory.
    - usrusr 5y ago
      Yeah, but if you can mitigate per process, you can keep the secrets of trusted code from the eyes of untrusted code by only affecting the performance of the untrusted processes. The way I understand it the "protection cost" would fall on potential attackers, not on potential victims (unless of course they are both, holders of secrets and runners of untrusted code).
      - genmud 5y ago
        Unfortunately, that is incorrect understanding. In the context of stuff like this, "untrusted code" can be so many different things, it isn't just being able to run an executable... The issue with these vulnerabilities is the processor "pre-runs/prefetches" certain things for performance, which would likely be run in the future, so that it has those results cached, or to increase the amount of instructions in a CPU cycle. The issue is that many of these things aren't direct executable code, but more like access patterns. For example, a speculative execution vulnerability might exist when there is a string of data in memory that has a memcp pattern, with memory addresses that are valid. To speed up the execution of programs, the processor might proactively read the memory from that memcp pattern because it is sending a command to the memory controller already. Many of the mitigation techniques are to flush the caches/buffers and be careful about memory reads, which are the precise things that actually take the performance hits. And one of the problems is since they are access patterns, the vulnerabilities can be the html renderer compiled with an application, an SVG rendering library or a mail client. For example, lets say there are mitigations built into the JS library... if you build a specifically crafted SVG, you could create similar access patterns to get around it. Its a huge cat and mouse game if there aren't OS protections and it only takes a single app to lose your secrets stored in memory.
temac 5y ago
Opt-in per-process spectre mitigation is already the case for some of them, because the mitigations in question are way too costly. Now it is not possible for every kind of mitigations, because e.g. patching the kernel between mitigated processes and unmitigated ones would be more costly than just always running the mitigations. edit: thinking more about it: you could have crazy ideas like two versions of the whole kernel space always loaded :D not sure about the cache impact in this case though.

by hjek 5y ago

pjmlp 5y ago

If gaming implies a MMO, a possible attack vector is attacking users to get hold of their gaming account details and do as they please.

usrusr 5y ago
The way I understand it (not that well, admittedly), per-process mitigations would be all about keeping that process from reading other memory areas, not about protecting that process from others. Which is better than the reverse if your intention is to allow some processes to run random js.
- pjmlp 5y ago
  Yeah, but in the context of games, most likely it means threaded code written in C or C++. If anything Spectre has shown us that the only real mitigation is to go back to multiprocessing with IPC, with the extra hardware resources it entails, as the exploit exists regardless of the language for in-process memory.
- genmud 5y ago
  The problem with spectre/meltdown is they don't use standard calls to ask for memory of other processes... that is the vulnerability. If you were do to do per process mitigation it would need to prevent certain process execution flows from happening, because the vulnerability is a problem with the CPU pulling memory from the way speculative execution works. This actually impacts things that are typically protected and is much more impactful than people think... for example, because the bug allows reading from nearly any memory address space, you could also pull in things like crypto keys from the OS or passwords from memory.
  - usrusr 5y ago
    Yeah, but if you can mitigate per process, you can keep the secrets of trusted code from the eyes of untrusted code by only affecting the performance of the untrusted processes. The way I understand it the "protection cost" would fall on potential attackers, not on potential victims (unless of course they are both, holders of secrets and runners of untrusted code).
    - genmud 5y ago
      Unfortunately, that is incorrect understanding. In the context of stuff like this, "untrusted code" can be so many different things, it isn't just being able to run an executable... The issue with these vulnerabilities is the processor "pre-runs/prefetches" certain things for performance, which would likely be run in the future, so that it has those results cached, or to increase the amount of instructions in a CPU cycle. The issue is that many of these things aren't direct executable code, but more like access patterns. For example, a speculative execution vulnerability might exist when there is a string of data in memory that has a memcp pattern, with memory addresses that are valid. To speed up the execution of programs, the processor might proactively read the memory from that memcp pattern because it is sending a command to the memory controller already. Many of the mitigation techniques are to flush the caches/buffers and be careful about memory reads, which are the precise things that actually take the performance hits. And one of the problems is since they are access patterns, the vulnerabilities can be the html renderer compiled with an application, an SVG rendering library or a mail client. For example, lets say there are mitigations built into the JS library... if you build a specifically crafted SVG, you could create similar access patterns to get around it. Its a huge cat and mouse game if there aren't OS protections and it only takes a single app to lose your secrets stored in memory.

temac 5y ago

Opt-in per-process spectre mitigation is already the case for some of them, because the mitigations in question are way too costly. Now it is not possible for every kind of mitigations, because e.g. patching the kernel between mitigated processes and unmitigated ones would be more costly than just always running the mitigations. edit: thinking more about it: you could have crazy ideas like two versions of the whole kernel space always loaded :D not sure about the cache impact in this case though.