5 ms·

So many of the performance-reducing security are related to timing attacks. Would perhaps a solution to this be to have mixed cores: some cores intended for ma

So many of the performance-reducing security are related to timing attacks. Would perhaps a solution to this be to have mixed cores: some cores intended for managing passwords and other secure data with all the performance reducing mitigations to avoid timing attacks. Other cores completely unlocked, no mitigations, and intended for non-secure computation (gaming, number crunching, ...). Then let the OS and programmers ensure it's known which computation is marked as secure and which is not, to decide on which cores it can be ran.

bluGill 5y ago
No. I've erased this reply several times as I thought of a mitigation to the problem I was going to state - but in the end nothing mitigates everything. Most of the ways to make this work are hard to get right - it is too easy to forget to mark something as unsafe, or in some other way allow data to the fast cores that the fast cores shouldn't have. Even if you figure out how to do it though, you can still fall to a double failure: your safe code doesn't leak passwords via a timing attack, but via something else (buffer overflow?) it leaks the password to the unsafe side, which in turn leaks it via a timing attack.