On Tue, Apr 26, 2016 at 12:41 PM, Pavel Machek <pavel@xxxxxx> wrote: > On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote: >> On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek <pavel@xxxxxx> wrote: >> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote: >> >> Intel(R) SGX is a set of CPU instructions that can be used by >> >> applications to set aside private regions of code and data. The code >> >> outside the enclave is disallowed to access the memory inside the >> >> enclave by the CPU access control. >> >> >> >> 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. This could probably be used for evil, but I think the evil uses are outweighed by the good uses. > > 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. There are some hints in the whitepapers that such a mechanism might be present on existing Skylake chipsets. I'm not really sure. > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- Andy Lutomirski AMA Capital Management, LLC _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
