2 ms·

> Is there a fundamental reason we cannot make speculative execution secure? It is secure in many, many contexts. For example, I have no concerns about specula

> Is there a fundamental reason we cannot make speculative execution secure? It is secure in many, many contexts. For example, I have no concerns about speculative execution if I'm running a database or service, which is great since those are the areas where performance matters most. Where it's troublesome is when you need isolation in the presence of arbitrary code execution. My suggestion is that if you ever find yourself in that scenario that you manage your cores manually - ensure that "attacker" code never crosses with anything sensitive on the same core. If you need that next level of security, enable the mitigations. Pinning your cores is going to help a lot with the mitigations anyways - the TLB doesn't have to be flushed in circumstances where the same process on the same core is switched in, or something like that (someone please explain more, I forget and I don't want to look it up right now). There's some process context id cache blah blah blah, the point is that you can improve things if you pin to a core. I think basically you're right. Instead of removing an amazing optimization let's find the areas where we can enable it, understand the threat model where it's relevant, and find ways to either reduce the cost of mitigations or otherwise mitigate in a way that's free.

fbdab103 3y ago
Is it easy to automatically and exclusively pin an application to some cores? Firefox automatically gets assigned two cores, and no other work is allowed there? I know I theoretically have the ability to set affinity, but have never explored it. Are there performance gotchas (outside of losing all core access)? Perhaps performance could even see minor improvement?
- insanitybit 3y ago
  Yeah it's fairly straightforward. You can boot your OS such that it won't schedule work on a set of cores unless you explicitly tell it to, which ensures isolation. You just have to pass the core numbers in. Otherwise it's possible to do it all in userland but it's not as reliable since a new process could spawn and you'd have to handle its affinity - it's way easier to just do the process core boot flags. > Are there performance gotchas (outside of losing all core access)? Depends on the workload and how the program is built. If you need to run tons of different processes concurrently (the 'user desktop' use case) it is not great. If your concurrency model requires creating hundreds of threads (Java, for most of the time it existed) it may not work well, especially if the threads don't have an even distribution of work (so you may see increased tail latencies). And, of course, if you have 8 cores but you isolate a workload to 6, you've just lost 2 cores that could have been used. > Perhaps performance could even see minor improvement? Considerable improvement, potentially. Less CPU synchronization means fewer L3 flushes, you'll get fewer context switches since your scheduler won't need to try to schedule other threads onto your core, fewer TLB flushes (relevant for kPTI/Meltdown mitigations), etc. If you lean into this approach you can get best in class throughput.

fbdab103 3y ago

Is it easy to automatically and exclusively pin an application to some cores? Firefox automatically gets assigned two cores, and no other work is allowed there? I know I theoretically have the ability to set affinity, but have never explored it. Are there performance gotchas (outside of losing all core access)? Perhaps performance could even see minor improvement?

insanitybit 3y ago
Yeah it's fairly straightforward. You can boot your OS such that it won't schedule work on a set of cores unless you explicitly tell it to, which ensures isolation. You just have to pass the core numbers in. Otherwise it's possible to do it all in userland but it's not as reliable since a new process could spawn and you'd have to handle its affinity - it's way easier to just do the process core boot flags. > Are there performance gotchas (outside of losing all core access)? Depends on the workload and how the program is built. If you need to run tons of different processes concurrently (the 'user desktop' use case) it is not great. If your concurrency model requires creating hundreds of threads (Java, for most of the time it existed) it may not work well, especially if the threads don't have an even distribution of work (so you may see increased tail latencies). And, of course, if you have 8 cores but you isolate a workload to 6, you've just lost 2 cores that could have been used. > Perhaps performance could even see minor improvement? Considerable improvement, potentially. Less CPU synchronization means fewer L3 flushes, you'll get fewer context switches since your scheduler won't need to try to schedule other threads onto your core, fewer TLB flushes (relevant for kPTI/Meltdown mitigations), etc. If you lean into this approach you can get best in class throughput.