ntpd w/ --enable-seccomp

[Hal Murray]

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 
instruction signal.

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.

I'm seeing:
(gdb) bt
#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.