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

[Philipp Stephani <p.stephani2@gmail.com>]

Am So., 11. Apr. 2021 um 19:19 Uhr schrieb 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.)
>

Nice catch. I think it should be fine to allow the clock system calls.
I've now done that with commit
ea5ea09244b762008bba509d8c58bad5835fb949.