Open yamt opened 7 months ago
Maybe the second way is better, since the issue not only occurs in the host function, but also may occur in runtime, .e.g. allocating argv buffer in wasm_runtime_invoke_native: https://github.com/bytecodealliance/wasm-micro-runtime/blob/30426be82c806391c9709c5c11c891cdf50b528f/core/iwasm/common/wasm_runtime_common.c#L4916-L4921 It didn't happen since it is allocated only when the default buffer in local variable isn't enough and by default the latter is large enough (allows to call a wasm/host function with 31 arguments).
If we only care about the memory allocated by wasm_runtime_malloc, maybe we can auto handle it wasm_runtime_malloc, wasm_runtime_free and after longjmp:
exec_env_tls
is not NULL and its jmp stack isn't NULL), and if yes, allocate an extra node to take the memory allocated, and add the node into current WASMJmpBuf's node listMaybe the second way is better, since the issue not only occurs in the host function, but also may occur in runtime, .e.g. allocating argv buffer in wasm_runtime_invoke_native:
right now i'm inclined towards the first approach because those checks are necessary for OS_ENABLE_HW_BOUND_CHECK=0 anyway.
OK, and it would be good if we also fix the argv buffer allocation issue in wasm_runtime_invoke_native.
another reason why (b) isn't enough is host-provided apis like libc functions. when we hit the guard pages in the middle of libc, it's impossible to recover gracefully.
on SEGV on the guard pages, the signal handler performs longjmp to recover the control flow. for aot frames it's fine. however, when it's caused by native code like host functions, it can end up with resource leaks.
possible solutions:
a. consider native functions hitting guard pages a bug. insert "manual" overflow detection logic to appropriate places instead.
b. insert "resource cleanup callbacks" into the jmpbuf_node stack. execute them after a jump.