Stephen (Oct 05 2024 at 02:10): Stephen (Oct 05 2024 at 02:10):Hi all,
I'm trying to learn to use wasmtime with async feature. I have some questions related to the async_stack_zeroing if using pooling allocator. I checked the source code, looks this async_stack_zeroing will be used in deallocate_fiber_stack, it will use memset to zero the first async_stack_keep_resident bytes, then decommit the remaining by using madvise in linux, then the FiberStack itself will be deallocated which there is no decommit this kind of operation in deallocate(). However, if async_stack_zeroing is turn off, it will just return at the beginning, which means the stack will not be reset to 0 in this case? Then if yes, what is the benefit to turn on async_stack_zeroing because it looks this option affect the performance a lot?
Thanks in advance!
Chris Fallin (Oct 05 2024 at 03:17):The idea with stack zeroing is that it's a defense-in-depth mechanism. It prevents data from a previous instance being "right under the nose" of a new instance. That new instance, if the compiler has no bugs, should never see the uninitialized stack memory; but we do not necessarily have a bug-free compiler. All it would take is one bug in the spill/reload or stack frame mechanism for the data from one instance to affect another; and there are some particularly juicy things in the stackframe aside from spilled data, like return addresses and frame pointers.
Chris Fallin (Oct 05 2024 at 03:18):It's kind of like (not exactly, but kind of) running a virtual machine with data in RAM left over from the last virtual machine, because you trust that the code in the new VM will have been compiled correctly and will not observe uninitialized state
Chris Fallin (Oct 05 2024 at 03:19):Wasm compilation is trusted (which is why it's not exactly like my VM example), so again, semantically this step isn't necessary; it's just a (imho) wise defense against a potential for catastrophic bugs
Chris Fallin (Oct 05 2024 at 03:21):FWIW, also, we've had some ideas to reduce this cost: for example, tracking a "watermark" of how much stack is actually touched, and only zeroing that much. Said watermark could be tracked by keeping a non-mapped page at some point as a "tripwire" and, on fault, mapping it in but noting the stack reached that point
Stephen (Oct 05 2024 at 03:26):I see, thanks for explaining!
Last updated: Oct 23 2024 at 20:03 UTC