Hacker News new | ask | show | jobs
by evgen 3647 days ago
A company that Facebook acquired a couple of years ago (PrivateCore) realized that the L1 cache had grown large enough that you could run a hypervisor out of it. You use a TPM secure boot chain to ensure you are booting the code you need into the hardware you expect, load up the hypervisor and its keys, and then this hypervisor is used to encrypt _everything_. Now you have encrypted RAM, so physical possession of a running device gets you nothing at all.
2 comments

L1 had grown large enough? What do you mean? L1 was 32KB in the Pentium II days, and for the last ten years of Intel chips it's been an unchanging 64KB. Why would it have to fit into L1 specifically, rather than L2/L3? (If you do use L2/L3, that's also been big enough to spare the space for a hypervisor since the Pentium II, which had 512KB.)
Looks like they do use L3, alongside an number of other intel x86 features (not surprisingly things like AES-NI)

https://privatecore.com/wp-content/uploads/2014/02/pr-privat...

Sorry couldn't copy/paste relevant section; formatting went horrible.

Typo on my part, it was L3.
What does it do with the encrypted RAM? The only possibility I see is to take an sufficiently large block, decrypt it into the cache an run it there. But then again if you need to jump out of the block how does the CPU know which block to decrypt next?
page faults.... the hypervisor encrypts/decrypts on-demand. Much the same as virtual memory works (just that the plain-text data is only ever in the internal cache).
My point is that it is impossible to know where the next code chunk is if it is properly encrypted. How does the page fault handler know which block to decrypt next without first decrypting the whole code module, where module is a closed piece of code without jumps outside.

In my opinion every scheme to enable that will cripple the encryption.

the code is decrypted into internal SRAM. executed normally. then an entirely normal page-fault happens at which point the hypervisor catches the trap and decrypts the data again into internal SRAM and maps it appropriately then allows the access to continue.
Will SGX help this feature?