Hi! > >> >> The firmware uses PRMRR registers to reserve an area of physical memory > >> >> called Enclave Page Cache (EPC). There is a hardware unit in the > >> >> processor called Memory Encryption Engine. The MEE encrypts and decrypts > >> >> the EPC pages as they enter and leave the processor package. > >> > > >> > What are non-evil use cases for this? > >> > >> Storing your ssh private key encrypted such that even someone who > >> completely compromises your system can't get the actual private key > > > > Well, if someone gets root on my system, he can get my ssh private > > key.... right? > > > > So, you can use this to prevent "cold boot" attacks? (You know, > > stealing machine, liquid nitrogen, moving DIMMs to different machine > > to read them?) Ok. That's non-evil. > > Preventing cold boot attacks is really just icing on the cake. The > real point of this is to allow you to run an "enclave". An SGX > enclave has unencrypted code but gets access to a key that only it can > access. It could use that key to unwrap your ssh private key and sign > with it without ever revealing the unwrapped key. No one, not even > root, can read enclave memory once the enclave is initialized and gets > access to its personalized key. The point of the memory encryption > engine to to prevent even cold boot attacks from being used to read > enclave memory. Ok, so the attacker can still access the "other" machine, but ok, key is protected. But... that will mean that my ssh will need to be SGX-aware, and that I will not be able to switch to AMD machine in future. ... or to other Intel machine for that matter, right? What new syscalls would be needed for ssh to get all this support? > > Is there reason not to enable this for whole RAM if the hw can do it? > > The HW can't, at least not in the current implementation. Also, the > metadata has considerable overhead (no clue whether there's a > performance hit, but there's certainly a memory usage hit). :-(. > >> out. Using this in conjunction with an RPMB device to make it Rather > >> Difficult (tm) for third parties to decrypt your disk even if you > >> password has low entropy. There are plenty more. > > > > I'm not sure what RPMB is, but I don't think you can make it too hard > > to decrypt my disk if my password has low entropy. ... And I don't see > > how encrypting RAM helps there. > > Replay Protected Memory Block. It's a device that allows someone to > write to it and confirm that the write happened and the old contents > is no longer available. You could use it to implement an enclave that > checks a password for your disk but only allows you to try a certain > number of times. Ookay... I guess I can get a fake Replay Protected Memory block, which will confirm that write happened and not do anything from China, but ok, if you put that memory on the CPU, you raise the bar to a "rather difficult" (tm) level. Nice. But that also means that when my CPU dies, I'll no longer be able to access the encrypted data. And, again, it means that quite complex new kernel-user interface will be needed, right? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
