bug#47708: 28.0.50; SIGSYS test failure with seccomp-filter.bpf

["Basil L. Contovounesios" <contovob@tcd.ie>]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Philipp Stephani <p.stephani2@gmail.com> writes:
>
>> Could you check which syscall exactly is failing, e.g. using
>> journalctl -g SECCOMP -t audisp-syslog
>> (assuming that system uses systemd and seccomp audit logging is enabled).
>
> After running:
>
>   ./src/emacs -Q -batch -seccomp test/src/emacs-resources/seccomp-filter.bpf
>
> the last audit in 'sudo journalctl -g SECCOMP' is:
>
>   Apr 11 18:08:56 tia audit[25251]: SECCOMP auid=1000 uid=1000 gid=1000
>   ses=3 subj==unconfined pid=25251 comm="emacs"
>   exe="/home/blc/.local/src/emacs/src/emacs" sig=31 arch=c000003e
>   syscall=228 compat=0 ip=0x7fff7f1f7a7d code=0x80000000
>
> Looking up syscall 228 online points to clock_gettime, just like in the
> GDB log I attached in my previous message.

I don't know whether this is relevant, but 'man 2 seccomp' has the
following to say about clock_gettime:

  Caveats
      There are various subtleties to consider when applying seccomp  filters
      to a program, including the following:

      *  Some traditional system calls have user-space implementations in the
         vdso(7) on many architectures.  Notable examples include  clock_get‐
         time(2),  gettimeofday(2), and time(2).  On such architectures, sec‐
         comp filtering for these system calls will have  no  effect.   (How‐
         ever,  there  are  cases  where the vdso(7) implementations may fall
         back to invoking the true system call, in which case seccomp filters
         would see the system call.)

-- 
Basil