* bug#47708: 28.0.50; SIGSYS test failure with seccomp-filter.bpf
@ 2021-04-11 13:17 Basil L. Contovounesios
2021-04-11 13:58 ` Philipp Stephani
0 siblings, 1 reply; 7+ messages in thread
From: Basil L. Contovounesios @ 2021-04-11 13:17 UTC (permalink / raw
To: 47708; +Cc: Philipp Stephani
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
On Debian Testing with libseccomp 2.5.1-1, 'make test/emacs-tests' fails
with:
Test emacs-tests/seccomp/allows-stdout backtrace:
signal(ert-test-failed (((should (eql status 0)) :form (eql "Bad sys
ert-fail(((should (eql status 0)) :form (eql "Bad system call" 0) :v
[...]
normal-top-level()
Test emacs-tests/seccomp/allows-stdout condition:
Info: Process output:
(ert-test-failed
((should
(eql status 0))
:form
(eql "Bad system call" 0)
:value nil))
FAILED 2/6 emacs-tests/seccomp/allows-stdout (0.032159 sec)
Investigating a bit further, from the source tree root:
0. cd src
1. gdb ./emacs
2. set logging on
3. b pdumper.c:5263
4. r -Q -batch -seccomp ../test/src/emacs-resources/seccomp-filter.bpf
5. s RET RET RET
6. q
Here's the log:
[-- Attachment #2: gdb.txt --]
[-- Type: text/plain, Size: 887 bytes --]
Breakpoint 3 at 0x28ab53: file pdumper.c, line 5263.
Starting program: /home/blc/.local/src/emacs/src/emacs -Q -batch -seccomp ../test/src/emacs-resources/seccomp-filter.bpf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 3, pdumper_load (dump_filename=0x555555ed99f0 "/home/blc/.local/src/emacs/src/emacs.pdmp")
at pdumper.c:5263
5263 const struct timespec start_time = current_timespec ();
current_timespec () at gettime.c:47
47 gettime (&ts);
gettime (ts=0x7fffffffd8b0) at gettime.c:32
32 clock_gettime (CLOCK_REALTIME, ts);
__GI___clock_gettime (clock_id=0, tp=0x7fffffffd8b0) at ../sysdeps/unix/sysv/linux/clock_gettime.c:38
38 ../sysdeps/unix/sysv/linux/clock_gettime.c: No such file or directory.
Program terminated with signal SIGSYS, Bad system call.
The program no longer exists.
[-- Attachment #3: Type: text/plain, Size: 2555 bytes --]
Let me know if you'd like me to test anything further.
Thanks,
--
Basil
In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
of 2021-04-11 built on tia
Repository revision: 686c366f8a63c448d06e5f08d604374fb316bc57
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Debian GNU/Linux bullseye/sid
Configured using:
'configure 'CC=ccache gcc' 'CFLAGS=-O0 -g3 -ggdb -gdwarf-4'
--prefix=/home/blc/.local --enable-checking=yes,glyphs
--enable-check-lisp-object-type --with-x-toolkit=lucid
--with-file-notification=yes --with-x'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XAW3D XDBE XIM XPM LUCID ZLIB
Important settings:
value of $LANG: en_IE.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process emacs)
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#47708: 28.0.50; SIGSYS test failure with seccomp-filter.bpf
2021-04-11 13:17 bug#47708: 28.0.50; SIGSYS test failure with seccomp-filter.bpf Basil L. Contovounesios
@ 2021-04-11 13:58 ` Philipp Stephani
2021-04-11 17:13 ` Basil L. Contovounesios
0 siblings, 1 reply; 7+ messages in thread
From: Philipp Stephani @ 2021-04-11 13:58 UTC (permalink / raw
To: Basil L. Contovounesios; +Cc: 47708
Am So., 11. Apr. 2021 um 15:19 Uhr schrieb Basil L. Contovounesios
<contovob@tcd.ie>:
>
> On Debian Testing with libseccomp 2.5.1-1, 'make test/emacs-tests' fails
> with:
>
> Test emacs-tests/seccomp/allows-stdout backtrace:
> signal(ert-test-failed (((should (eql status 0)) :form (eql "Bad sys
> ert-fail(((should (eql status 0)) :form (eql "Bad system call" 0) :v
> [...]
> normal-top-level()
> Test emacs-tests/seccomp/allows-stdout condition:
> Info: Process output:
> (ert-test-failed
> ((should
> (eql status 0))
> :form
> (eql "Bad system call" 0)
> :value nil))
> FAILED 2/6 emacs-tests/seccomp/allows-stdout (0.032159 sec)
>
Thanks for the report! 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).
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#47708: 28.0.50; SIGSYS test failure with seccomp-filter.bpf
2021-04-11 13:58 ` Philipp Stephani
@ 2021-04-11 17:13 ` Basil L. Contovounesios
2021-04-11 17:19 ` Basil L. Contovounesios
2021-04-11 17:39 ` Philipp Stephani
0 siblings, 2 replies; 7+ messages in thread
From: Basil L. Contovounesios @ 2021-04-11 17:13 UTC (permalink / raw
To: Philipp Stephani; +Cc: 47708
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.
Is there something else I can check?
Thanks,
--
Basil
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#47708: 28.0.50; SIGSYS test failure with seccomp-filter.bpf
2021-04-11 17:13 ` Basil L. Contovounesios
@ 2021-04-11 17:19 ` Basil L. Contovounesios
2021-04-11 17:52 ` Philipp Stephani
2021-04-11 17:39 ` Philipp Stephani
1 sibling, 1 reply; 7+ messages in thread
From: Basil L. Contovounesios @ 2021-04-11 17:19 UTC (permalink / raw
To: Philipp Stephani; +Cc: 47708
"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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#47708: 28.0.50; SIGSYS test failure with seccomp-filter.bpf
2021-04-11 17:13 ` Basil L. Contovounesios
2021-04-11 17:19 ` Basil L. Contovounesios
@ 2021-04-11 17:39 ` Philipp Stephani
1 sibling, 0 replies; 7+ messages in thread
From: Philipp Stephani @ 2021-04-11 17:39 UTC (permalink / raw
To: Basil L. Contovounesios; +Cc: 47708
Am So., 11. Apr. 2021 um 19:13 Uhr schrieb Basil L. Contovounesios
<contovob@tcd.ie>:
>
> 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.
Thanks for the confirmation. (Occasionally the actual syscall is
different from the C library function that invokes it.)
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#47708: 28.0.50; SIGSYS test failure with seccomp-filter.bpf
2021-04-11 17:19 ` Basil L. Contovounesios
@ 2021-04-11 17:52 ` Philipp Stephani
2021-04-11 18:49 ` Basil L. Contovounesios
0 siblings, 1 reply; 7+ messages in thread
From: Philipp Stephani @ 2021-04-11 17:52 UTC (permalink / raw
To: Basil L. Contovounesios; +Cc: 47708
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#47708: 28.0.50; SIGSYS test failure with seccomp-filter.bpf
2021-04-11 17:52 ` Philipp Stephani
@ 2021-04-11 18:49 ` Basil L. Contovounesios
0 siblings, 0 replies; 7+ messages in thread
From: Basil L. Contovounesios @ 2021-04-11 18:49 UTC (permalink / raw
To: Philipp Stephani; +Cc: 47708-done
Philipp Stephani <p.stephani2@gmail.com> writes:
> Am So., 11. Apr. 2021 um 19:19 Uhr schrieb Basil L. Contovounesios
> <contovob@tcd.ie>:
>>
>> 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.
Thanks, that fixes the test failure here, so I'm closing this report.
--
Basil
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-04-11 18:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-04-11 13:17 bug#47708: 28.0.50; SIGSYS test failure with seccomp-filter.bpf Basil L. Contovounesios
2021-04-11 13:58 ` Philipp Stephani
2021-04-11 17:13 ` Basil L. Contovounesios
2021-04-11 17:19 ` Basil L. Contovounesios
2021-04-11 17:52 ` Philipp Stephani
2021-04-11 18:49 ` Basil L. Contovounesios
2021-04-11 17:39 ` Philipp Stephani
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.