Stable counterpart for `core::intrinsics::volatile_set_memory`

[autumnontape]

A volatile memset function would be useful for efficiently zeroing sensitive data before dropping it so it's less likely to be exposed by bugs like Heartbleed. It's already possible to explicitly zero bytes in Rust by using core::ptr::write_volatile in a loop, but because the writes are volatile, the compiler is forced to emit them exactly as written (one byte at a time in simple implementations) rather than using an optimized memset routine.

[RalfJung]

but because the writes are volatile, the compiler is forced to emit them exactly as written (one byte at a time in simple implementations) rather than using an optimized memset routine.

That is exactly what volatile is for, though... wanting volatile and wanting optimizations is somewhat of a contradiction.

In UCG discussions around volatile (rust-lang/unsafe-code-guidelines#33, rust-lang/unsafe-code-guidelines#152) the general consensus was that the language itself should only offer volatile operations that cannot be teared -- currently you can do write_volatile with a type way too big to be written in a single instruction, which runs counter the goal of volatile, which is to exactly control how these memory accesses happen.

If we also offer "volatile accesses that are allowed to tear", then this is basically a whole new class of memory accesses, with guarantees and use-cases rather distinct from regular volatile accesses. Currently, it is all mixed up though.

[autumnontape]

volatile_set_memory currently lowers to a memset call, similar to functions like explicit_bzero that exist in C for this purpose. I would be in favor of naming the function something other than "volatile" and perhaps leaving open the possibility for it to do things other than write to exactly one span of memory, e.g. to overwrite registers instead of forcing data that would otherwise be kept in registers to be written to memory.

[elichai]

FYI if the size is preknown you can do something like this:

pub unsafe fn volatile_set_memory(slice: &mut [u8; 32], n: u8) {
    let ptr = slice as *mut [u8; 32];
    ptr.write_volatile([n; 32]);
}

Trying to do this generically over T with [u8; size_of::<T>()] is currently blocked on #68436
but you can still do it non generically:

struct PrivateKey([u8; 32]);
impl PrivateKey {
    pub unsafe fn volatile_zero(&mut self) {
        let ptr = self as *mut Self as *mut [u8; size_of::<PrivateKey>()];
        ptr.write_volatile([0u8; size_of::<PrivateKey>()]);
    }
}

[blckngm]

Now that inline assembly is in stable, it can used to preventing “memset” from being optimized out, right?

pub fn zeroize(x: &mut [u8]) {
    x.fill(0);
    unsafe {
        core::arch::asm!(
            "/* {ptr} */",
            ptr = in(reg) x.as_ptr(),
            options(nostack, readonly, preserves_flags),
        );
    }
}

This wastes a register, but generates optimal code for the “memset”, especially when inlined and the size of the buffer is known and a multiple of e.g. xmm register size.

cc RustCrypto/utils#743