> The overwhelming majority of software authors are unconcerned about cross-process Spectre attacks, indicated by the fact that none of them enable IBPB. The only exception I've seen is Google Chrome.
As expected, Google goes the extra mile again to keep their users safe.
I believe Chrome is also the only software that enables certain mitigations such as ProcessSystemCallDisablePolicy on Windows and NO_SMT and TECS on macOS [1]. I wonder if some of these OS features have been implemented at Google's request.
However, in the case of Spectre, I think the OS should try to prevent exploitation rather than end programs, with a user-facing toggle to disable mitigations per-program for compatibility reasons.
WebKit definitely uses those, search the codebase for "TCSM". I would assume that the Chrome people either worked with Apple on it, or they reversed it from what WebKit was doing.
On the note of OS mitigations, I've been thinking that a heavy-handed but possibly necessary (at least for highly untrusted programs) approach is to trample all over a process' cache and other relevant microarchitectural affordances whenever the process is entered. Then it should prevent a wide range of attacks, including those unknown until now. A more targeted method is messing up, say, branch predictor state when a process is being exited (i.e. preempted). I find that less intuitively reassuring, but it would reduce performance impact. In any case, I don't find techniques like retpolines or Intel IBRS plausible in the general case, so I'm inclined to go scorched earth. Not that it would likely be popular with the performance cost.
misleading as chrome has recently gone to the trouble of removing adblock from their browser at a plumbing level, opening users up to malicious advertisements and trackers in search of google ad revenue. do not use chrome for the love of god.
From the writeup, it appears that microcode doesn't completely flush indirect branch predictions when instructed to do so, which leads to known cross-process attack techniques working again.
Frankly I'm not surprised. Beyond the initial scramble to deal with the huge open barn door that the first variants represented, the temperature on side channel attacks cooled for a bit. Given that it's extremely difficult to test any mitigation, due to noise, etc, it's not hard to imagine how this slipped through.
The performance/security tradeoff we constantly face in this area seems to be constantly drawn on the side of performance. Most people seem to believe that they're mostly running trusted code on their computers, and that trusted code shouldn't need security mitigations. I challenge that, as native applications, particularly on multi-user systems, already have a security model that is being violated by cross-process attacks. We shouldn't have the situation where some random third-party app has access to data in other processes, even if both are running as the same user. People working on the Linux kernel no doubt have a spectrum of opinions, but it's clear that the very, very conservative approach they've taken to mitigation puts performance as the #1 priority, which is exactly the default that got us into this situation.
Genuinely asking, regarding Spectre (including ARM), does it really push the argument towards running sensitive software outside the cloud, even when it's resource-wise convenient? Sure, owning your hardware gives you control, but the key to mitigating Spectre is isolation. If your cloud provider can guarantee that your VMs aren't sharing physical resources with other customers (or that those resources are strongly isolated), then the Spectre risk is arguably comparable to running on your own hardware. Top cloud providers have more resources and expertise to dedicate to security updates and mitigations than a smaller operation. Maybe the real question isn't 'cloud vs. on-premise', but rather 'how well-isolated am I from other tenants in any environment?
Yes, the "cloud vs on-prem" is not really interesting. Because one project must be well isolated from other projects, regardless of their owners : as such, inside a single compagny, we must isolate all projects from each others.
Do not fall into the "I put production on one side and preproduction on the other"
Cloud providers allows great isolation, even if many people fail to implement this (for instance, by using VPC-peering / network hub / shared VPC / whatever).
Indeed, one could implement this "on-prem": vxlan and friends are there for you. It does require some skills, tho.
I believe the backbone of infrastructure security lies in two pieces: first, the ability to deploy stuff easily, quickly, autonomously. Then, the ability to deploy stuff with no cost overhead (no "price per project" or whatever).
I love how far and and Intel have come, and how you can get a massive arm CPU, but these modern hardware security issues seem to be a more frequent issue(is this true?) And to stop them one takes a decent performance penalty..... Which is way less than ideal.
> The overwhelming majority of software authors are unconcerned about cross-process Spectre attacks, indicated by the fact that none of them enable IBPB. The only exception I've seen is Google Chrome.
As expected, Google goes the extra mile again to keep their users safe.
I believe Chrome is also the only software that enables certain mitigations such as ProcessSystemCallDisablePolicy on Windows and NO_SMT and TECS on macOS [1]. I wonder if some of these OS features have been implemented at Google's request.
However, in the case of Spectre, I think the OS should try to prevent exploitation rather than end programs, with a user-facing toggle to disable mitigations per-program for compatibility reasons.
[1] https://www.malwarebytes.com/blog/news/2021/08/macos-11s-hid...
WebKit definitely uses those, search the codebase for "TCSM". I would assume that the Chrome people either worked with Apple on it, or they reversed it from what WebKit was doing.
On the note of OS mitigations, I've been thinking that a heavy-handed but possibly necessary (at least for highly untrusted programs) approach is to trample all over a process' cache and other relevant microarchitectural affordances whenever the process is entered. Then it should prevent a wide range of attacks, including those unknown until now. A more targeted method is messing up, say, branch predictor state when a process is being exited (i.e. preempted). I find that less intuitively reassuring, but it would reduce performance impact. In any case, I don't find techniques like retpolines or Intel IBRS plausible in the general case, so I'm inclined to go scorched earth. Not that it would likely be popular with the performance cost.
misleading as chrome has recently gone to the trouble of removing adblock from their browser at a plumbing level, opening users up to malicious advertisements and trackers in search of google ad revenue. do not use chrome for the love of god.
From the writeup, it appears that microcode doesn't completely flush indirect branch predictions when instructed to do so, which leads to known cross-process attack techniques working again.
Frankly I'm not surprised. Beyond the initial scramble to deal with the huge open barn door that the first variants represented, the temperature on side channel attacks cooled for a bit. Given that it's extremely difficult to test any mitigation, due to noise, etc, it's not hard to imagine how this slipped through.
The performance/security tradeoff we constantly face in this area seems to be constantly drawn on the side of performance. Most people seem to believe that they're mostly running trusted code on their computers, and that trusted code shouldn't need security mitigations. I challenge that, as native applications, particularly on multi-user systems, already have a security model that is being violated by cross-process attacks. We shouldn't have the situation where some random third-party app has access to data in other processes, even if both are running as the same user. People working on the Linux kernel no doubt have a spectrum of opinions, but it's clear that the very, very conservative approach they've taken to mitigation puts performance as the #1 priority, which is exactly the default that got us into this situation.
Genuinely asking, regarding Spectre (including ARM), does it really push the argument towards running sensitive software outside the cloud, even when it's resource-wise convenient? Sure, owning your hardware gives you control, but the key to mitigating Spectre is isolation. If your cloud provider can guarantee that your VMs aren't sharing physical resources with other customers (or that those resources are strongly isolated), then the Spectre risk is arguably comparable to running on your own hardware. Top cloud providers have more resources and expertise to dedicate to security updates and mitigations than a smaller operation. Maybe the real question isn't 'cloud vs. on-premise', but rather 'how well-isolated am I from other tenants in any environment?
Yes, the "cloud vs on-prem" is not really interesting. Because one project must be well isolated from other projects, regardless of their owners : as such, inside a single compagny, we must isolate all projects from each others.
Do not fall into the "I put production on one side and preproduction on the other"
Cloud providers allows great isolation, even if many people fail to implement this (for instance, by using VPC-peering / network hub / shared VPC / whatever).
Indeed, one could implement this "on-prem": vxlan and friends are there for you. It does require some skills, tho.
I believe the backbone of infrastructure security lies in two pieces: first, the ability to deploy stuff easily, quickly, autonomously. Then, the ability to deploy stuff with no cost overhead (no "price per project" or whatever).
See original paper here:
https://comsec.ethz.ch/wp-content/files/ibpb_sp25.pdf
Is the old pentium safe? Or the and fx CPUs?
I love how far and and Intel have come, and how you can get a massive arm CPU, but these modern hardware security issues seem to be a more frequent issue(is this true?) And to stop them one takes a decent performance penalty..... Which is way less than ideal.
I think everything from Pentium Pro (except Bonnell-based Atom), AMD K5, Cyrix 6x86 and VIA Nano onwards is vulnerable.
I hate losing desktop CPU performance to an issue that would never affect me.