5 ms·

This is ignoring an important benefit of the libc implementations of malloc/free on OpenBSD, free pages are being opportunistically munmap'd at random. This cat

by brynet 8y ago

This is ignoring an important benefit of the libc implementations of malloc/free on OpenBSD, free pages are being opportunistically munmap'd at random. This catches actual bugs. Otto Moerbeek has a great recent Twitter thread on the topic: https://twitter.com/ottom6k/status/1065594523559096321 https://twitter.com/ottom6k/status/1065594523559096321 https://twitter.com/ottom6k/status/1063118597160091648 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.

monocasa 8y ago
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.
- brynet 8y ago
  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!"
  - monocasa 8y ago
    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".

by brynet 8y ago

monocasa 8y ago

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.

brynet 8y ago
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!"
- monocasa 8y ago
  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".