Were you running a 32 or 64 bit build of thunderbird? If it was 32 bit then you're right that it is move pages but if it was 64 bit then it was seccomp.

We definitely have move_pages support so I'm guessing this was a 64 bit build and it was actually seccomp, which is likely to a bit problematic to support...

(In reply to zephyrus00jp from comment #0)
> --8752-- WARNING: unhandled syscall: 317

I see that too, in mozilla-central, in the past few days.  I'll look
at it in the coming week.

> Segmentation fault
> I am not sure if the Segmentation fault is due to this missing support
> of syscall, but who knows.

I don't think so.

In your mozconfig, you need these

  ac_add_options --disable-jemalloc
  ac_add_options --enable-valgrind

and when you run Valgrind, you need this

  --vex-iropt-register-updates=allregs-at-mem-access

otherwise it will crash in Ionmonkey and asm.js JIT code.  More
generally, read this:
https://developer.mozilla.org/en-US/docs/Mozilla/Testing/Valgrind

(In reply to Tom Hughes from comment #2)
> We definitely have move_pages support so I'm guessing this was a 64 bit
> build and it was actually seccomp, which is likely to a bit problematic to
> support...

Hi,
It is 64-bit build. I compiled this on my 64-bit Debian GNU/Linux.

(In reply to Julian Seward from comment #3)
> (In reply to zephyrus00jp from comment #0)
> > --8752-- WARNING: unhandled syscall: 317
> 
> I see that too, in mozilla-central, in the past few days.  I'll look
> at it in the coming week.

Thank you for the confirmation.
I see. So it is not only me.

> > Segmentation fault
> > I am not sure if the Segmentation fault is due to this missing support
> > of syscall, but who knows.
> 
> I don't think so.
> 
> In your mozconfig, you need these
> 
>   ac_add_options --disable-jemalloc
>   ac_add_options --enable-valgrind

I have these in my mozconfig.

> and when you run Valgrind, you need this
> 
>   --vex-iropt-register-updates=allregs-at-mem-access

I did not have this when I ran Valgrind.

> otherwise it will crash in Ionmonkey and asm.js JIT code.  More
> generally, read this:
> https://developer.mozilla.org/en-US/docs/Mozilla/Testing/Valgrind

Thank you for the pointer. I have taken a look at it and added
--vex-iropt-register-updates=allregs-at-mem-access
but still no luck.

Strange thing is that I can't even get a decent stack trace from gdb even though
the valgrind binary seems unstripped.
Here is the run.
(I took a few options out but it did not seem to make a difference.)

ishikawa@ip030:/REF-COMM-CENTRAL/work-dir$ gdb /usr/local/bin/valgrind
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/valgrind...done.
(gdb) run  --trace-children=yes --smc-check=all-non-file --gen-suppressions=all --vex-iropt-register-updates=allregs-at-mem-access --malloc-fill=0xA5 --free-fill=0xC3 --leak-check=full --num-callers=50 --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/cross-architecture.sup --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/i386-redhat-linux-gnu.sup --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/x86_64-redhat-linux-gnu.sup --show-possibly-lost=no --read-inline-info=yes --show-mismatched-frees=no  /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird-bin 
Starting program: /usr/local/bin/valgrind --trace-children=yes --smc-check=all-non-file --gen-suppressions=all --vex-iropt-register-updates=allregs-at-mem-access --malloc-fill=0xA5 --free-fill=0xC3 --leak-check=full --num-callers=50 --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/cross-architecture.sup --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/i386-redhat-linux-gnu.sup --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/x86_64-redhat-linux-gnu.sup --show-possibly-lost=no --read-inline-info=yes --show-mismatched-frees=no  /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird-bin
process 3530 is executing new program: /usr/local/lib/valgrind/memcheck-amd64-linux
==3530== Memcheck, a memory error detector
==3530== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3530== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==3530== Command: /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird-bin
==3530== 

Program received signal SIGSEGV, Segmentation fault.
0x00000008042c3c84 in ?? ()
(gdb) where
#0  0x00000008042c3c84 in ?? ()
#1  0x0000000802ca1f30 in ?? ()
#2  0x00000008020082e0 in ?? ()
#3  0x0000000000403b5e in ?? ()
#4  0x00000008020082e0 in ?? ()
#5  0x0000000000001c00 in ?? ()
#6  0x0000000000000000 in ?? ()
(gdb) quit
A debugging session is active.

	Inferior 1 [process 3530] will be killed.

Quit anyway? (y or n) y
ishikawa@ip030:/REF-COMM-CENTRAL/work-dir$ 

It certainly looks that the address in question is very high and may be the
compiled code placed in a memory buffer somewhere.


TIA

So the system call is seccomp then... That will be fun...

I figure we're just going to have to fake it, and pretend it was worked but not actually pass it on to the kernel, as any system call filter the client program wants to install might interfere with things valgrind wants to do.

(1) valgrind/memcheck crash

I figured that the crash is related to the version of the kernel supplied by Debian. So some kernel features do not play nicely with valgrind/memcheck. There are so many options to tweak, I could not figure out which option (or the lack of it) is bad for valgrind/memcheck.

valgrind/memcheck crashes under some Debian-supplied version (64-bit) .

Here is a simple table of whether valgrind/memcheck works under a particular kernel version.
------------------------+----------------
Kernel version    | valgrind + C-C TB works or not
------------------------+----------------
Debian     3.2.0...|  works <--- base debian version for wheezy
------------------------+----------------
self-compiled   3.9.0...|  works
------------------------+----------------
self-compiled  3.12.40  | works
------------------------+----------------
self-compiled  3.13.11  | works
------------------------+----------------

self-compiled  3.14.38  | ???  <--- pristine kernel hit the problem

(2) > So the system call is seccomp then... That will be fun...

Just noticed why seccomp is used.


mentioned in the following patch and panicked. open source is
wonderful when it works, but difficult to deal with when it does not :-(

          http://lkml.iu.edu/hypermail/linux/kernel/1407.3/04296.html

------------------------+----------------
self-compiled 3.15.9    | ??? <--- vanilla kernel could not bring up X
                                                 probably because the same problem above.
------------------------+----------------
Debian backport 3.16 ...|  valgrind/memcheck Segmentation fault!
------------------------+----------------
        ....
------------------------+----------------
self-compiled 3.19.5    | works!  <--- This is what I use now.
                                        | It seems to work with userland
                                        | programs/utilities of Debian Jessie (pre-release).
------------------------+----------------


So Debian users who have issues with valgrind/memcheck crashing can compile 3.19.5 and
use the new userland of Jessie in the foreseeable future.

(2)  Use seccomp

I noticed that this warning about unsupported seccomp was printed when
plugin support program was invoked from firefox (not in TB. Sorry about it).
Naturally, you wan to restrict what a plugin can do and so use of seccomp is a natural
consequence when it is available.

TIA

*** Bug 357781 has been marked as a duplicate of this bug. ***

I notice that mozilla-central no causes this complaint.  I assume that 
configuring it with --enable-valgrind causes it not even to bother to try
to use this syscall.

The underlying problem here is that we have no reasonable way to implement
support for this syscall, so we're just ignoring it and causing it to appear to fail.

There are more applications using seccomp now to create a kind of sandbox. e.g. qemu does (when using -sandbox=on).

seccomp is a little tricky for valgrind to implement since valgrind itself might use system calls not used by the application running under valgrind since they are the same process. And the arguments are also tricky to interpret since depending on operation and flags this might be an arbitrary BPF program.

We could simply return ENOSYS for seccomp and not produce the error/warning message.

Or we could do some simple argument checks and pass it through as is to the kernel. That might then break valgrind if the seccomp call blocks some syscall we need, but things are already broken anyway.

Or we could have a new command line flag --allow-seccomp that switches between the two modes of operation?

A third option would be to report success but not actually do anything - that might be necessary for a program which refuses to proceed if it can't install it's seccomp filter but whose filter would break valgrind.

The gold plated option of course would be try and modify the filter to allow any system calls valgrind might use in addition to anything which passes the original filter. That would be hard though, even if theoretically possible, and I'm not sure if even that is true.

Removed user jb.1234abcd from CC.

Created attachment 160505 [details]
--disable-seccomp=yes feature

I propose an option --disable-seccomp=[no|yes] feature to Valgrind, which would fake "seccomp" syscall (and an old style "prctl(PR_SET_SECCOMP...)") success if set to "yes" and would otherwise default to "no".

"prctl" case remains the same unless "yes" is selected and "seccomp" case now returns ENOSYS unless "yes" is selected.

The patch also adds the option to the --help output, man page, and "none/tests/linux/seccomp" test case to the testsuite.

The usecase is that some programs only allow switching seccomp off at compile time.  This way, they can be analyzed without recompilation (at the cost of sandboxing being turned off, because Valgrind is efefctivelly faking seccomp filter installation without doing anything).  The proper emulation of the seccomp feature is impossible since Linux kernel doesn't allow switching between two different filters dynamically and partial solution with Valgrind analyzing cBPF program and whitelisting syscalls it needs for itself is too much work for very little gain.

I tested the patch with the entire testsuite on x86_64 and s390x architectures (OpenSUSE Tumbleweed).


Expected behaviour:

$ valgrind -q --disable-seccomp=yes file /etc/passwd
/etc/passwd: ASCII text
$ valgrind -q --disable-seccomp=no file /etc/passwd
Bad system call
$ valgrind -q file /etc/passwd
Bad system call

$ perl tests/vg_regtest  none/tests/linux/seccomp
seccomp:         valgrind   -q --disable-seccomp=yes ./seccomp

== 1 test, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==

Is that safe to do?

Valgrind, a bit like GDB, is a security risk.

On FreeBSD sysctl security.bsd.unprivileged_proc_debug controls whether applications like gdb or valgrind can run. Does Linux have an equivalent?

FreeBSD Valgrind does support Capsicum (it's capability mode interface), but it just passes on syscalls (after printing a warning when calling cap_enter). The means some Valgrind functionality is lost (specifically opening files after entering capability mode which at least one of the tools uses).

(In reply to Paul Floyd from comment #13)
> Is that safe to do?
> 
> Valgrind, a bit like GDB, is a security risk.

No doubt about that.  But you can always make things safer by disallowing stuff.

> On FreeBSD sysctl security.bsd.unprivileged_proc_debug controls whether
> applications like gdb or valgrind can run. Does Linux have an equivalent?

I haven't used FreeBSD for like 18 years, and I'm not sure what exactly it does, but there's a possibility of doing `sysctl -w kernel.yama.ptrace_scope=2` or similar on Linux to restrict what you can do with ptrace.  But I don't think that restrict valgrind though, just gdb, strace etc.  Is Valgrind using ptrace for something?

> FreeBSD Valgrind does support Capsicum (it's capability mode interface), but
> it just passes on syscalls (after printing a warning when calling
> cap_enter). The means some Valgrind functionality is lost (specifically
> opening files after entering capability mode which at least one of the tools
> uses).

The trouble is that it's a bit random about what is disallowed by seccomp.  The default filter will kill valgrind for sure and otherwise it's about analyzing random cBPF filter that might be completely different per application.

But, bear in mind is that I'm not proposing this to be the default behaviour.  Nothing really changes except that you have now a choice to disable sandboxing.  It's, I think, reasonably well described in the man page including the security implications.

Also note this patch that implements more of seccomp:
https://sourceforge.net/p/valgrind/mailman/message/46305485/

*** Bug 380183 has been marked as a duplicate of this bug. ***

(In reply to Mark Wielaard from comment #15)
> Also note this patch that implements more of seccomp:
> https://sourceforge.net/p/valgrind/mailman/message/46305485/

To be honest.  I was not trying to implement seccomp. I was trying to find a way to turn it off. :-)

I took a look at the patch from the mailing list.  Seeing "[PATCH 1/2]", is there a second part to it?  I see only one.  I'm not subscribed to valgrind-devel and the sourceforge web interface isn't the nicest one I have seen.

 If I read the valgrind-devel patch correctly, it does... 

for SECCOMP_SET_MODE_STRICT
1/ make seccomp call visible two --trace-syscalls=yes
2/ say nothing about it's arguments

for SECCOMP_SET_MODE_FILTER
1/ make seccomp call visible two --trace-syscalls=yes
2/ tell valgrind it reads 3 arguments from registers
3/ tell valgrind it reads a memory from the third argument pointer (size of 1?)

I doesn't deal with SECCOMP_GET_ACTION_AVAIL and SECCOMP_GET_NOTIF_SIZES at all.

In other words it does slightly less then what is currently being done for the same operations invoked via older prctl syscall, because that tells valgrind it reads 2 arguments from registers in case of SECCOMP_MODE_STRICT additionally.  To be fair, strict mode is a lost cause anyway for the simplests of programs, unless they are specifically designed to run in it.  It breaks even "int main(void) {}" if you link against glibc, since glibc started invoking exit_group(0) for all programs at some point (which is a syscall not allowed in seccomp strict mode).

When I was writing the patch, I tried to preserve the prctl syscall case while mark seccomp syscall as unimplemented.  What I could do is basically copy paste the prctl syscall case onto seccomp syscall case and tweak it and see how to handle additional SECCOMP_GET_ACTION_AVAIL and SECCOMP_GET_NOTIF_SIZES operations.

Created attachment 164961 [details]
--disable-seccomp=yes feature v2

Second version of the patch.  It's not final, as I should throw in a few test cases.  Disabling seccomp still allows SECCOMP_GET_ACTION_AVAIL and SECCOMP_GET_NOTIF_SIZES  operations as those should never stop valgrind from working. I implemented some basic seccomp syscall checks (and left prctl as it was), then I thought I would throw in a few warnings based on how seccomp syscall api should be used, but I must say that the verbosity of the warnings surprised me.

The default behviour: 
> $ valgrind file /bin/ls
> ==17247== Memcheck, a memory error detector
> ==17247== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
> ==17247== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright info
> ==17247== Command: file /bin/ls
> ==17247==
> ==17247== WARNING: in STRICT SECCOMP mode 2nd argument (flags) should always be 0
> ==17247== WARNING: valgrind is unlikely to work in STRICT SECCOMP mode
> ==17247== WARNING: in FILTER SECCOMP mode 3nd argument (args) should point to struct sock_fprog
> ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode
> ==17247== WARNING: in FILTER SECCOMP mode 3nd argument (args) should point to struct sock_fprog
> ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode
> ==17247== WARNING: in FILTER SECCOMP mode 3nd argument (args) should point to struct sock_fprog
> ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode
> ==17247== WARNING: in FILTER SECCOMP mode 3nd argument (args) should point to struct sock_fprog
> ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode
> ==17247== WARNING: in FILTER SECCOMP mode 3nd argument (args) should point to struct sock_fprog
> ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode
> ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode
> Bad system call

It seems to me that those warnings are not imaginary:
> $ strace -e seccomp file /bin/ls
> seccomp(SECCOMP_SET_MODE_STRICT, 0x1, NULL) = -1 EINVAL (Invalid argument)
> seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address)
> seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_LOG, NULL) = -1 EFAULT (Bad address)
> seccomp(SECCOMP_GET_ACTION_AVAIL, 0, 0x7ffdbdae238c) = 0
> seccomp(SECCOMP_GET_ACTION_AVAIL, 0, 0x7ffdbdae238c) = 0
> seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_SPEC_ALLOW, NULL) = -1 EFAULT (Bad address)
> seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_NEW_LISTENER, NULL) = -1 EFAULT (Bad address)
> seccomp(SECCOMP_GET_NOTIF_SIZES, 0, 0x7ffdbdae2392) = 0
> seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC_ESRCH, NULL) = -1 EFAULT (Bad address)
> seccomp(SECCOMP_SET_MODE_FILTER, 0, 0x564b7a15e490) = 0
> /bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=22f5cfe4926547861d47486e96c0dceb360dec09, for GNU/Linux 3.2.0, stripped
> +++ exited with 0 +++

Disabling it works just fine:
> $ valgrind --disable-seccomp=yes file /bin/ls
> ==17584== Memcheck, a memory error detector
> ==17584== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
> ==17584== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright info
> ==17584== Command: file /bin/ls
> ==17584==
> /bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=22f5cfe4926547861d47486e96c0dceb360dec09, for GNU/Linux 3.2.0, stripped
> ==17584==
> ==17584== HEAP SUMMARY:
> ==17584==     in use at exit: 0 bytes in 0 blocks
> ==17584==   total heap usage: 838 allocs, 838 frees, 8,364,592 bytes allocated
> ==17584==
> ==17584== All heap blocks were freed -- no leaks are possible
> ==17584==
> ==17584== For lists of detected and suppressed errors, rerun with: -s
> ==17584== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Created attachment 164984 [details]
--disable-seccomp=yes feature v3

I added two testcases and fixed linking of postwrappers.

> $ perl tests/vg_regtest  none/tests/linux/seccomp?
> seccomp1:        valgrind   -q --disable-seccomp=yes ./seccomp1 
> seccomp2:        valgrind   -q ./seccomp2 
> seccomp3:        valgrind   -q ./seccomp3 
> 
> == 3 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==

Created attachment 165137 [details]
implement --disable-seccomp=[no|yes] and seccomp syscall v4

Sorry, for the spam.  I added another testcase and improved the remaining ones.  The seccomp4 test is especially important, because it shows that valgrind will still work with seccomp filter active unless something important is blacklisted (I'm using alarm syscall there).  Tested on x86_64 (kernel 6.6) and s390x (kernel 5.14).

> $ perl tests/vg_regtest  none/tests/linux/seccomp?
> seccomp1:        valgrind   -q --disable-seccomp=yes ./seccomp1 
> seccomp2:        valgrind   -q ./seccomp2 
> seccomp3:        valgrind   -q ./seccomp3 
> seccomp4:        valgrind   -q ./seccomp4 
> 
> == 4 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==

I would be grateful for any kind of review.

*** Bug 492482 has been marked as a duplicate of this bug. ***

Created attachment 175864 [details]
implement --disable-seccomp=[no|yes] and seccomp syscall

I rebased the patch to the current master, since it no longer applied.

Created attachment 175865 [details]
seccomp syscall: warn only once

I was also thinking about reducing the amount of warnings for the bad case.  One option would be not to warn, and another to warn only once.  Perhaps, it could be hidden behind a macro instead of the repetition, but I'm not sure.  The trouble is that libseccomp is misusing seccomp api to check whether seccomp is supported at all on older kernels by invoking the syscall with an invalid combination of arguments and looking at the error code and this is happening more than once.

> $ valgrind /usr/bin/file /etc/passwd
> ==219469== Memcheck, a memory error detector
> ==219469== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
> ==219469== Using Valgrind-3.25.0.GIT and LibVEX; rerun with -h for copyright info
> ==219469== Command: /usr/bin/file /etc/passwd
> ==219469== 
> ==219469== WARNING: in STRICT SECCOMP mode 2nd argument (flags) should always be 0
> ==219469== WARNING: valgrind is unlikely to work in STRICT SECCOMP mode
> ==219469== WARNING: in FILTER SECCOMP mode 3nd argument (args) should point to struct sock_fprog
> ==219469== WARNING: valgrind might not work in FILTER SECCOMP mode
> Bad system call