I think you’re missing the point of this post. This isn’t a general purpose technique they are advocating, but rather an interesting method that might prove useful to someone.
It's definitely good to be aware of what tricks you have. Sometimes you need to do weird things like treat memory as hostile, see this article about chrome sandboxing: https://lwn.net/Articles/347547/
> So that's what we do: each untrusted thread has a trusted helper thread running in the same process. This certainly presents a fairly hostile environment for the trusted code to run in. For one, it can only trust its CPU registers - all memory must be assumed to be hostile. Since C code will spill to the stack when needed and may pass arguments on the stack, all the code for the trusted thread has to [be] carefully written in assembly.
> The trusted thread can receive requests to make system calls from the untrusted thread over a socket pair, validate the system call number and perform them on its behalf. We can stop the untrusted thread from breaking out by only using CPU registers and by refusing to let the untrusted code manipulate the VM in unsafe ways with mmap, mprotect etc.
It's not even a 'weird trick'; early-stage bootloader code and embedded systems often have to execute before RAM has been configured. This is a useful way to gain a little working space.
I'm not an assembly programmer, but is it possible there are benefits to treating SSE or AVX registers as a contiguous on-core buffer that are unrelated to performance?
I don't have enough experience with XMM registers (and SSE4 in general) to know if this is actually {useful,possible}, but a hypothetical use might be creating and using cryptographic keys such that the important numbers are never stored in main memory. If e.g. a decryption key is ever present in RAM, it's probably possible to steal it with a cold-boot attack that copies all of RAM. Once you have the RAM dump, the key can probably be found very quickly:
for (secret_key_t *p = 0; p < RAM_SIZE; p++) {
decode_with_key(p);
}
This does require significant physical access, but it works. I seem to remember reading ~1.5 years ago about a turnkey forensics kit (bottle of refrigerant included) for doing cold boot attacks? Regardless, more ways to protect keys is could be really useful.
Registers may be stored to RAM (though there are often local register files in the CPU). If you're on a modern x86 platform, you may have encrypted memory support.
For Intel, look up SGX. For AMD, look up SEV. Each of these is way more secure than reliance on registers as secure scratch memory.
SSE registers will never get stored to ram without emitting explicit instructions (or getting an interrupt) to do so on any Intel/amd cpu as far as I know. It can be tricky to deal with such situations, but if you have a stretch of code where you can stop that registers can be used to hide data from memory.