wasm2c: big endian support moves memory on growth which will cause overheads

[shravanrn]

@sbc100 @keithw @SoniEx2

The big endian support in wasm2c with mmaped linear memory still moves data when growing memory. This is inefficient. Where possible, it is probably simpler to rely on growing memory in place (similar to the little endian implementation)

The context here is Firefox's potential usage of RLBox + wasm2c on the s390x. Beyond the performance concern, an additional issue is that RLBox does not support using wasm2c when memory can be moved.

I believe a fix should be possible.

Approach:

• The rough difference behind wasm's little vs. big endian implementation is the accesses to linear memory. In the little endian impl, accessing an offset i means we are accessing locationlinear_memory[i]. On big endian systems we are accessing linear_memory[linear_memory_size - i - 1]

• Thus, we can avoid moving memories, by reserving the max memory with no page permissions, and growing the usable memory from the end of the allocation to the beginning.

I'll try to look into this soon (Any help or thoughts welcome)

[keithw]

I am amazed and impressed that anybody is even using our s390x/big-endian support, much less Firefox! That's pretty cool.

[shravanrn]

I'm just playing with it for the moment :)
But if everything works (plus a pass where we audit the security a bit more), this will hopefully be enabled in Firefox by default when it is compiled for big endian archs

[rossberg]

Still curious how the host interaction works with this. E.g., when passing a string pointer to the host, isn't it all backwards (and pointing to the wrong end) from the host's perspective?

[shravanrn]

@rossberg RLBox (the glue layer between Wasm sandboxed libraries and host applications) tends to marshal data from the Wasm memory to host memory both for safety reasons (avoiding time-of-check time-of-use scenarios) as well as to perform ABI fixups. For example, one of the current ABI fixups is that long is a 64-bits on a 64-bit Linux host but is 32-bits in Wasm32. So this ABI fixup would kick in, for example, anytime struct with a long member is marshalled. The endianess data flips on strings etc. could, in theory, be handled similarly.

I should caution that this is still early in my testing process. The use of wasm2c in big endian config in Firefox is contingent on whether I am actually able to modify RLBox to hide these differences from the host reasonably well.

The upside here is this this gives me an excuse to cleanup the big endian support in wasm2c.

[shravanrn]

Also, it looks like the basic test suite on s390x is not passing (testing on qemu) --- some tests fail, and these failing tests have results where the bytes are in the wrong order. So I probably have to chase some of that down first

(Edit: correction, the tests pass. There was a bug in my setup)