5 ms·
It may not be fully untrusted, but it's good to have barriers as well. Also, this problem is fundamental and not limited to a single core, package or machine.
by jeffdavis 6y ago
It may not be fully untrusted, but it's good to have barriers as well.
Also, this problem is fundamental and not limited to a single core, package or machine. Any time you are making opportunistic optimizations (of which caching is one), and the opportunities available depend on what happened outside of a privilege boundary, you can have this problem.
A similar thing happens at a higher level of abstraction with, for example, btree operation timings in a database.
- paulryanrogers 6y agoI wonder if we can make some of these mitigations conditional. When I'm doing key handling or online banking I want max protection. When gaming I want max performance. And I don't want to reboot to switch up kernel parameters.
- craftinator 6y agoI've done hardly any work on kernels before; would it be possible to make such a major change in the fly?
- saagarjha 6y agoI have not looked at the implementation, but I’m sure you could come up with a scheme that checked a flag on context switch and choose to clear the cache or not, which would mean you could ensure it takes effect the very next switch. In practice there may be practical or complexity constraints that would prevent this.
- monocasa 6y agoThe current patch set is implemented as a prctl that you can turn on and off at will.
- the8472 6y agoSome of the mitigations can be opted into on a per-process level via prctl