7 ms·

> 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

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

eridius 8y ago
I'm not particularly familiar with Pinned but the documentation on std::pin suggests it prevents moving data, not copying data (and is primarily designed around enabling self-referential structs).
- legulere 8y ago
  Moves are exactly the problem, as the data is just copied, without drop running on the source, and they happen implicitly.
  - eridius 8y ago
    Rust isn't going to just silently move the pointed-to data in something like Box<[u8; 32]>. It looks like the point of Pinned is to protect against operations like swap() that would move the pointed-to data, but the point here is to maintain the data's invariants (e.g. a self-referential struct cannot be moved or its self-references would be invalid) rather than to protect against silent moves (a call to swap() is definitely not silent).
    - masklinn 8y ago
      > Rust isn't going to just silently move the pointed-to data in something like Box<[u8; 32]>. 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
      - eridius 8y ago
        A [u8;32] doesn't work with Pin. Pin only works when you wrap it around a pointer type. From the documentation on Unpin: > 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.
- deleted 8y ago
  [deleted]
- kibwen 8y ago
  AFAIK the purpose of pinning is to statically ensure that the pinned data remains at the current address in memory, for the purpose of handing out references to the data that remain valid even if the precise lifetime of those references isn't statically known (the soundness and safety of Rust's async story relies on this property holding, so the devs are incentivized to uphold it). I won't claim to be able prove that it's impossible for a too-smart compiler to still somehow manage to have pinned data lingering somewhere else in memory, but it should be a good start.
tomjakubowski 8y ago
It's not good enough to make the type non-Clone (and therefore, non-Copy)?
- ncmncm 8y ago
  Very, very far from good enough. I.e., the first step down a long and lonely road. Crypto Implementation Is Hard. Especially when you need it to be secret. It is lots easier if you don't care.
  - tomjakubowski 8y ago
    Yeah. I guess that I just don't see what Pin provides that non-Copy/Clone does, when it comes to preventing the zeroed data from leaking elsewhere. In other words, why is a zeroing Drop of a type more secure if it uses Pin too?
    - ncmncm 8y ago
      The unpleasant answer is that both might do no good at all, by themselves.
    - firethief 8y ago
      Copy/Clone/move is a typesystem distinction. At codegen time, they all can mean "memcpy this byte range". E.g. how else to return a struct by value?
- jake_the_third 8y ago
  Nope. Not at all. 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.
- masklinn 8y ago
  No. Both copies and moves are simple memcpy at the machine-level[0], the only difference is whether the compiler will let you keep using the source afterwards. [0] though I guess the compiler might be smart enough to implicitly pass big-enough values by pointer instead
ncmncm 8y ago
This isn't the half of it! 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.
- ncmncm 8y ago
  It's not all bad news. "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.
  - monocasa 8y ago
    Transactional memory doesn't help you here. Everything will be cleared, including whatever you were trying to do with the secret.
    - ncmncm 8y ago
      It means you have to start over if it gets cleared. That adds latency spikes to processes that use it, which have to be planned for. Everything around security is hard. It gets easier if you don't care whether it really is secure, which is common.
- segfaultbuserr 8y ago
  Special primitives in programming languages should be provided to solve this problem, just like how Linux kernel uses a "barrier()" macro to mark non-reorderable code, and "wmb()" and "rmb()" to mark non-reorderable I/O. OpenBSD provides void explicit_bzero(void *s, size_t n); In libc, which is used for this purpose. Recently, glibc added function, presumably because it's a good idea. 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.

eridius 8y ago

I'm not particularly familiar with Pinned but the documentation on std::pin suggests it prevents moving data, not copying data (and is primarily designed around enabling self-referential structs).

legulere 8y ago
Moves are exactly the problem, as the data is just copied, without drop running on the source, and they happen implicitly.
- eridius 8y ago
  Rust isn't going to just silently move the pointed-to data in something like Box<[u8; 32]>. It looks like the point of Pinned is to protect against operations like swap() that would move the pointed-to data, but the point here is to maintain the data's invariants (e.g. a self-referential struct cannot be moved or its self-references would be invalid) rather than to protect against silent moves (a call to swap() is definitely not silent).
  - masklinn 8y ago
    > Rust isn't going to just silently move the pointed-to data in something like Box<[u8; 32]>. 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
    - eridius 8y ago
      A [u8;32] doesn't work with Pin. Pin only works when you wrap it around a pointer type. From the documentation on Unpin: > 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.
deleted 8y ago
[deleted]
kibwen 8y ago
AFAIK the purpose of pinning is to statically ensure that the pinned data remains at the current address in memory, for the purpose of handing out references to the data that remain valid even if the precise lifetime of those references isn't statically known (the soundness and safety of Rust's async story relies on this property holding, so the devs are incentivized to uphold it). I won't claim to be able prove that it's impossible for a too-smart compiler to still somehow manage to have pinned data lingering somewhere else in memory, but it should be a good start.

tomjakubowski 8y ago

It's not good enough to make the type non-Clone (and therefore, non-Copy)?

ncmncm 8y ago
Very, very far from good enough. I.e., the first step down a long and lonely road. Crypto Implementation Is Hard. Especially when you need it to be secret. It is lots easier if you don't care.
- tomjakubowski 8y ago
  Yeah. I guess that I just don't see what Pin provides that non-Copy/Clone does, when it comes to preventing the zeroed data from leaking elsewhere. In other words, why is a zeroing Drop of a type more secure if it uses Pin too?
  - ncmncm 8y ago
    The unpleasant answer is that both might do no good at all, by themselves.
  - firethief 8y ago
    Copy/Clone/move is a typesystem distinction. At codegen time, they all can mean "memcpy this byte range". E.g. how else to return a struct by value?
jake_the_third 8y ago
Nope. Not at all. 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.
masklinn 8y ago
No. Both copies and moves are simple memcpy at the machine-level[0], the only difference is whether the compiler will let you keep using the source afterwards. [0] though I guess the compiler might be smart enough to implicitly pass big-enough values by pointer instead

ncmncm 8y ago

This isn't the half of it! 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.

ncmncm 8y ago
It's not all bad news. "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.
- monocasa 8y ago
  Transactional memory doesn't help you here. Everything will be cleared, including whatever you were trying to do with the secret.
  - ncmncm 8y ago
    It means you have to start over if it gets cleared. That adds latency spikes to processes that use it, which have to be planned for. Everything around security is hard. It gets easier if you don't care whether it really is secure, which is common.
segfaultbuserr 8y ago
Special primitives in programming languages should be provided to solve this problem, just like how Linux kernel uses a "barrier()" macro to mark non-reorderable code, and "wmb()" and "rmb()" to mark non-reorderable I/O. OpenBSD provides void explicit_bzero(void *s, size_t n); In libc, which is used for this purpose. Recently, glibc added function, presumably because it's a good idea. 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.