ntpd w/ --enable-seccomp
hmurray at megapathdsl.net
Sun Nov 27 11:58:07 UTC 2016
Stromeko at nexgo.de said:
> Let me know if you can reproduce or not. I'm using: Linux raspberrypi2
> 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux
I can easily reproduce it, but I can't find what I need.
The way that seccomp works is that you build a big table of all the allowed
syscalls and pass that to the kernel. If you miss one, you get an illegal
Normally, I just run ntpd from gdb:
run -n -u ntp:ntp
when it crashes, a backtrace usually tells me the name of the system call.
It may help to comment out the signal_no_reset line in ntpd/ntp_sandbox.c
I need the __NR_xxx for the system call.
#0 _armv7_tick () at armv4cpuid.S:17
#1 0x76da84b4 in OPENSSL_cpuid_setup () at armcap.c:75
#2 0x76fdeffc in call_init (l=<optimized out>, argc=4, argv=0x7efffc94,
env=0x7efffca8) at dl-init.c:78
#3 0x76fdf0d8 in _dl_init (main_map=0x76fff958, argc=4, argv=0x7efffc94,
env=0x7efffca8) at dl-init.c:126
#4 0x76fcfd84 in _dl_start_user () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I assume that _armv7_tick is the system call, but I can't translate that to
what we need.
This looks like initialization for openssl/libcrypto
We may be able to work around this by calling some crypto routine to make the
initialization happen earlier.
These are my opinions. I hate spam.
More information about the devel