4 ms·

I think you’re missing the point. This is only useful if there is actually a measureable benefit.

lgas 9y ago
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?
- kindfellow92 9y ago
  In the style of this article, Most probably not.
- pdkl95 9y ago
  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. https://en.wikipedia.org/wiki/TRESOR https://en.wikipedia.org/wiki/TRESOR
  - Karliss 9y ago
    Unless process is temporarily stopped by OS which has saved all registers in RAM so that process can be continued afterwards.
  - chaboud 9y ago
    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.
    - physguy1123 9y ago
      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.
      - kindfellow92 9y ago
        Yeah on context switch the SSE registers are stored in memory, so this doesn’t help for security.
        physguy1123 9y ago
        That's why I said it's tricky to deal with interrupts, but possible if the effort is worth it to the use case. One could run the code in a kernel module which masked interrupts or use restartable sequences and cleared sse in the kernel when in certain code sections.
emily-c 9y ago
I think it's useful in that it gives you a weird trick to think about :)
- Dylan16807 9y ago
  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/ 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. (I don't know if that technique is still used)
  - kindfellow92 9y ago
    This trick doesn’t avoid the storage of this data into RAM. A single context switch is enough.
    - Dylan16807 9y ago
      Context switches put it into kernel memory, not process memory. That's safe.
- ianhowson 9y ago
  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.

lgas 9y ago

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?

kindfellow92 9y ago
In the style of this article, Most probably not.
pdkl95 9y ago
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. https://en.wikipedia.org/wiki/TRESOR https://en.wikipedia.org/wiki/TRESOR
- Karliss 9y ago
  Unless process is temporarily stopped by OS which has saved all registers in RAM so that process can be continued afterwards.
- chaboud 9y ago
  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.
  - physguy1123 9y ago
    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.
    - kindfellow92 9y ago
      Yeah on context switch the SSE registers are stored in memory, so this doesn’t help for security.
      - physguy1123 9y ago
        That's why I said it's tricky to deal with interrupts, but possible if the effort is worth it to the use case. One could run the code in a kernel module which masked interrupts or use restartable sequences and cleared sse in the kernel when in certain code sections.

emily-c 9y ago

I think it's useful in that it gives you a weird trick to think about :)

Dylan16807 9y ago
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/ 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. (I don't know if that technique is still used)
- kindfellow92 9y ago
  This trick doesn’t avoid the storage of this data into RAM. A single context switch is enough.
  - Dylan16807 9y ago
    Context switches put it into kernel memory, not process memory. That's safe.
ianhowson 9y ago
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.