Initially, Coreboot used CAR to store the C-stack in the L1 data cache: http://rere.qmqm.pl/~mirq/cache_as_ram_lb_09142006.pdf http://www.coreboot.org/images/6/6c/LBCar.pdf
To execute the code, we must switch the unified L2 to CAR mode, then L1i (you should know that most modern desktop / application processors are separated by L1: one for data - L1d - with read / write and the other - read-only L1i for code) will be able to read the code from CAR L2. This mode was implemented in the UBRX console - Universal BIOS Recovery for x86 ( akeo ) PC: http://pete.akeo.ie/2011/08/ubrx-l2-cache-as-instruction-ram.html
There are two L1 ondie caches: one for data and one for instructions, with one command being read-only. Thus, the CAR tuning method from coreboot provides access to the L1 data cache, and not to the first, so we cannot just load our code into L1-Data and wait for it to start.
There was also a commercial company that created a product to protect the code from Frozen memory attacks (when an attacker froze DRAM, pulled out a DRAM module and moved it to another PC to read, most of the data would be stored for tens of seconds). Their product loads all os / hypervisor kernels into the cache, and the code and data are stored inside the CPU. The product was vCage from PrivateCore (via Reverse Engineering for Docker Deployment in a Private Cloud and Preventing Reverse Engineering using Binary Code and Secret Key , thanks to AdamNYC user for information):
("The vCage host is packaged as a lifeless Linux KVM image on a RAM disk.")
https://security.stackexchange.com/questions/53165/is-it-possible-to-boot-an-encrypted-server-remotely-and-securely , comment .sex user northox security :
"In the case of vCage, you mostly need to trust Intel and Private Core. In short, vCage provides the L3 hypervisor verified through remote certification."
Check slide 36 https://forum.stanford.edu/events/2014/2014slides/plenary/Oded%20Stanford%20Annual%20Forum%202014.pdf#page=36
"The CPU as the perimeter of calculations • Physical security is the processor package itself • Loading stateless images into the processor cache"
The image is loaded into the processor cache (L3); and OS - Linux! (slide 39)
The biggest problems • Compressing the Linux kernel at <10 MB - Maintaining all virtualization features - Maintaining stability (without OOM) • Maintaining the CPU cache under our control
This means that vCage was able to execute code from the cache; but the company is no longer a public part of Facebook, so there are no new details or open source linux patches.