Cannot use 0 as an address in wasm in with opt-level >= 1 #57897

surma · 2019-01-25T15:28:25Z

I want to use Rust to work on the raw chunk of memory that WebAssembly creates for me. Consider the following rust code:

#![no_std]
#![no_main]

use core::panic::PanicInfo;
use core::slice::from_raw_parts_mut;

#[no_mangle]
fn test() {
  let in_b: &mut [u32];

  unsafe {
    in_b = from_raw_parts_mut::<u32>(0 as *mut u32, 3);
  }

  in_b[0] = 123;
}


#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
  loop {}
}

Compile with

rustc --target=wasm32-unknown-unknown -o rust.wasm rotate.rs

And load with this HTML file:

<!DOCTYPE html>
<script>
  async function init() {
    const { instance } = await WebAssembly.instantiate(
      await fetch("/rust.wasm").then(r => r.arrayBuffer())
    );
    instance.exports.test();
    console.log(new Uint32Array(instance.exports.memory.buffer, 0).slice(0, 3));
  }
  init();
</script>

This will work fine (i.e. no errors).

If you add -C opt-level=1 (or 2 or 3) to the rustc invocation, the wasm module will fail with unreachable.

If you change the rust code as following

-    in_b = from_raw_parts_mut::<u32>(0 as *mut u32, 3);
+    in_b = from_raw_parts_mut::<u32>(4 as *mut u32, 3);

the code will work again.

I think if I can use 0 as an address in a debug build I should also be able to do it in release mode 😄

cc @ashleygwilliams

The text was updated successfully, but these errors were encountered:

nagisa · 2019-01-25T17:56:09Z

Oh my, 0 pointer not being a null strikes!

Centril · 2019-01-25T18:08:24Z

from_raw_parts_mut explicitly states that the data pointer (you've passed ptr::null_mut() to it) must not be null. Therefore the behavior of your program above is undefined.

surma · 2019-01-25T23:55:58Z

Ha, I really should read the documentation when using unsafe stuff. Thanks for pointing that out.

It’s completely fair to not allow address 0, but can we then make sure that the program will panic in debug mode? Having it coincidentally do the right in debug while it crashes when doing a release build is very unfortunate.

Centril · 2019-01-26T00:06:27Z

@surma hmm... the function has debug_assert!(data as usize % mem::align_of::<T>() == 0, ...);; ~~maybe it didn't panic due to the #[panic_handler]?~~ -- ah no; that's because std's debug_assert doesn't show up in your code; only when building std itself... iirc.

surma · 2019-01-26T03:25:44Z

Even if it was, it would only be checking for alignment, not for a non-zero value, wouldn’t it?

Centril · 2019-01-26T03:31:56Z

@surma yeah my bad; we should perhaps add debug_assert!(data != ptr::null_mut(), ..); -- make a PR for that and see what folks think?

hanna-kruppe · 2019-01-26T11:29:26Z

The pre-built binaries distributed through rustup are built without debug assertions, so neither the existing alignment check nor a new (debug-assertion-only) null check would actually reach most users.

surma · 2019-01-26T14:13:17Z

neither the existing alignment check nor a new (debug-assertion-only) null check would actually reach most users.

So what changes would need to be made to make this program crash in debug mode, and not only in release mode?

nagisa · 2019-01-26T14:44:21Z

Invocation of undefined behaviour yields undefined results, so we cannot and will not guarantee crash, crash-free or matching behaviour at any of the optimisation levels.

I’m sympathetic to the observation that 0 is an absolutely valid pointer in WASM and perhaps std::mem::nullptr should be something else, however this is and will increasingly be extremely difficult to change. I believe, doing so would involve making changes to the whole WASM ecosystem (including runtimes, C code, etc.)

I do not see how this issue is actionable in any way as is.

surma · 2019-01-26T15:04:28Z

I am not expecting 0 to work as an address just for WebAssembly. That is a massive change and not reasonable or proportional. Agreed.

I do feel like it would be reasonable to add some debug-only code that guarantees a crash in debug mode, but that code would get stripped in release mode. Or is that not possible?

In release mode I am of course 100% okay with undefined behavior being exactly that, undefined.

Centril · 2019-01-26T15:40:13Z

@surma Another option is to try out the cargo miri tool and see if that catches any UB (also available on playground).

nikomatsakis · 2019-01-28T20:47:53Z

@surma

I do feel like it would be reasonable to add some debug-only code that guarantees a crash in debug mode, but that code would get stripped in release mode. Or is that not possible?

It's not impossible, but it is pretty hard. The problem is that the stdlib -- at present -- is always optimized. We've talked for a long time about having the ability to rebuild the stdlib with different options, or at least shipping a "debug version", in part so that we can add assertions like this, but it's not something we have the capacity to do right now. So, that would imply that we'd have to add the assertion also in optimized mode, which we don't really want to do.

surma · 2019-01-28T23:18:49Z

Ah understood. Fair enough. Thanks for clarifying.

RalfJung · 2019-01-29T16:14:24Z

Also see #53871

alexcrichton · 2019-12-16T22:27:53Z

I'm going to close this because this is something we're pretty unlikely to ever support in wasm.

Centril added the O-wasm Target: WASM (WebAssembly), http://webassembly.org/ label Jan 25, 2019

Centril changed the title ~~Canntot use 0 as an address in wasm in with opt-level >= 1~~ Cannot use 0 as an address in wasm in with opt-level >= 1 Jan 25, 2019

oli-obk mentioned this issue Jan 29, 2019

Cannot run even basic Tokio programs rust-lang/miri#602

Open

alexcrichton closed this as completed Dec 16, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cannot use 0 as an address in wasm in with opt-level >= 1 #57897

Cannot use 0 as an address in wasm in with opt-level >= 1 #57897

surma commented Jan 25, 2019 •

edited

Loading

nagisa commented Jan 25, 2019

Centril commented Jan 25, 2019

surma commented Jan 25, 2019

Centril commented Jan 26, 2019 •

edited

Loading

surma commented Jan 26, 2019

Centril commented Jan 26, 2019

hanna-kruppe commented Jan 26, 2019 •

edited

Loading

surma commented Jan 26, 2019

nagisa commented Jan 26, 2019

surma commented Jan 26, 2019

Centril commented Jan 26, 2019

nikomatsakis commented Jan 28, 2019

surma commented Jan 28, 2019

RalfJung commented Jan 29, 2019

alexcrichton commented Dec 16, 2019

Cannot use 0 as an address in wasm in with opt-level >= 1 #57897

Cannot use 0 as an address in wasm in with opt-level >= 1 #57897

Comments

surma commented Jan 25, 2019 • edited Loading

nagisa commented Jan 25, 2019

Centril commented Jan 25, 2019

surma commented Jan 25, 2019

Centril commented Jan 26, 2019 • edited Loading

surma commented Jan 26, 2019

Centril commented Jan 26, 2019

hanna-kruppe commented Jan 26, 2019 • edited Loading

surma commented Jan 26, 2019

nagisa commented Jan 26, 2019

surma commented Jan 26, 2019

Centril commented Jan 26, 2019

nikomatsakis commented Jan 28, 2019

surma commented Jan 28, 2019

RalfJung commented Jan 29, 2019

alexcrichton commented Dec 16, 2019

surma commented Jan 25, 2019 •

edited

Loading

Centril commented Jan 26, 2019 •

edited

Loading

hanna-kruppe commented Jan 26, 2019 •

edited

Loading