3 ms·

> In that case, just fall back to bitwise AND index clamping. A small performance penalty, but nothing major. Masking the index will break code that is actuall

by dbaupp 8y ago

> In that case, just fall back to bitwise AND index clamping. A small performance penalty, but nothing major. Masking the index will break code that is actually using the larger address space: running true 64-bit WASM code (as in, using >4GB of space) won't work, which is what I was referring to. > page table entries Indeed, hence the reference to virtual memory. In any case, because both x86-64 and ARM64 only have 48 bits of actually addressable space, that 4GB of overhead (plus, up to 4GB of actual addressable memory) only allows for 65536 (or half that) WASM instances. That's definitely a large number, but not one that is out of reach.

vardump 8y ago
> Masking the index will break code that is actually using the larger address space: running true 64-bit WASM code (as in, using >4GB of space) won't work, which is what I was referring to. You can also clamp for example at 33-37 bits, giving 8-128 GB array range.
- comesee 8y ago
  You can do masking in the same way Linux does it. It prevents "branch code bypass" without using an explicit size: cmp %bound, %ptr jae bad_ptr sbb %mask, %mask and %mask, %ptr Just two extra instructions. No need to memory map or hard code the size of bounds. See `array_index_mask_nospec` in https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/barrier.h https://github.com/torvalds/linux/blob/master/arch/x86/inclu...
  - vardump 8y ago
    > Just two extra instructions. No need to memory map or hard code the size of bounds. Pretty neat idea! [Although the (register) dependency chain looks a bit nasty. 'and' will need 'sbb' to commit and 'sbb' will need to wait for 'cmp' to commit (flags register). But I guess the few/rare cases where this latency is really an issue can be dealt one-by-one basis.] > No need to memory map Well, using MMU can have performance benefits. Less repetitive bounds checking code and better performance in most scenarios. Both solutions have their strengths and issues, there are no silver bullets.
    - comesee 8y ago
      Good point on the MMU performance advantage and trade offs involved. When everyone's heads were on fire, made sense to indiscriminately mask off user controlled pointers. Now that the dust has settled a bit I imagine we'll see more usage of memory mapping tricks in performance critical sections.
- dbaupp 8y ago
  And now you're limited to 2048 WASM instances in a single address space, purely because of virtual memory overhead. To be clear, I think the idea is very neat, but, like most things, comes with a variety of trade-offs that should be reasoned about rather than papered over.

by dbaupp 8y ago

vardump 8y ago

> Masking the index will break code that is actually using the larger address space: running true 64-bit WASM code (as in, using >4GB of space) won't work, which is what I was referring to. You can also clamp for example at 33-37 bits, giving 8-128 GB array range.

comesee 8y ago
You can do masking in the same way Linux does it. It prevents "branch code bypass" without using an explicit size: cmp %bound, %ptr jae bad_ptr sbb %mask, %mask and %mask, %ptr Just two extra instructions. No need to memory map or hard code the size of bounds. See `array_index_mask_nospec` in https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/barrier.h https://github.com/torvalds/linux/blob/master/arch/x86/inclu...
- vardump 8y ago
  > Just two extra instructions. No need to memory map or hard code the size of bounds. Pretty neat idea! [Although the (register) dependency chain looks a bit nasty. 'and' will need 'sbb' to commit and 'sbb' will need to wait for 'cmp' to commit (flags register). But I guess the few/rare cases where this latency is really an issue can be dealt one-by-one basis.] > No need to memory map Well, using MMU can have performance benefits. Less repetitive bounds checking code and better performance in most scenarios. Both solutions have their strengths and issues, there are no silver bullets.
  - comesee 8y ago
    Good point on the MMU performance advantage and trade offs involved. When everyone's heads were on fire, made sense to indiscriminately mask off user controlled pointers. Now that the dust has settled a bit I imagine we'll see more usage of memory mapping tricks in performance critical sections.
dbaupp 8y ago
And now you're limited to 2048 WASM instances in a single address space, purely because of virtual memory overhead. To be clear, I think the idea is very neat, but, like most things, comes with a variety of trade-offs that should be reasoned about rather than papered over.