Re:Robust and Efficient Elimination of Cache and Timing Side...
by comex on Friday January 05, 2018 @11:43PM
(#16083895)
Their performance results depend on isolating “protected” functions that access sensitive data, while keeping the rest of the code unprotected. That’s fine in a sane world, but with Spectre, just about any code can be tricked into speculatively accessing sensitive data in its address space. So trying to adapt this into a Spectre mitigation reduces to just flushing all CPU caches on every context switch (plus giving each core a separate chunk of the L3 cache, which is supposed to be shared). That would be… not pretty, from a performance standpoint.
[ Parent
| on HN ]
Re:Robust and Efficient Elimination of Cache and Timing Side...
by KirinDave on Saturday January 06, 2018 @01:38AM
(#16084163)
Consider though: a similar logic has lead us to not flush the cache, and here we are.
Until we have better ways of reasoning about and restricting the code we are running, it isn't going to get prettier. Conservative approaches like this may not be best for every propose, but in hardened code like a hypervisor it might make sense.
Re:Robust and Efficient Elimination of Cache and Timing Side...
by srett on Saturday January 06, 2018 @06:08AM
(#16084765)
Isn't the problem rather that we have instructions to control the cache at all? As far as my research goes, things like CLFLUSH were introduced at the same time as SSE2, which was what, the Pentium III era? We were apparently doing fine without them before that, even with 4+ CPU systems.
I'm currently trying to get the spectre.c PoC to work without using CLFLUSH or similar, but it doesn't look too promising yet. Then again, I only started an hour ago and lack the ability to think in those creative and twisted ways that lead to the discovery of this whole issue in the first place.