[gcr]

Is there any modern kernel in widespread use that runs while encrypted in RAM?

What kind of attacks would encrypting a running kernel prevent? The kernel and hardware work together to enforce memory safety, so it can't be to prevent a rogue process from reading kernel memory...

Edit: Is this talking about encrypting the kernel image in permanent storage, or encrypting a running kernel in RAM? When booting Linux for example, the boot loader will load the Linux kernel image into memory as a gzip-compressed blob. The kernel's first instructions are a small decompressor program that unpack the rest of the kernel image into memory and then jumps into the uncompressed kernel. Did previous iOS versions do something similar to their saved kernel image?

[jevinskie]

Permanent storage. The kernelcache is lzss compressed and encrypted with AES. I forget the details of signature verification at the moment, but that is done using RSA. The iBoot bootloader handles all of the decompression, decryption, and signature verification.

[crypty]

> encrypting a running kernel in RAM

How is that supposed to work? Ok, the CPU can fetch an encrypted instruction, decrypt it and execute it, but when it needs to jump, how is it supposed to know where to jump? Also encrypting each instruction separately and independently would be trivial to reverse.

Is there any system that really runs encrypted code from RAM? Any papers describing such a system?

[evgen]

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.

[Dylan16807]

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.)

[wepple]

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.

[evgen]

Typo on my part, it was L3.

[crypty]

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?

[TickleSteve]

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).

[crypty]

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.

[TickleSteve]

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.