about summary refs log tree commit diff stats
path: root/doc
diff options
context:
space:
mode:
authorbptato <nincsnevem662@gmail.com>2024-10-31 17:44:03 +0100
committerbptato <nincsnevem662@gmail.com>2024-10-31 18:38:16 +0100
commitd9ca197ed8056c021d4e37ec52aacc6039e24ab7 (patch)
tree782781c4bb85e65f112092f96c7ee91e447c7c97 /doc
parentd9a74dbdeef846a98a464bfc102ce282b45e9606 (diff)
downloadchawan-d9ca197ed8056c021d4e37ec52aacc6039e24ab7.tar.gz
chaseccomp: fix compilation with newest dash, misc changes
* fix matching on unstripped whitespace: caught after upgrading to
  upstream dash & chaseccomp wouldn't compile
* add defines to ensure that we computed the filter length correctly
* inline cut_label
* EPERM on sigaction, sigprocmask, gettid, and kill on tgkill (so a
  crash doesn't trigger sandbox violations)
* move SIGSYS handler to C and add one for the network

The last change removes the stack trace from SIGSYS, but gives us the
syscall number which is probably more useful. (Indeed, we don't even
have a stack trace in release builds.)
Diffstat (limited to 'doc')
-rw-r--r--doc/hacking.md22
1 files changed, 10 insertions, 12 deletions
diff --git a/doc/hacking.md b/doc/hacking.md
index 99404064..12672fd1 100644
--- a/doc/hacking.md
+++ b/doc/hacking.md
@@ -212,18 +212,16 @@ Use `config.color.toml` and `my-test-case.color.expected` to preserve colors.
 
 ### Sandbox violations
 
-First, note that a nil deref can also trigger a sandbox violation. Read
-the stack trace to make sure you aren't dealing with that.
-
-Then, figure out if it's happening in a CGI process or a buffer
-process. If your buffer was swapped out for the console, it's likely the
-latter; otherwise, the former.
-
-Now change the appropriate sandbox handler from `SCMP_ACT_TRAP` to
-`SCMP_ACT_KILL_PROCESS`. Run `strace -f ./cha -o start.console-buffer [...] 2>a`,
-trigger the crash, then search for "killed by SIGSYS" in `a`. Copy the
-logged PID, then search backwards once; you should now see the syscall
-that got your process killed.
+You got a syscall number (assuming you're on Linux); look it up in the
+Linux syscall table for your architecture.
+
+To get more context on what happened, you can run
+`strace -f ./cha -o start.console-buffer [...] 2>a`, trigger the crash,
+then search for the last occurrence of "--- SIGSYS". Then search
+backwards on the PID to see the last syscalls.
+
+(Incidentally, strace also shows the syscall name, so it may be easier
+to check like that than looking it up in the syscall table.)
 
 ## Resources