7 ms·

this is complete nonsense. A normal c program running on a modern operating system has the mmu control what memory it can access. So, Web assembly's "just a blo

this is complete nonsense. A normal c program running on a modern operating system has the mmu control what memory it can access. So, Web assembly's "just a block of memory" is no better - it is the same.

sitkack 8y ago
Correct. A normal C program has full reign over the entire process memory space. A wasm program only has access to the call interface provided to it and its linear memory region allocated to it. The guarantees are much different and greatly in favor of wasm. In wasm the stack and the code segments are off limits.
- repsilat 8y ago
  "Full rein". And the C heap is typically a linear memory region (that grows monotonically) isn't it?
  - conradev 8y ago
    The process’ address space includes more than just malloc zones: it includes the code of the running process, the stacks for all of the running threads, linked libraries and their imported functions, etc.
  - slededit 8y ago
    brk does grow linearly (a holdover from the days of segmentation). But malloc may well allocate chunks of virtual memory for large allocations. Windows doesn't have a brk equivalent and the underlying heap is fully implemented via VirtualAlloc.
    - repsilat 8y ago
      Fair, but I think this all amounts to "A linear patch of memory is fine primitive to build an allocator or standard library on." The "not faulting on address zero" thing is interesting but not crazy -- only broken programs will break.
      - slededit 8y ago
        While you can build it that way it is not at all a good way to do it. You lose all the benefits of paging when handling fragmentation - you basically will never be able to shrink the data segment on most practical programs - and therefore never be able to return memory to the operating system. brk is an ancient holdover from when memory protection was done via segmentation. Paging eliminates the need for this historical misfeature. I'm a bit sad WASM propagated it further into modern systems.
        repsilat 8y ago
        Isn't paging orthogonal to using brk? Or is "paging" something more specific than "virtual memory is handled by the OS in big chunks"? I guess your allocator can try its best to prevent fragmentation, but you're right that returning memory to the OS isn't going to happen without explicit compaction (which nobody in native code is going to do.) Dunno if anyone ever expects memory use to go down though. (Is less true than it used to be? -- I guess we used to make big swap files and now that's less fashionable.) I guess if it's not too much more of a burden on the OS to make it keep track of a Swiss cheese virtual memory allocation then it is useful.
        slededit 8y ago
        The OS implements brk under the hood with "swiss cheese virtual memory" so you don't get any real optimizations here. On AMD64 paging is mandatory. It does have a cost but the MMU hardware accelerates this to make it mostly not noticeable. The brk system call places an unnecessary restriction on how the memory is used that is not imposed by the hardware. Back in the 70s when segmentation was a thing and virtual memory hadn't taken hold this would be different - but virtual memory has won.
    - floatboth 8y ago
      Pretty much only glibc malloc still uses brk. GNU being GNU I guess. Modern mallocs like jemalloc use mmap exclusively. FreeBSD straight up did not implement sbrk at all for aarch64 and riscv – very very few things broke because of that (one of the things that did break was, IIRC, GNU Emacs).
- kllrnohj 8y ago
  You missed the author's point by miles. C only has access to its process space as does WASM. WASM's only improvement is it makes stack smashing bugs harder (which ironically makes real security worse as it means you can't use retpoline, but let's ignore that for now) HOWEVER it gives up on using guard pages and address randomization (systemic preventions against common bugs like buffer overflows), making WASM in practice less safe than C. WASM is only safer for the host embedding untrusted code. For trusted code, though, it's across the board worse in every way - including security. Which shouldn't be all that contentious of a statement since WASM had no goals or intentions to ever replace trusted native code execution. That's not a thing it tries to do, and it shouldn't be a surprise that it didn't do it.
  - monocasa 8y ago
    > which ironically makes real security worse as it means you can't use retpoline Why wouldn't the WASM JIT retpoline all code (probably only if the underlying processor needs it) rather than relying on the guest programs to do it themselves. > HOWEVER it gives up on using guard pages and address randomization (systemic preventions against common bugs like buffer overflows), making WASM in practice less safe than C. Once again, wouldn't the JIT be able to enforce this at runtime? It's not like WASM binaries are referencing raw address offsets.
    - kllrnohj 8y ago
      > Why wouldn't the WASM JIT retpoline all code (probably only if the underlying processor needs it) rather than relying on the guest programs to do it themselves. Possible, but is that then a runtime option in the WASM header? How does it know if the program needs the cost of retpoline or not? And how can a program ensure that it's getting such mitigations when it needs them? > Once again, wouldn't the JIT be able to enforce this at runtime? 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. For an actual case study in why this is risky all you have to do is look at OpenSSL's heartbleed. If it had been using the system's malloc/free (which WASM doesn't have) instead of using its internal free lists then heartbleed largely wouldn't have existed on platforms like OpenBSD.
deleted 8y ago
[deleted]

sitkack 8y ago

Correct. A normal C program has full reign over the entire process memory space. A wasm program only has access to the call interface provided to it and its linear memory region allocated to it. The guarantees are much different and greatly in favor of wasm. In wasm the stack and the code segments are off limits.

repsilat 8y ago
"Full rein". And the C heap is typically a linear memory region (that grows monotonically) isn't it?
- conradev 8y ago
  The process’ address space includes more than just malloc zones: it includes the code of the running process, the stacks for all of the running threads, linked libraries and their imported functions, etc.
- slededit 8y ago
  brk does grow linearly (a holdover from the days of segmentation). But malloc may well allocate chunks of virtual memory for large allocations. Windows doesn't have a brk equivalent and the underlying heap is fully implemented via VirtualAlloc.
  - repsilat 8y ago
    Fair, but I think this all amounts to "A linear patch of memory is fine primitive to build an allocator or standard library on." The "not faulting on address zero" thing is interesting but not crazy -- only broken programs will break.
    - slededit 8y ago
      While you can build it that way it is not at all a good way to do it. You lose all the benefits of paging when handling fragmentation - you basically will never be able to shrink the data segment on most practical programs - and therefore never be able to return memory to the operating system. brk is an ancient holdover from when memory protection was done via segmentation. Paging eliminates the need for this historical misfeature. I'm a bit sad WASM propagated it further into modern systems.
      - repsilat 8y ago
        Isn't paging orthogonal to using brk? Or is "paging" something more specific than "virtual memory is handled by the OS in big chunks"? I guess your allocator can try its best to prevent fragmentation, but you're right that returning memory to the OS isn't going to happen without explicit compaction (which nobody in native code is going to do.) Dunno if anyone ever expects memory use to go down though. (Is less true than it used to be? -- I guess we used to make big swap files and now that's less fashionable.) I guess if it's not too much more of a burden on the OS to make it keep track of a Swiss cheese virtual memory allocation then it is useful.
        slededit 8y ago
        The OS implements brk under the hood with "swiss cheese virtual memory" so you don't get any real optimizations here. On AMD64 paging is mandatory. It does have a cost but the MMU hardware accelerates this to make it mostly not noticeable. The brk system call places an unnecessary restriction on how the memory is used that is not imposed by the hardware. Back in the 70s when segmentation was a thing and virtual memory hadn't taken hold this would be different - but virtual memory has won.
  - floatboth 8y ago
    Pretty much only glibc malloc still uses brk. GNU being GNU I guess. Modern mallocs like jemalloc use mmap exclusively. FreeBSD straight up did not implement sbrk at all for aarch64 and riscv – very very few things broke because of that (one of the things that did break was, IIRC, GNU Emacs).
kllrnohj 8y ago
You missed the author's point by miles. C only has access to its process space as does WASM. WASM's only improvement is it makes stack smashing bugs harder (which ironically makes real security worse as it means you can't use retpoline, but let's ignore that for now) HOWEVER it gives up on using guard pages and address randomization (systemic preventions against common bugs like buffer overflows), making WASM in practice less safe than C. WASM is only safer for the host embedding untrusted code. For trusted code, though, it's across the board worse in every way - including security. Which shouldn't be all that contentious of a statement since WASM had no goals or intentions to ever replace trusted native code execution. That's not a thing it tries to do, and it shouldn't be a surprise that it didn't do it.
- monocasa 8y ago
  > which ironically makes real security worse as it means you can't use retpoline Why wouldn't the WASM JIT retpoline all code (probably only if the underlying processor needs it) rather than relying on the guest programs to do it themselves. > HOWEVER it gives up on using guard pages and address randomization (systemic preventions against common bugs like buffer overflows), making WASM in practice less safe than C. Once again, wouldn't the JIT be able to enforce this at runtime? It's not like WASM binaries are referencing raw address offsets.
  - kllrnohj 8y ago
    > Why wouldn't the WASM JIT retpoline all code (probably only if the underlying processor needs it) rather than relying on the guest programs to do it themselves. Possible, but is that then a runtime option in the WASM header? How does it know if the program needs the cost of retpoline or not? And how can a program ensure that it's getting such mitigations when it needs them? > Once again, wouldn't the JIT be able to enforce this at runtime? 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. For an actual case study in why this is risky all you have to do is look at OpenSSL's heartbleed. If it had been using the system's malloc/free (which WASM doesn't have) instead of using its internal free lists then heartbleed largely wouldn't have existed on platforms like OpenBSD.

deleted 8y ago

[deleted]