> Are sensitive values set to zero after being used? In Rust this may be done using the Drop trait rather than explicitly.
A zeroing Drop is theater unless the sensitive data is Pinned too. Rust likes to copy things around.
A zeroing Drop is theater unless the sensitive data is Pinned too. Rust likes to copy things around.
Optimizers consider code that zeroes a dying object to be dead code. (This is also a problem in C++ destructors.) It can be arbitrarily difficult to keep such code from being elided in various passes. Even inline asm instructions can be removed by a peephole pass.
Then, the CPU might decide not to flush all those zeroes from its writeback cache until some random time later when it needs that bit of cache for something else.
This is all wonderful for performance, usually, but it means you it takes a lot of dog-work to disable it.
If you have not verified that memory actually has zeroes in it, as seen by another core or DMA engine, it doesn't.
OpenBSD provides
void explicit_bzero(void *s, size_t n);
But it still has limitations due to lack of compiler support. I think the problem can only be solved at the compiler/OS level.
> The explicit_bzero() function addresses a problem that security-conscious applications may run into when using bzero(): if the compiler can deduce that the location to zeroed will never again be touched by a correct program, then it may remove the bzero() call altogether. This is a problem if the intent of the bzero() call was to erase sensitive data (e.g., passwords) to prevent the possibility that the data was leaked by an incorrect or compromised program. Calls to explicit_bzero() are never optimized away by the compiler.
> The explicit_bzero() function does not solve all problems associated with erasing sensitive data:
> 1. The explicit_bzero() function does not guarantee that sensitive data is completely erased from memory. (The same is true of bzero().) For example, there may be copies of the sensitive data in a register and in "scratch" stack areas. The explicit_bzero() function is not aware of these copies, and can't erase them.
> 2. In some circumstances, explicit_bzero() can decrease security. If the compiler determined that the variable containing the sensitive data could be optimized to be stored in a register (because it is small enough to fit in a register, and no operation other than the explicit_bzero() call would need to take the address of the variable), then the explicit_bzero() call will force the data to be copied from the register to a location in RAM that is then immediately erased (while the copy in the register remains unaffected). The problem here is that data in RAM is more likely to be exposed by a bug than data in a register, and thus the explicit_bzero() call creates a brief time window where the sensitive data is more vulnerable than it would otherwise have been if no attempt had been made to erase the data.
There's the problem. That is a lot of levels. There is support at certain levels; nowadays you can force writebacks from certain cache lines, and OSes let you keep pages from being swapped. The problem is that it needs coordinated support at all levels, but there is no money behind it, unlike features that may improve performance, and hardly anybody knows there is even a problem.
Spectre and Meltdown have raised awareness of security threats in infrastructure, but are so big they also absorb all the budget for it, and will continue indefinitely.
I've once read something about Remote Direct Memory Access, it allows one to completely bypass the kernel, CPU, cache, and stream data directly to the network adapter of another computer - you break a lot of essential abstractions of modern computer system, meanwhile still be able to provide a consistent and usable infrastructure.
Its security equivalent (something allows low-level control of the protected data) is unlikely to happen, except for DRM, I guess.
"Transactional Memory" seems to have flopped for lock-free synchronization, but it is a nice way to keep writes from ever going out to RAM or beyond. It reserves a bit of cache for temporary storage, and automatically wipes it if anything happens, like an interrupt -- even on a guest OS.
That is better than zeroing, and the toolchain won't fight you. But it might not be available everywhere you want it. Also, it wasn't designed for crypto, so there are probably vulnerabilities to the host OS.
Everything around security is hard. It gets easier if you don't care whether it really is secure, which is common.
Of course not, but for efficiency you might have an [u8;32][0] instead and that will get memcpy'd when it's moved around.
[0] 32 bytes on the stack isn't much, a single Vec or String is 24
> Since Rust itself has no notion of immovable types, and will consider moves to always be safe, this trait cannot prevent types from moving by itself.
From the documentation on std::pin:
> In order to prevent objects from moving, they must be pinned by wrapping a pointer to the data in the Pin type. A pointer wrapped in a Pin is otherwise equivalent to its normal version, e.g. Pin<Box<T>> and Box<T> work the same way except that the first is pinning the value of T in place.
> First of all, these are pointer types because pinned data mustn't be passed around by value (that would change its location in memory). …
Looking at Pin itself, it appears that it works by only implementing DerefMut if its target is Unpin, thus preventing you from mutating (and therefore swapping/replacing) the data unless the data supports Unpin. But beyond that, it also only implements Deref and DerefMut if its wrapped type itself implements Deref/DerefMut, which means using Pin around a non-pointer basically prevents you from accessing the wrapped data.
Afaict, Rust memcopys moved objects if they're larger than some size when passed as function arguments. Also take into account implicit copies such as those left laying around when a vector outgrows it's heap segment.
Crypto Implementation Is Hard. Especially when you need it to be secret. It is lots easier if you don't care.
In other words, why is a zeroing Drop of a type more secure if it uses Pin too?
[0] though I guess the compiler might be smart enough to implicitly pass big-enough values by pointer instead