Creating a reference with `std::mem::zeroed` generates a SIGILL

[koute]

This program:

fn main() {
    let value: &u8 = unsafe { ::std::mem::zeroed() };
}

when compiled with opt-level higher than zero generates a SIGILL. Switching to std::mem::uninitialized works around the issue.

I've been bitten by this in generic code where I have a field with ManuallyDrop<T> (basically I use it as an Option with manually managed null state).

This is possibly related to #52875

Affected versions:
rustc 1.29.0-nightly (874dec2 2018-07-21)
rustc 1.29.0-nightly (54628c8 2018-07-30)
rustc 1.27.2 (58cc626 2018-07-18)

Not affected versions:
rustc 1.26.0 (a775680 2018-05-07)

This doesn't look architecture specific as x86_64-unknown-linux-gnu, mips64-unknown-linux-gnuabi64 and armv7-unknown-linux-musleabihf are all affected.

[ishitatsuyuki]

As soon as you instantiate a type (including references) with a stale value it will immediately cause UB. This is not really actionable (mem::uninitialized itself is not very sound, there are proposals to use unions instead).

[Mark-Simulacrum]

Yes, this code is UB - references must be non-null.

I can see how things like mem::uninitialized and mem::zeroed should generally be discouraged in application code, but I find it surprising that a language marketed toward kernel writers is making it increasingly difficult to operate directly on memory. This caused a widely used library of mine to stop working, and I'm having trouble thinking of a fix that doesn't require a major rewrite that breaks backwards compatibility. Isn't the whole point of unsafe to isolate undefined behavior when it can't be reasonably avoided?

[Mark-Simulacrum]

You can use *const T or *mut T instead to operate on memory directly; if you've left a value zeroed or unintialized it wouldn't be safe to permit access to it: the raw pointer types do that, whereas the reference 'type' (&) does not.

If you want to, you can also wrap them in a struct to provide safe access, perhaps panicking if the value hasn't yet been initialized.

If you have suggestions as to how to improve ergonomics or clarity here (docs or through language changes) we'd be happy to hear them.

What about when working with C function pointers? I expected these to behave more like raw pointers, but it's causing this same SIGILL. Example:

let x: unsafe extern "C" fn () = mem::zeroed();

[Mark-Simulacrum]

You should be using Option<...> around the function pointer, and initializing it to None (equivalent to mem::zeroed, I believe, but safer).

The nomicon notes:

The most common type that takes advantage of the nullable pointer optimization is Option<T>, where None corresponds to null. So Option<extern "C" fn(c_int) -> c_int> is a correct way to represent a nullable function pointer using the C ABI (corresponding to the C type int (*)(int)).

At the time that I wrote the x11-dl crate, it didn't seem reasonable to expect users to check if a function pointer is None every time they use one when the crate ensures that they're all non-null (or Some(_)) before making them available. I was using mem::zeroed and a loop to initialize very large structs full of function pointers as an optimization that improved build times, execution times, and code size, and prevented a stack overflow from occurring on some systems. It would be reasonable if this SIGILL had existed from the start, but it's a breaking change that's very difficult to work around.

[koute]

One extra thing which I'd like to emphasize here is that this is an incredibly silly footgun when dealing with generic code. Yes, accessing something that is mem::zeroed or mem::uninitialized should definitely trigger undefined behavior (I don't think anyone is disputing that) and should not be done, however merely creating such a value without doing anything with it should not give the compiler a blanket permission to maliciously turn my program into a single ud2 instruction.

In fact, if the official stance is that initializing T& using mem::uninitialized() is undefined behavior (Based on what @ishitatsuyuki said it might...?) then this (written in safe Rust) program should trigger undefined behavior:

use std::collections::HashMap;

fn main() {
    let mut map: HashMap< (), &u32 > = HashMap::new();
    map.insert( (), &123 );
    for (_, v) in map.drain() {
        println!( "{}", v );
    }
}

Here's how the Drain iterator is defined:

impl<'a, K, V> Iterator for Drain<'a, K, V> {
    // ...
    #[inline]
    fn next(&mut self) -> Option<(SafeHash, K, V)> {
        self.iter.next().map(|raw| {
            unsafe {
                self.table.as_mut().size -= 1;
                let (k, v) = ptr::read(raw.pair());
                (SafeHash { hash: ptr::replace(&mut *raw.hash(), EMPTY_BUCKET) }, k, v)
            }
        })
    }
    // ...
}

And here's ptr::read:

#[inline]
#[stable(feature = "rust1", since = "1.0.0")]
pub unsafe fn read<T>(src: *const T) -> T {
    let mut tmp: T = mem::uninitialized();
    copy_nonoverlapping(src, &mut tmp, 1);
    tmp
}

So what's effectively doing is this:

let (k, v): ((), &'static u32) = mem::uninitialized();

In general my assumptions were always:

1. As long as the value (any value) is never accessed having it initialized using mem::uninitialized is safe.
2. The mem::zeroed is exactly the same as mem::uninitialized, except the underlying memory is zeroed.

The docs for mem::uninitialized currently do sound like it's fine to use mem::uninitialized as long as the value isn't accessed in any way.

The docs for mem::zeroed are more spartan; they do however suggest a similarity to mem::uninitialized. If there are cases where mem::uninitialized doesn't trigger UB and mem::zeroed does then I think that definitely should be documented!

[Mark-Simulacrum]

I'll reopen this and cc people who are working on uninitalized/zeroed.

cc @RalfJung @rust-lang/wg-unsafe-code-guidelines

[sfackler]

uninitialized is very different from zeroed in this context. A null reference is explicitly a value that doesn't exist, and creating one is undefined behavior.

@sfackler Uninitialized memory is also assumed to be a value that doesn't exist, and both are equally undefined behavior. If anything, zeroed memory is more likely to trigger a SIGSEGV or equivalent on most platforms, which is far better than with uninitialized memory, where this is only the best case scenario.

More importantly, as @koute mentioned, this zeroed memory is not at any point being accessed in these use cases. It's being overwritten before any use, which should pretty much eliminate any undefined behavior. Regardless, there would be no point in providing mem::uninitialized or mem::zeroed or unsafe at all if such code is forbidden.

Why not just rewrite these functions to

unsafe fn uninitialized<T> () -> T {
    panic!("this used to be allowed but isn't anymore because ???")
}

unsafe fn zeroed<T> () -> T {
    panic!("this used to be allowed but isn't anymore because ???")
}

[sfackler]

Uninitialized memory is also assumed to be a value that doesn't exist, and both are equally undefined behavior.

No, that is not correct. Uninitialized memory exists all over the place! The memory returned by malloc is uninitialized. Uninitialized memory has an undefined value.

Regardless, there would be no point in providing mem::uninitialized or mem::zeroed or unsafe at all if such code is forbidden.

All such code is not forbidden.