zeroize: possible UB in Zeroize implementation for Option<T> #653

Activity

1. mkj commented on Dec 2, 2022

   

   mkj

   on Dec 2, 2022

   Last edited by mkj

   More actions

   The write_bytes docs seem fairly clear that writing invalid bit-patterns without reading should not be UB? (added from rust-lang/unsafe-code-guidelines#330 (comment)).

   Interestingly that miri playground example now works - I bisected it to nightly-2021-09-15, but can't see what changed then. It might be OK for other reasons though.

   As an aside, I wonder if the Z: Zeroize bound could be removed from Option, allowing Option<Z> to zeroize any uncooperative types...? (no, that won't work for types with heap allocations)
2. tarcieri commented on Dec 8, 2022

   

   tarcieri

   on Dec 8, 2022

   MemberAuthor

   More actions

   Reads are still possible after Zeroize::zeroize since the API doesn't require dropping the value, although the question is whether we need to worry about reads after None has been written to the value
3. Kixunil commented on Jul 24, 2024

   

   Kixunil

   on Jul 24, 2024

   More actions

   Found this exact same thing. I believe just holding onto the pointer should help since Rust makes no assumptions about memory behind pointers and the previous reference is inactive according to the stacked borrows when the pointer is used:

           let this = self as *mut Self;
           unsafe {
               volatile_set(this.cast::<u8>(), 0, mem::size_of::<Self>());
           }
   
           unsafe { ptr::write_volatile(this, None) }

   Also to put it differently, if this were UB then memcpy would be also UB because it may briefly break invariants during copying.

   Alternatively and perhaps more efficiently you could construct the value to overwrite first and then do the overwriting, assuming Rust won't try to optimize to not copy the padding. But perhaps you can somehow avoid it by making the type opaque.