epoll_ctl, epoll_wait: segmentation fault due to missing vm address translation calls.

[stupendoussuperpowers]

Code References: dispatcher.rs::epoll_ctl_syscall dispatcher.rs::epoll_wait_syscall tests/socketepoll.c

I was investigating some of the skipped test cases for root cause analysis, for the case of the socketepoll.c I found the following problem:

We pass struct epoll_event to the epoll_ctl and epoll_wait syscalls to be populated. In our dispatcher, we try to translate it to a Rust struct like so:

let epollevent = interface::get_epollevent(arg4).unwrap();

However, the arg4 variable contains the raw address instead of a translated address within the cage.

This leads to segmentation faults like so:

./scripts/lindtool.sh: line 229: 37729 Segmentation fault      /home/lind/lind-wasm/src/wasmtime/target/debug/wasmtime run --allow-precompiled --wasi threads=y --wasi preview2=n /home/lind/lind-wasm/tests/unit-tests/networking_tests/non-deterministic/socketepoll.cwasm

I tried adding a fix which is in line with the standard approach to dealing with this:

let cage = translate::cagetable_getref(cageid);
let buf = translate_vmmap_addr(&cage, arg4).unwrap() as u64;

let epollevent = interface::get_epollevent(buf).unwrap();

And these seem to fix the segmentation faults.

Let me know if this is a known issue being worked on. (Or if it needs a separate PR)

[Yaxuan-w]

I'm not sure how this fix would interact with ongoing vmmap null handling fixes. Would love to hear more thoughts from @rennergade @yzhang71

[qianxichen233]

I'm not sure how this fix would interact with ongoing vmmap null handling fixes. Would love to hear more thoughts from @rennergade @yzhang71

I believe this is likely related to that PR. However, I also suspect that the implementation of epoll might be flawed as well, as I recall it has never been properly tested, and the epoll implementation on the main branch is probably in a partially broken state.