Re:WebAssembly doesn’t make unsafe languages safe
by monocasa on Monday November 26, 2018 @01:38PM
(#18535694)
I figured kllrnohj was referencing the fact that OpenBSD clears data when it's allocated. That you can do from WASM pretty easily.
Additionally WASM is moving towards multiple linear regions, which should allow mmap/munmap like functionality.
And in the context of OpenSSL, this kind of fanciness in some libc's that'll make all sorts of syscalls randomly is exactly why they wrote their own allocator.
Re:WebAssembly doesn’t make unsafe languages safe
by brynet on Monday November 26, 2018 @02:16PM
(#18535991)
The Heartbleed bug would have been found then fixed by the munmap, as the process would have crashed. This has nothing to do with clearing data, it would not have found this.
> And in the context of OpenSSL, this kind of fanciness in some libc's that'll make all sorts of syscalls randomly is exactly why they wrote their own allocator.
"web asm -- if it was good enough for openssl!"
Re:WebAssembly doesn’t make unsafe languages safe
by monocasa on Monday November 26, 2018 @04:40PM
(#18537053)
Heartbleed fully allocated the larger buffer. It wouldn't have crashed. It was just uninitialized memory being read out. Yes, munmap and remap would have cleared that ram, but so would the malloc clearing.
> "web asm -- if it was good enough for openssl!"
More like, "OpenBSD, so slow that people feel the need to write their own malloc".
Otto Moerbeek has a great recent Twitter thread on the topic: https://twitter.com/ottom6k/status/1065594523559096321
https://twitter.com/ottom6k/status/1063118597160091648
> The JIT has no insight into the app's malloc/free usage, so no, it can't. There is no system allocator in WASM, just a big chunk of linear memory that the app does whatever it wants with.
This point by kllrnohj illustrates a pretty significant weakness.