The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=39358 

------------------------------------------------------------------------
r39358 | evan@chromium.org | 2010-02-18 07:25:55 -0800 (Thu, 18 Feb 2010) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/browser_render_process_host.cc?r1=39358&r2=39357
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/zygote_host_linux.cc?r1=39358&r2=39357
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/zygote_main_linux.cc?r1=39358&r2=39357
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=39358&r2=39357
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=39358&r2=39357
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/renderer_main_platform_delegate_linux.cc?r1=39358&r2=39357

linux: enable seccomp sandbox by default

This is an experiment.  Hopefully it will flush out problems.
Use --disable-seccomp-sandbox to turn it off.

BUG= 36133 

Review URL: http://codereview.chromium.org/647017
------------------------------------------------------------------------

This failed on a buildbot.

[26995:26995:3534599947653:FATAL:/b/slave/chromium-dbg-linux-
interactive/build/src/chrome/browser/zygote_main_linux.cc(639)]
WARNING! This machine lacks support needed for the Seccomp sandbox.

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Interactive%20Tests%20(dbg)/
builds/8538


Lei, do you know what sort of kernels the bots are running?  This doesn't bode well... :(

This also failed to run the unit_tests binary:

[ RUN      ] RendererMainTest.CreateDestroy
Segmentation fault
Cannot access /proc/self/maps

With the change patched in locally, the unit test passes.  I hope it is related to the 
buildbot lacking seccomp somehow, but how that's happening isn't completely obvious to 
me how that might happen (if we don't have seccomp, how are we failing to access 
/proc/self/maps?).

I'll work with markus to look into the bot issues.

Seccomp doesn't work for me btw. with my gcc 4.4, 32 bit shared build on Fedora 9 but 
I also tried a binary from the buildbot a week or two ago with the same symptoms.

SECCOMP_SANDBOX_DEBUGGING=1 also didn't print anything useful (I haven't looked what 
that is supposed to do yet though).

$ ./out/Release/chrome-wrapper --enable-seccomp-sandbox
[err] evsignal_init: socketpair: Address family not supported by protocol
[err] evsignal_init: socketpair: Address family not supported by protocol

Browser starts up ... complains about renderers not responding and it looks like the 
renderers have died (from ps):

craig    27318 25.0  2.9 310648 91784 pts/4    Sl+  08:18   0:03 
/home/craig/chromium/src/out/Release/chrome --enable-seccomp-sandbox
craig    27355  0.0  1.3  74004 42968 pts/4    S+   08:18   0:00 
/home/craig/chromium/src/out/Release/chrome --enable-seccomp-sandbox
craig    27356  2.3  1.4  75496 45048 pts/4    S+   08:18   0:00 
/home/craig/chromium/src/out/Release/chrome --type=zygote --enable-seccomp-sandbox
craig    27387  0.1  0.0      0     0 pts/4    Z+   08:18   0:00 [chrome] <defunct>
craig    27389  0.3  0.0      0     0 pts/4    Z+   08:18   0:00 [chrome] <defunct>
craig    27409  0.2  0.0      0     0 pts/4    ZN+  08:18   0:00 [chrome] <defunct>
craig    27411  0.3  0.0      0     0 pts/4    ZN+  08:18   0:00 [chrome] <defunct>
...

I haven't poked at it in any more detail yet.

Craig, can you check your kernel config?

% grep -i seccomp /boot/config-2.6.24-26-generic
CONFIG_SECCOMP=y

$ grep -i seccomp /boot/config-2.6.27.25-78.2.56.fc9.i686 
CONFIG_SECCOMP=y
$ uname -r
2.6.27.25-78.2.56.fc9.i686

Evan, to follow up on the bot issue, I looked at the one with the error you sent 
(which should be the same as most other bots), and it does have seccomp enabled, both 
according to /boot/config, and according to a small test program Markus created. Could 
something else be causing the bot (and Craig's) errors?

Yes, there are other reasons why this could fail. If seccomp is enabled in the 
kernel, but the sandbox still doesn't work, that's usually a sign that glibc does 
something strange that we hadn't anticipated yet. There are only so many things that 
glibc can do, so we feel confident that we can eventually catch all these cases. But 
until now we didn't know how many cases we need to deal with.

And turning the sandbox on for more users was prompted exactly by the expectation 
that we will see some failures and hopefully get good bug reports. Most of these bugs 
will be pretty easy to fix, as soon as we can get debugging access to these systems.

The report that this bug his happening on a Fedora machine is very useful. That's 
something I can easily test in QEmu :-) Much easier than messing with the build bots.

If we are lucky, the fix will work for both Fedora and build bots. If not, I'll need 
to do some more debugging on the build bot machines.

(Note that I reverted the above patch because of the failure on the bots.  Once we 
have that worked out, I say we force users to --disable-seccomp-sandbox; it's just 
annoying to fix the bots to pass that while Markus debugs.)

If you do try to reproduce this it might help to know that although my box is 
essentially FC9, I did upgrade glibc as part of getting gcc 4.4 up and running and am 
currently using glibc-2.9.90-10 that I compiled from source. Hopefully the problem 
will show up on something like FC11 though...

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=39839 

------------------------------------------------------------------------
r39839 | markus@chromium.org | 2010-02-23 18:06:06 -0800 (Tue, 23 Feb 2010) | 17 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/sandbox.cc?r1=39839&r2=39838

Be more restrictive when finding file names for libraries that need patching.
This avoids false positives if the directory name matches one of the well-known
library names (e.g. ld).

False positives not only result in a performance hit at startup, because we
are now trying to instrument libraries that don't actually contain any system
calls; but even worse than this, we could try to instrument system calls in
the sandboxing code itself. And those system calls are deliberately coded so
that they will not get rewritten.

Fortunately, none of this is a security problem. If we accidentally rewrite
system calls that weren't supposed to be rewritten, we will just crash on
startup.

TEST=the sandbox now works on the buildbots
BUG= 36133 
Review URL: http://codereview.chromium.org/652188
------------------------------------------------------------------------

FYI, the latest changes haven't fixed the seccomp sandbox for me btw.

Using a r39851 binary from the builders (also reproducible with a local compile), I still see this:

$ ./chrome-wrapper --enable-seccomp-sandbox --user-data-dir=tmp
/home/craig/Desktop/chrome-linux/chrome: /lib/libz.so.1: no version information available (required by /home/craig/Desktop/chrome-linux/chrome)
/home/craig/Desktop/chrome-linux/chrome: /lib/libz.so.1: no version information available (required by /home/craig/Desktop/chrome-linux/chrome)
[err] evsignal_init: socketpair: Address family not supported by protocol

and

$ ps auxwwww | grep chrome
craig     9548  6.1  0.7 187248 24356 pts/3    Sl+  07:46   0:00 /home/craig/Desktop/chrome-linux/chrome --enable-seccomp-sandbox --user-data-dir=tmp
craig     9585  0.0  0.0  55368  2344 pts/3    S+   07:46   0:00 /home/craig/Desktop/chrome-linux/chrome --enable-seccomp-sandbox --user-data-dir=tmp
craig     9586  0.0  0.2  56840  8008 pts/3    S+   07:46   0:00 /home/craig/Desktop/chrome-linux/chrome --type=zygote --enable-seccomp-sandbox
craig     9602  0.0  0.0      0     0 pts/3    Z+   07:46   0:00 [chrome] <defunct>
craig     9664  0.0  0.0   4172   712 pts/5    S+   07:46   0:00 grep chrome

Does anyone have any useful debugging tips for this? I want to put a breakpoint somewhere around evsignal_init to poke at this but it isn't working 
although I arguably haven't spent that much time fighting with it. I've tried this:

./out/Release/chrome-wrapper --enable-seccomp-sandbox  --allow-sandbox-debugging --user-data-dir=tmp --renderer-cmd-prefix='xterm -e gdb --args'

and I've #if 0'ed what appears to be the enabling of seccomp (see below) but the process still exits when it gets SIGTRAP.

What did I miss? I can obviously put printfs all over the place if I can't get the debugger up but I suspect there must be a way to use it.

--- a/sandbox/linux/seccomp/trusted_thread.cc
+++ b/sandbox/linux/seccomp/trusted_thread.cc
@@ -527,12 +527,14 @@ void Sandbox::createTrustedThread(int processFdPub, int cloneFdPub,
       "jz   30\n"
 
       // Release privileges by entering seccomp mode.
+#if 0
       "mov  $157, %%eax\n"         // NR_prctl
       "mov  $22, %%edi\n"          // PR_SET_SECCOMP
       "mov  $1, %%esi\n"
       "syscall\n"
       "test %%rax, %%rax\n"
       "jnz  25b\n"                 // exit process
+#endif
 
       // Back in the newly created sandboxed thread, wait for trusted process
       // to receive request. It is possible for an attacker to make us
@@ -1142,12 +1144,14 @@ void Sandbox::createTrustedThread(int processFdPub, int cloneFdPub,
       "jz   30\n"
 
       // Release privileges by entering seccomp mode.
+#if 0
       "mov  $172, %%eax\n"         // NR_prctl
       "mov  $22, %%ebx\n"          // PR_SET_SECCOMP
       "mov  $1, %%ecx\n"
       "int  $0x80\n"
       "test %%eax, %%eax\n"
       "jnz  25b\n"                 // exit process
+#endif


I'll poke at it a bit more tomorrow...

It is often easier if you try debugging the stand-alone version of the sandbox 
http://code.google.com/p/seccompsandbox/

Setting SECCOMP_SANDBOX_DEBUGGING=1 sometimes helps shed some light on things (this only 
works in debugging builds!).

But the most reliable debugging tool is probably this combination:

make
rm -f strace.log*
SECCOMP_SANDBOX_DEBUGGING=1 strace -s 80 -ff -o strace.log ./testbin32

Reading the log files usually sheds some light on what is going on. But it probably helps to 
be more familiar with the code; so, if you don't think you can make any sense of the logging 
output, feel free to send the logs to me.

The logs don't necessarily pin-point where the problem is, but they often give enough hints 
that I can then suggest where to put debugging statements.

Alternatively, if you can somehow give me shell access to your machine, that would help a 
lot.

I tested on both Fedora 9 and Fedora 12, and other than my initial problems boot strapping 
enough of these systems to test my code, everything works surprisingly well. I can turn on 
the seccomp sandbox in both releases.

Performance is slightly degraded in 32bit mode, but I have a pending patch that just needs 
to be cleaned up a little bit.

Also, Fedora 12 sometimes issues SE Linux warnings. I think I know how to work around this 
problem. So, ignore that for the time being. I necessary, temporarily change SE Linux to 
permissive mode.

Thanks for the debugging hints Markus. I will follow up via email with logs etc.

selinux is disabled for me btw. (I needed that for the chromeos chroot stuff to work 
for me).

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=40900 

------------------------------------------------------------------------
r40900 | markus@chromium.org | 2010-03-08 09:06:40 -0800 (Mon, 08 Mar 2010) | 50 lines
Changed paths:
   A http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/allocator.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/allocator.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/clone.cc?r1=40900&r2=40899
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/library.cc?r1=40900&r2=40899
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/library.h?r1=40900&r2=40899
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/maps.cc?r1=40900&r2=40899
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/maps.h?r1=40900&r2=40899
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/sandbox.cc?r1=40900&r2=40899
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/sandbox_impl.h?r1=40900&r2=40899
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/securemem.h?r1=40900&r2=40899
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/syscall.cc?r1=40900&r2=40899
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/trusted_thread.cc?r1=40900&r2=40899
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/sandbox.gyp?r1=40900&r2=40899

- Add a custom allocator for STL objects. This fixes sandbox failures that
 were observed on some machines (in particular in 32bit mode).

- Some more changes to avoid calling into glibc when we can make a direct
 system call, instead. These particular call sites were unlikely to cause
 any problems. But it makes the code easier to audit if we avoid all
 unnecessary calls into glibc.

- In 64bit mode, gettimeofday() is handled by vsyscalls and tends to be cheap.
 In 32bit mode, it is just a regular system call. Some users rely on being
 able to call gettimeofday() at a very high rate (up to thousands of
 consecutive calls). Recognize this system call pattern and optimize for it.

- Add debugging option that allows us to warn about expensive system calls.
 In many cases, these warnings can then be used to optimize the sandboxed
 application.

- Fix compilation on newer versions of gcc.

- Changed the x86-32 version of the code that we use when intercepting
 system calls. Previously, we would use CALL to jump to the set of
 instructions that we had relocated. But we made the mistake of allowing
 relocation of instructions that reference %esp. This doesn't work, as
 CALL modifies the stack. We now avoid using CALL and instead jump
 directly. On x86-32 that requires the use of a PUSH/RET combination as
 there is no 32bit wide JMP instruction.
 The x86-64 version of the code was already written in a way that would
 avoid this particular problem.
 (I would like to thank Craig Schlenter for his exceptional detective
  work in tracking down the root cause of this bug!)

- For debugging purposes, injected a really small library (less than 4kB)
 and discovered that some of our memory map manipulations implicitly
 relied on mappings to be at least two pages long. Fixed the code that
 made this incorrect assumption.

- For really small libraries, the runtime linker can choose a different
 more compact layout. Our computation of the ASR offset did not know how
 to deal with that. Fixed by explicitly looking for a ".text" segment
 instead of looking for a PT_DYNAMIC section.

- Closed a file descriptor that we kept open longer than needed.

- Removed some unused code.

- Added copyright headers

TEST=tested on i386 and x86-64
BUG= 36133 
Review URL: http://codereview.chromium.org/661438
------------------------------------------------------------------------

Bulk-assigning seccomp bugs to markus so they don't show up unassigned; he 
can dole them out to others.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=43122 

------------------------------------------------------------------------
r43122 | evan@chromium.org | 2010-03-30 12:47:41 -0700 (Tue, 30 Mar 2010) | 12 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=43122&r2=43121
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/browser_render_process_host.cc?r1=43122&r2=43121
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/zygote_host_linux.cc?r1=43122&r2=43121
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/zygote_main_linux.cc?r1=43122&r2=43121
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=43122&r2=43121
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=43122&r2=43121
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/renderer_main_platform_delegate_linux.cc?r1=43122&r2=43121
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/nacl/nacl_test.cc?r1=43122&r2=43121

linux: enable seccomp sandbox by default

It seems the best way to keep the seccomp sandbox working is to have
everyone's development environment have it on by default.  So we turn
on the seccomp sandbox, but only for non-official builds.

If the build-time flag is set: --disable-seccomp-sandbox turns it off.
If the build-time flag is *not* set: --enable-seccomp-sandbox turns it on.

BUG= 36133 

Review URL: http://codereview.chromium.org/1558003
------------------------------------------------------------------------

might be causing http://code.google.com/p/chromium/issues/detail?id=40448

Anything labeled mstone:x by definition is not a blocker for stable.

Hey guys,

Sorry if this is the wrong place to ask, but I was wondering what prompted the "need to eliminate the setuid sandbox." ?

I've been looking into using it in a separate project and would love to know if it is insecure/unusable/etc.

-- Cheers, tav

tav: it's secure, but we don't like it:

* Setting the processes as non-dumpable means that we can't get their memory information
* There's no way to translate PIDs across a PID namespace, so we have to perform an unspeakable hack that I'm not even going to talk about in order to get the PIDs of our renderer processes
* The SUID binary freaks people out
* It breaks utterly for guest accounts that can't run SUID binaries
* We can't adjust the OOM score for sandboxed renderers
* We can't poke holes in the sandbox: it's all or nothing.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=61557

------------------------------------------------------------------------
r61557 | evan@chromium.org | Tue Oct 05 13:52:53 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=61557&r2=61556&pathrev=61557

linux: enable seccomp sandbox by default

Seeing how the bots feel about this again.

BUG= 36133 

Review URL: http://codereview.chromium.org/3539015
------------------------------------------------------------------------

Decided I'm going to trying to push this one over the finish line, even if it means disabling tests.  We need Markus back.

Not blocked on  issue 59376 , but that could be a good way to test this code (it starts a renderer without using the zygote, which should be doable in seccomp land).

We have a workaround for  issue 59423 , so it's no longer blocking this.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=64267

------------------------------------------------------------------------
r64267 | evan@chromium.org | Thu Oct 28 10:29:30 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=64267&r2=64266&pathrev=64267

linux: enable seccomp sandbox by default

Seeing how the bots feel about this again.

BUG= 36133 

Review URL: http://codereview.chromium.org/3539015
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=64306

------------------------------------------------------------------------
r64306 | vangelis@chromium.org | Thu Oct 28 13:40:34 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=64306&r2=64305&pathrev=64306

Revert 64267 - linux: enable seccomp sandbox by default
(Reason for revert: Widespread failures on Linux bots starting with http://build.chromium.org/p/chromium/builders/Linux%20Tests%20(dbg)(2)/builds/729)

Seeing how the bots feel about this again.

BUG= 36133 

Review URL: http://codereview.chromium.org/3539015

TBR=evan@chromium.org
Review URL: http://codereview.chromium.org/4200010
------------------------------------------------------------------------

Any progress in this?

As of today a fully updated Fedora 14 system with:
  google-chrome-stable-10.0.648.204-79063.x86_64

still defaults to seccomp off, however running via 'google-chrome --enable-seccomp-sandbox' appears to result in a fully functional browser.

(and chrome://about/sandbox/ now shows:
Sandbox Status

SUID Sandbox	Yes
  PID namespaces	Yes
  Network namespaces	Yes
Seccomp sandbox	Yes [was No without the flag]
You are adequately sandboxed.)

I'm waiting on Markus to track down one last bug, though it's been long enough that I worry some others have crept in...

Is this finally unblocked?  If not, what is this blocked on?

It's on by default for debug builds (so it no longer regresses) but it's off by default for release builds due to its performance impact.  (For the majority of cases it's only slightly slower but for some of our tests it's 4000% slower.)  I guess it's blocked on someone analyzing that code to see whether we can work around it, and/or kernel work (but that seems to be a dead end: http://lwn.net/Articles/450291/ ).

Hmm, so Linux Plumber's Conference, begins this Tuesday, and I (and a bunch of folks from prod kernel team) happen to be heading up there (Santa Rosa)...

I've always thought a bitmap of can-call this syscall privileges would be very useful (indeed I implemented something like this myself around 10 years ago for a DNS server).  Although it should probably have a little more then just on/off state [I can think of: permit, ignore and return success (for sync for example), fail with syscall not supported, fail with permission denied, terminate process].

Anyway, do we understand the performance regression well enough to be able to say what the blocker is?
Would just being able to call gettimeofday, nanosleep be enough to help tremendously?

Do we have any data on which system calls are the ones which we regularly call that hit the emulation slow path?

Even if we can't get a per-syscall bitmap, maybe we can create a seccomp mode 2, where we open up a couple more critical-path syscalls - just glancing at a syscall list there appear to be quite a few that could be opened up without really (or even at all) decreasing the security of the sandbox - stuff like nanosleep, time, gettimeofday, lseek, gettid/pid, maybe even poll/epoll/futex stuff...

Do you have a description of what exactly you allow in the monitor?

We definitely have a wishlist of items that would make seccomp-style
sandboxing much much easier. We even have a couple of people (cc'd on this
e-mail), who have written some amount of kernel code that could achieve
these goals. We just don't think we have much hope of making headway with
kernel politics:

 - allow white-listing on a per system call basis. It is perfectly OK, if
this is done in a platform-specific way and needs to know calling
conventions and system call numbers for each platform. For a nice-to-have
feature, possibly allow white-listing on a more fine-grained filtering
mechanism, but realistically that's probably even more controversial and
doesn't actually gain us all that much.

 - kernel support for intercepting all system calls that a application
attempts to make and instead sending them to a user-space handler. This
handler lives in the same address space and thread as the application that
made the system call.

 - ability to make a selected number of system calls on behalf of another
process. In particular, manipulating another process' address space would be
incredibly useful. But there are probably a handful of other system calls we
care about; I can try to compile a list, if you think it would make any
difference.

 - don't make seccomp mode auto-disable RDTSC. This is actually a kernel
bug, and Julien might already have succeeded in getting the fix committed.
Haven't checked.

There are lots of other nice-to-have features. But the above would probably
get us very close to what we need and would eliminate a lot of the
complexity and performance penalty from the existing seccomp sandbox code.
It also wouldn't take all that much kernel code -- if only the kernel
developers could agree on accepting patches.


Markus

Here's all the data I have.  It's a plot of our various perf tests for the same revision of Chrome with seccomp on or off.  Our tests each load various pages multiple times, so the dots on the chart correspond to the median load time of a given page for baseline vs seccomp.  If you hover a dot, the data on the right shows the distribution of page load times for that page.
http://www.corp.google.com/~evanm/projects/chrome/datavis/cycler/

Unfortunately, this doesn't answer any of your questions directly.  It would take some digging.  I had hoped this would reveal obvious optimization targets (e.g. in a previous iteration, we discovered that particular international pages got much slower, which revealed a bug in how we loaded font files) but instead it seems to show everything is slower proportionally to its load time, without revealing what in particular causes a problem.

Hmm, while that data is definitely proof that there is a significant performance regression, it is of course pretty much useless in order to try to figure out what the source of it is.

There's no way to get chrome with seccomp enabled to generate a table of times-syscall-was-bounced[SYSCALL#] after chrome shutdown?  I think having that distribution would be exceedingly helpful.

This has been replaced by the seccomp-bpf sandbox, already on by default. People who want what we now call "seccomp-legacy" can still use --enable-seccomp-sandbox.