emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: GNU bug Tracking System
Subject: bug#47708: closed (28.0.50; SIGSYS test failure with seccomp-filter.bpf)
Date: Sun, 11 Apr 2021 18:50:01 +0000

Your message dated Sun, 11 Apr 2021 19:49:47 +0100
with message-id <87wnt8odv8.fsf@tcd.ie>
and subject line Re: bug#47708: 28.0.50; SIGSYS test failure with 
seccomp-filter.bpf
has caused the debbugs.gnu.org bug report #47708,
regarding 28.0.50; SIGSYS test failure with seccomp-filter.bpf
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
47708: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=47708
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 28.0.50; SIGSYS test failure with seccomp-filter.bpf Date: Sun, 11 Apr 2021 14:17:53 +0100
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:

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.
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)

--- End Message ---
--- Begin Message --- Subject: Re: bug#47708: 28.0.50; SIGSYS test failure with seccomp-filter.bpf Date: Sun, 11 Apr 2021 19:49:47 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]