Alternatives to volatile_set_memory

bascule · 2015-03-26T03:48:15.634Z

As I understand it std::intrinsics::volatile_set_memory is going away.

There’s a very specific use case I want it for: zeroing drop for cryptographic buffers.

Instead of trying to stabilize the idea of “volatile_set_memory”, I think what I’d actually like, at least for crypto purposes, is something like Zeroing<T> that ensures a volatile zero on drop.

huon · 2015-03-26T11:46:03.343Z

To be clear, it isn’t going away, just becoming inaccessible from the 1.0 stable compiler; it will still be accessible via the nightly compilers. We are expecting non-trivial number of users to have to wait until 1.1, 1.2, …, 1.x to be able to have their complete application running with the stable branch, but the 6 week release cycles means the new features will come quickly (and the nightlies will continue to work in the meantime).

I’m not commenting about the particular specifics here, merely ensuring everyone’s on the same page: functionality unstable at 1.0 is not dead-in-the-water once that release is cut.

(Of course, we’d definitely like to keep small the number of people who are forced to use the nightly by unstable features, so it would be interesting if something like this could land… but there isn’t much time until the beta.)

cmr · 2015-03-27T00:37:23.654Z

I’m not sure it’s possible to implement Zeroing<T> except as a marker trait in the compiler. Consider:

struct Zeroing<T> { data: T }
impl<T> Deref for Zeroing<T> { ... }
// etc
impl<T> Drop for Zeroing<T> {
     fn drop(&mut self) {
          // need to drop the value...
         let x: T = unsafe { ptr::read(&self.data) };
         drop(x);
         // now we need to zero: self.data, x, AND wherever x was put when passed to drop.
     }
 }

It might be possible with negative bounds, implementing for T: !Drop, but I’m not sure. It’d be much easier as a special struct Zeroing<T: Copy> { data: Vec<T> } or Box<T> where T: Copy + ?Sized (as an owned buffer that will be zeroed and never copied).

If we were going to ship something for 1.0, it either needs to be ZeroingBuf { data: Vec<u8> } or a magical lang item.

EDIT: And, a more comprehensive design would have a ZeroSelf trait, so containers like Vec would know how to zero their contents. I think ZeroingBuf is probably a better idea… EDIT2: To clarify, I think we should totally implement ZeroingBuf for 1.0.

huon · 2015-03-27T12:04:48.563Z

cmr:

It might be possible with negative bounds, implementing for T: !Drop, but I’m not sure. It’d be much easier as a special struct Zeroing<T: Copy> { data: Vec<T> } or Box<T> where T: Copy + ?Sized (as an owned buffer that will be zeroed and never copied).

If we’re talking hypothetical features, providing a function to run the destructor without having to copy on to the stack seems nicer than negative bounds or a limited ZeroingBuf: https://github.com/rust-lang/rfcs/issues/753

cmr · 2015-03-28T21:09:28.163Z

You’re right. That facility would be very nice.

bascule · 2015-03-28T23:33:47.428Z

ZeroingBuf { data: Vec<u8> } solves the general problem I have: expressing the desire to zero using the type system rather than adding an explicit destructor to each type we want to contain a buffer that gets zeroed on drop. Unsigned byte vectors are pretty much all I care about… I don’t actually need to do this generically.

As an anecdotal data point, sodiumoxide presently handles this with macros and I think it’s kind of ugly:

github.com

dnaq/sodiumoxide/blob/master/src/utils.rs#L31


pub fn memcmp(x: &[u8], y: &[u8]) -> bool {
if x.len() != y.len() {
    return false
}
unsafe {
    ffi::sodium_memcmp(x.as_ptr(), y.as_ptr(), x.len()) == 0
}
}


/// `increment_le()` treats `x` as an unsigned little-endian number and increments it.
///
/// WARNING: this method does not check for arithmetic overflow. When used for incrementing
/// nonces it is the callers responsibility to ensure that any given nonce value
/// is only used once.
/// If the caller does not do that the cryptographic primitives in sodiumoxide
/// will not uphold any security guarantees (i.e. they will break)
pub fn increment_le(x: &mut [u8]) {
unsafe {
    ffi::sodium_increment(x.as_mut_ptr(), x.len());
}
}

grayfox · 2015-10-07T11:19:49.540Z

I’m sorry to answer to this old question. However I’m wondering why you can’t use std::ptr::write_bytes, which is stablelized. Is it not secure for cryptographic applications because the implementation has not the volatile-flag?

Moreover the documentation state that intrinsics will probably never get stable status but is there an stablelized interface for volatile_set_memory?

Disclaimer: This post is related to my question in the users forum: https://users.rust-lang.org/t/optimization-by-the-compiler-of-non-volatile-and-volatile-io-operations/3181/1

eddyb · 2015-11-09T18:09:23.468Z

It’s not volatile, which means it will likely get eliminated by LLVM optimization (and IME, it does disappear in simple cases).

system · 2019-03-25T08:24:07.256Z

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.