Safety of storing custom data in MaybeUninit

code review
1

Basically, my question is: is secretmangle/src/arbitrary.rs at master · ProgramCrafter/secretmangle · GitHub sound with the current Rust rules?

This module does not do much from Rust perspective, since it is intended to mangle stored values so that they are not easily seen in debugger, memory dump (such as swap file) or leak. However, it intends to work on any type which is provided to it.

The key design principles:

  1. The T value is stored in a separate allocation, using a data: Box<MaybeUninit<T>>.
  2. The XOR key is stored in the struct itself, and is a sequence of random bits. As I only care that it is sized the same as T - it even is permitted to have padding at the same place as T - the ideal buffer seems to be key: MaybeUninit<T> as well.
  3. Accesses are done using a closure. Between any two accesses an even number of XORs had been performed on the memory, so the exact value of every non-padding bit is preserved (and, from concrete machine perspective, every single bit is same).
2

Did you run your tests under Miri yet? If not, that's always a good first step.

3

Unfortunately Miri cannot validate inline assembly used to XOR the memory while preserving initialization status (init -> init, uninit padding -> uninit padding); the tests on bytemuck::NoUninit version pass though.

1 Like
4

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.