WebAssembly lets applications write/read to NULL. Even if, by design, WASM prevents whole classes of vulnerabilities, that sounds like a regression over what all modern operating systems do, which has proven to prevent many bugs and exploitable vulnerabilities.
-
-
-
Replying to @emilbayes
Yes. Sure, the C standard allows (void*)0 to represent a different address, but in practice no compiler ever did that, and that would break quite a lot of code.
1 reply 0 retweets 0 likes -
Replying to @jedisct1
What kind of vulnerabilities would it lead to, it data was read or written to address 0? A NULL check seems to compile to a check on the const 0 with Emscripten for example
1 reply 0 retweets 0 likes -
-
-
Replying to @emilbayes
Crashes on NULL pointers deref are extremely useful, even in high-level languages such as Go. Now, these become silent, with unpredictable side effects.
1 reply 0 retweets 0 likes -
Replying to @jedisct1
So if NULL was (i32.const -1) in WASM, that would cause and out of bounds trap. Wouldn't that yield the same behaviour?
2 replies 0 retweets 0 likes -
Replying to @emilbayes
It would probably restore that behavior. But now, (uintptr_t)0 != (void *) 0. You can’t initialize a pointers array with calloc() or memset(0) any more. This is going to break things.
1 reply 0 retweets 0 likes -
Replying to @jedisct1
But isn't this exploiting the knowledge that NULL is 0? :) I know what you're saying is that this is knowledge that people exploit in practise even though they shouldn't
1 reply 0 retweets 0 likes
Yes. Quickly initializing arrays of things that include pointers using memset(0) or calloc() is a very common practice.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.