warnings from backtrace

[Hal Murray]

[context is signal from signal handler]
>> How much does the handler need?
>What do you mean 'need'?

What syscalls does the handler use?  (and hence need to get its job done)

Backing up a bit.  Here is what a SIGLARM looks like:
2301  13:00:55 --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
2301  13:00:55 rt_sigreturn({mask=[HUP INT QUIT USR1 USR2 ALRM TERM]}) = -1 
EINTR (Interrupted system call)

So it doesn't do any syscalls.  (at least not in this case.)

----------

I think I've figured out why my test case wasn't working.

Here is what thestrace looks like:

2301  13:00:55 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
2301  13:00:55 mmap(NULL, 8392704, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fe3872e1000
2301  13:00:55 mprotect(0x7fe3872e1000, 4096, PROT_NONE) = 10
2301  13:00:55 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, 
si_call_addr=0x7fe38820fe97, si_syscall=__NR_mprotect, 
si_arch=AUDIT_ARCH_X86_64} ---
2301  13:00:55 +++ killed by SIGSYS +++

Note the SIG_BLOCK at the top.

The problem is that pthread_create is blocking signals and the chunk of 
syscalls that I had commented out includes something that pthread_create uses 
(while blocking SIGSYS).

If pthread_create uses something we don't allow, it will crash without any 
message.  That can happen on a familiar system if they change the 
implementation to use a new syscall, or on a new system with a different 
thread implementation where we haven't collected the syscalls used by 
thread/DNS yet.

It will be easy to debug with strace or gdb, but mysterious until we guess 
what is going on.

-----------

I have a strace log from a simple trap at recvfrom that worked as expected.

The msyslog stuff only calls write.  I don't even see a call to get the time. 
???

2022  12:45:21 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, 
si_call_addr=0x7fb4dad27a13, si_syscall=__NR_recvfrom, 
si_arch=AUDIT_ARCH_X86_64} ---
2022  12:45:21 write(2, " 2 Jun 12:45:21 ", 16) = 16
2022  12:45:21 write(2, "ntpd[2022]: ", 12) = 12
2022  12:45:21 write(2, "ERROR: SIGSYS: got a trap.\n", 27) = 27
2022  12:45:21 write(4, " 2 Jun 12:45:21 ntpd[2022]: ERRO"..., 55) = 55
2022  12:45:21 write(2, " 2 Jun 12:45:21 ", 16) = 16
2022  12:45:21 write(2, "ntpd[2022]: ", 12) = 12
2022  12:45:21 write(2, "ERROR: SIGSYS/seccomp bad syscal"..., 48) = 48
2022  12:45:21 write(4, " 2 Jun 12:45:21 ntpd[2022]: ERRO"..., 76) = 76
2022  12:45:21 futex(0x7fb4da8b40f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
2022  12:45:21 write(2, " 2 Jun 12:45:21 ", 16) = 16
2022  12:45:21 write(2, "ntpd[2022]: ", 12) = 12
2022  12:45:21 write(2, "Stack trace:\n", 13) = 13
...

I assume the futex call (sem_xxx) is part of the backtrace.

-----------

Here is the log info:

 2 Jun 12:52:51 ntpd[2097]: sandbox: seccomp enabled.
 2 Jun 12:53:37 ntpd[2097]: ERROR: SIGSYS: got a trap.
 2 Jun 12:53:37 ntpd[2097]: ERROR: SIGSYS/seccomp bad syscall 45/0xc000003e
 2 Jun 12:53:38 ntpd[2097]: Stack trace:
 2 Jun 12:53:38 ntpd[2097]:   /lib64/libpthread.so.0(+0x115c0) 
[0x7ffff72725c0]
 2 Jun 12:53:38 ntpd[2097]:   /lib64/libpthread.so.0(recvfrom+0x13) 
[0x7ffff72719f3]
 2 Jun 12:53:38 ntpd[2097]:   /home/murray/ntpsec/raw/fed/main/ntpd/ntpd(+0xeb
bb) [0x555555562bbb]
 2 Jun 12:53:38 ntpd[2097]:   /home/murray/ntpsec/raw/fed/main/ntpd/ntpd(+0x1c
47e) [0x55555557047e]
 2 Jun 12:53:38 ntpd[2097]:   /home/murray/ntpsec/raw/fed/main/ntpd/ntpd(+0x1c
570) [0x555555570570]
 2 Jun 12:53:38 ntpd[2097]:   /lib64/libc.so.6(__libc_start_main+0xf1) 
[0x7ffff6a5a401]
 2 Jun 12:53:38 ntpd[2097]:   /home/murray/ntpsec/raw/fed/main/ntpd/ntpd(+0x86
ca) [0x55555555c6ca]
 2 Jun 12:53:38 ntpd[2097]: 0.0.0.0 c01d 0d kern kernel time sync disabled

Do we have a recipe for turning those hex offsets into something useful?


-- 
These are my opinions.  I hate spam.