On Fri, Aug 14, 2020 at 11:09 AM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > On 8/14/20 10:46 AM, Andy Lutomirski wrote: > > I'm a little unconvinced about the security benefits. As far as I > > know, UC memory will not end up in cache by any means (unless > > aliased), but it's going to be tough to do much with UC data with > > anything resembling reasonable performance without derived values > > getting cached. > > I think this is much more in the category of raising the bar than > providing any absolute security guarantees. The problem here is that we're raising the bar in a way that is weirdly architecture dependent, *extremely* nonperformant, and may not even accomplish what it's trying to accomplish. > > Let's say you have a secret and you read it into some registers and then > spill them on the stack. You've got two cached copies, one for the > primary data and another for the stack copy. Secret areas don't get rid > of the stack copy, but they do get rid of the other one. One cache copy > is better than two. Bar raised. :) If we have two bars right next to each other and we raise one of them, did we really accomplish much? I admit that having a secret in its own dedicated cache line seems like an easier target than a secret in a cache line that may be quickly overwritten by something else. But even user registers right now aren't specially protected -- pt_regs lives is cached and probably has a predictable location, especially if you execve() a setuid program. > > There are also some stronger protections, less in the bar-raising > category. On x86 at least, uncached accesses also crush speculation. > You can't, for instance, speculatively get wrong values if you're not > speculating in the first place. I was thinking of things like Load > Value Injection[1]. This seems genuinely useful, but it doesn't really address the fact that requesting UC memory via PAT apparently has a good chance of getting WB anyway. > > I _believe_ there are also things like AES-NI that can get strong > protection from stuff like this. They load encryption keys into (AVX) > registers and then can do encrypt/decrypt operations without the keys > leaving the registers. If the key was loaded from a secret memory area > right into the registers, I think the protection from cache attacks > would be pretty strong. > Except for context switches :) > > 1. > https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection
