feat(fuzzing): Add syscall monitoring to canister sandbox #3420
Conversation
venkkatesh-sekar
changed the title
| // and the tid are stored in a BTreeSet, they are ordered based on their creation sequence. | ||
| // | ||
| // By tracing all PIDs and analyzing the associated syscalls, we observe that the critical | ||
| // threads to attach to are typically among the last few, specifically [n-2] and [n-1]. |
There was a problem hiding this comment.
Perhaps we should trace all of them?
There was a problem hiding this comment.
Initially I wanted to trace only the wasm execution but it makes sense to trace all the threads. However, there was an issue with tracer getting stuck on some PIDs. I have spawned the tracers into their own thread pool which should solve this problem
| WaitStatus::PtraceSyscall(_) => { | ||
| if let Ok(regs) = ptrace::getregs(child) { | ||
| let sysno = Sysno::from(regs.orig_rax as u32); | ||
| if !allowed_syscalls.contains(&sysno) { |
There was a problem hiding this comment.
We should likely track entries to and exits from system calls. On syscall exit, RAX contains the return value...
There was a problem hiding this comment.
Done and with PTRACE_O_TRACESYSGOOD set via Options:all, it should be easy as flipping a boolean in the while loop. However, I did notice the rax being the same on both entry and exit so maybe I'm missing something.
In #2513, we introduced the target
//rs/execution_environment/fuzz:fuzzer_sandboxthat allows fuzzers to use cansiter sandbox. In this PR, we improve the library to add syscall monitoring over the sandbox to mimic a pseudo SELinux setting in a test environment.The current approach is simple as in the sandbox panics if it performs a syscall not present in a static list. But the functionality can be further improved in future PRs.