Miscellaneous syscalls to support running Tor

[robgjansen]

No description provided.

[codecov]

Codecov Report

Merging #1075 (a1f71da) into dev (2448c17) will decrease coverage by 0.05%.
The diff coverage is 41.01%.

@@            Coverage Diff             @@
##              dev    #1075      +/-   ##
==========================================
- Coverage   55.04%   54.98%   -0.06%     
==========================================
  Files         130      133       +3     
  Lines       19586    19772     +186     
  Branches     4676     4711      +35     
==========================================
+ Hits        10781    10872      +91     
- Misses       6045     6111      +66     
- Partials     2760     2789      +29     

Flag	Coverage Δ
tests	54.98% <41.01%> (-0.06%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/main/host/syscall/sysinfo.c	0.00% <0.00%> (ø)
src/test/signal/test_signal.c	18.18% <11.76%> (ø)
src/shim/preload_syscalls.c	47.61% <25.00%> (-0.40%)	⬇️
src/main/host/syscall/process.c	31.57% <25.71%> (-68.43%)	⬇️
src/main/host/syscall/futex.c	63.09% <37.50%> (-2.70%)	⬇️
src/main/host/process.c	73.51% <57.14%> (-0.50%)	⬇️
src/main/host/host.c	67.85% <63.63%> (-0.16%)	⬇️
src/main/host/syscall/signal.c	65.38% <65.38%> (ø)
src/main/host/syscall_handler.c	55.45% <75.00%> (+1.64%)	⬆️
.../main/core/scheduler/scheduler_policy_host_steal.c	81.67% <0.00%> (-0.39%)	⬇️
... and 8 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2448c17...6d2bdc7. Read the comment docs.

[robgjansen]

Oh I see I should enable the test_getpid_kill test in src/test/unistd/test_unistd.rs now that kill is supported.

[stevenengler]

Looks good!

During a meeting we discussed a few limitations of the signal support. The plan is just to document these for now.

1. There's a minor issue of causality when using the native Linux signal functionality rather than implementing signals as events/tasks, but this shouldn't be important since only one process/thread per host can be running at once.
2. If the plugin uses the SIGSTOP or SIGCONT signals, it could cause issues for ptrace mode.
3. In preload mode, this could cause issues for plugins that have syscall handlers. If process A sends a signal to process B, process B which is not currently running (and is waiting on a syscall) will receive the signal and start running the signal handler. The signal handler may make a syscall which gets intercepted by Shadow, and Shadow will try to make a second syscall while it's already processing the first one and will result in an error/crash.
4. In preload mode, even if there is no signal handler registered, if the shim is waiting for a message from a Shadow worker (the shim is waiting on the semaphore), a signal will interrupt the wait and Shadow will continue as if the semaphore wait has finished when it hasn't.

[robgjansen]

Another option for dealing with signals is to only allow processes to send signals to themselves, which is the approach taken in the "Reproducible Containers" paper.