Closed Bug 985227 Opened 6 years ago Closed 6 years ago

Clean up seccomp-bpf filter definition

Categories

(Core :: Security, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla31

People

(Reporter: jld, Assigned: jld)

References

Details

Attachments

(3 files, 1 obsolete file)

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.
Attachment #8393254 - Flags: review?(gdestuynder)
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.
Attachment #8393254 - Attachment is obsolete: true
Attachment #8393254 - Flags: review?(gdestuynder)
Attachment #8393263 - Flags: review?(gdestuynder)
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
Keywords: checkin-needed
You need to log in before you can comment on or make changes to this bug.