Stream: git-wasmtime

Topic: wasmtime / issue #3278 Wasmtime: text section alignment i...


view this post on Zulip Wasmtime GitHub notifications bot (Sep 01 2021 at 18:33):

alexcrichton opened issue #3278:

Currently when assembling an object file Wasmtime will always specify a 4k page alignment for the text section. The goal of this alignment is to ensure that the file contents are aligned such that when mmap'd into memory the start of the text section will be on a page boundary, allowing to switch the page to executable permissions.

This assumption today is incorrect for platforms whose page size is not 4k, such as AArch64 Apple M1 machines. This is intended to track the fix in https://github.com/bytecodealliance/wasmtime/pull/3274

view this post on Zulip Wasmtime GitHub notifications bot (Sep 02 2021 at 16:49):

cfallin closed issue #3278:

Currently when assembling an object file Wasmtime will always specify a 4k page alignment for the text section. The goal of this alignment is to ensure that the file contents are aligned such that when mmap'd into memory the start of the text section will be on a page boundary, allowing to switch the page to executable permissions.

This assumption today is incorrect for platforms whose page size is not 4k, such as AArch64 Apple M1 machines. This is intended to track the fix in https://github.com/bytecodealliance/wasmtime/pull/3274

view this post on Zulip Wasmtime GitHub notifications bot (Sep 06 2021 at 19:23):

akirilov-arm commented on issue #3278:

IMHO the current solution could be improved further because depending on your definition of a platform, even a single platform may use different page sizes. For example, Ubuntu-based distributions running on AArch64 tend to use 4 KB pages, while RHEL-based ones prefer 64 KB as the size. Of course, a simple fix could be simply to increase the current hardcoded value (for that platform) from 4 to 64 KB, but I am not sure about the ramifications of that change (It is quite a big jump!).

cc @bjorn3 @bnjbvr

view this post on Zulip Wasmtime GitHub notifications bot (Sep 07 2021 at 07:39):

bnjbvr commented on issue #3278:

I seem to recall having seen that each trampoline would get its own code page, as well as each wasm module, so this might cause a bit of allocation overhead. I don't know if we manage allocations at a sub-page granularity level; if so, that would probably be fine to have larger OS page sizes by default.

(I seem to fuzzily recall there are also security implications related to this, as larger page sizes make it easier to exhaust memory and then predict where a code allocation landed, effectively bypassing ASLR, but that might require additional conditions; maybe someone who's less fuzzy can confirm/contradict this.)

view this post on Zulip Wasmtime GitHub notifications bot (Sep 08 2021 at 14:17):

alexcrichton commented on issue #3278:

The current idea is that we want to be able to mmap the text section directly from within a file which is where the page alignment requirements comes in. I also tried to make it such that only the text section itself was made executable, but we could also just make whatever pages contain the text section executable, although that will make unrelated bits executable which seems bad.

I think it's probably fine to just round up to the most generous page sized used on a platform for now. It means that module serialized artifacts will have some extra 0's in them but most modules are going to be larger than 64k anyway. I don't think there's currently any need to optimize the raw format of a module for byte-size, especially since the compressed size will paper over this.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 13 2021 at 17:08):

akirilov-arm commented on issue #3278:

I tried increasing the default text section alignment on AArch64 to 64 KB, but then I hit an issue, namely a check in CodeMemory::publish(), which failed when I tried running the compiled module on a system with 4 KB pages. I am not sure how to proceed - I think we mostly care that the .text section is correctly aligned on the runtime page size, not the page size we assume when generating the object file. On the other hand, it feels wrong to ignore the alignment value we read from the object file. Any ideas?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 13 2021 at 17:32):

alexcrichton commented on issue #3278:

Yeah I think it's safe to remove that assertion, that was mostly me trying to double-check things but it doesn't serve much purpose and the assertion for page-alignment down below is all we really need.

Either that or we could specifically allow the .text section to "violate" its alignment for a documented reason.


Last updated: Nov 22 2024 at 16:03 UTC