The seccomp-bpf filter is a bit suboptimal for maintainability at the moment: lots of "if arm, then … else if x86 then … else if x86_64 then …" blocks and repetition, the pieces broken out into "high"/"med"/"low", and so on. This seems to be largely a side-effect of defining the entire thing as a macro in a .h file, which will be going away with bug 920372 in any case.

Let's try this with the big copy from seccomp_filter.h to SandboxFilter.cpp handled as a rename, instead of an unrelated delete+create. It should be easier to review that way. I'll mark this as a rename when committing, if Hg can handle that and there isn't some other reason not to.

its a nice start, although i'd like to get an even clearer notation if possible. I'm not sure how possible that is with macros though.. I suppose that having a shorter whitelist goes a long way to making it easier to read anyway. worst case, we could have a different file per architecture and/or platform, i guess.

Checkin stuff: The patches must be applied in order (p0, p1, p2). Note that the first patch contains a rename, but hg qimport seems to have handled it correctly without doing anything special. Trying: https://tbpl.mozilla.org/?tree=Try&rev=9e0f27e14f43

https://hg.mozilla.org/integration/mozilla-inbound/rev/1e4e7d7e184b https://hg.mozilla.org/integration/mozilla-inbound/rev/679ac1f215d8 https://hg.mozilla.org/integration/mozilla-inbound/rev/d380f713c721

https://hg.mozilla.org/mozilla-central/rev/1e4e7d7e184b https://hg.mozilla.org/mozilla-central/rev/679ac1f215d8 https://hg.mozilla.org/mozilla-central/rev/d380f713c721