In order to ship seccomp on production devices safely, we need to get seccomp enabled on developer devices asap, so that we have a full development cycle using seccomp. Since we are not ready to go to kitkat on Flame yet (where seccomp is enabled already by Qualcomm), we need to investigate a solution for getting seccomp on JellyBean based Flame devices. Ideally I was hoping we could somehow incorporate this in the regular build scripts, but they don't currently build the kernel. (But perhaps they could for Flame?) Or maybe we can just make a bootimage which developers can flash using fastboot. I'm not sure what the easiest/safest route is here. Notes: - If we can make the move to kitkat on flame soon (like next few weeks) we can probably WONTFIX this bug, but from what I hear, this won't be likely. - Seccomp support is already in the tree for Qualcomm's JellyBean based builds, but it requires a flag to be enabled when building the kernel [1] - The priority goal here is to get developers working on master to have seccomp enabled. 1.4 would be nice too (and is seccomp compatible), but not essential. 1.3 is not widely tested with seccomp, but seccomp can be disabled at runtime, so seccomp enabled devices can still be used with 1.3 gecko/gaia. We would probably want to account (see [2]) [1] https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/?id=b393ed0957543 [2] https://wiki.mozilla.org/Security/Sandbox/Seccomp#How_do_I_disable_the_sandbox_temporarily.3F

Just FTR, seccomp is already enabled on all geeksphone builds (with ICS base) and at times we did get crash reports or similar where only GP was affected and in the end traced that to seccomp. We really should have this enabled on Flame so developers see all seccomp issues on their own devices and we test the mechanism well on devices we actually support from our side.

I made a bug about the kernel build/flash process in general, since bug 1000682 looks to be about a specific module.

(In reply to Jed Davis [:jld] from comment #2) > I made a bug about the kernel build/flash process in general, since bug > 1000682 looks to be about a specific module. I actually requested that 1000682 add a full kernel build. I think it's a bit pointless to add just a module.