On Thu, 2014-06-12 at 14:59 -0700, Greg KH wrote:

On Thu, Jun 12, 2014 at 10:10:59PM +0100, Ben Hutchings wrote:

quoted

On Thu, 2014-06-12 at 14:05 -0700, Greg KH wrote:

quoted

On Thu, Jun 12, 2014 at 02:03:23PM -0700, Greg KH wrote:

quoted

On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:

quoted

On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:

quoted

Control: tag -1 security upstream patch moreinfo
Control: severity -1 grave
Control: found -1 3.14.5-1

Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:

commit 137f7df8cead00688524c82360930845396b8a21
Author: Markos Chandras [off-list ref]
Date:   Wed Jan 22 14:40:00 2014 +0000

    MIPS: asm: thread_info: Add _TIF_SECCOMP flag

It looks like this can be cherry-picked cleanly onto stable branches for
3.13 and 3.14.  For 3.11 and 3.12, it will need trivial adjustment.

For branches older than 3.11, this needs to be cherry-picked first:

commit e7f3b48af7be9f8007a224663a5b91340626fed5
Author: Ralf Baechle [off-list ref]
Date:   Wed May 29 01:02:18 2013 +0200

    MIPS: Cleanup flags in syscall flags handlers.

It also needs parts of 1d7bf993e0731b4ac790667c196b2a2d787f95c3 (MIPS:
ftrace: Add support for syscall tracepoints.) to apply properly to stuff
older than 3.11.  But, I'm not so sure that is good to apply as that is
a whole new feature.

So I think I'll just do this "by hand" to get it to work properly...

Wait, no, SECCOMP for MIPS isn't even in 3.10 or older kernels, so why
is this a 3.2 issue?  Did you add it there to your kernel for some
reason?

Seccomp mode 2 (i.e. filtering with BPF) was only just implenented for
MIPS in 3.15.  Mode 1 (fixed set of syscalls) was implemented long ago.

Really?  I don't see _TIF_SECCOMP in the mips asm files in 3.10.  I
don't feel comfortable backporting it to 3.10 or 3.4, are you going to
do that for 3.2?

I'm attaching the backport to 3.2 which I've now been able to test.  It
appears to apply cleanly to 3.4 and 3.10 as well.  ("MIPS: Cleanup flags
in syscall flags handlers." applies to all branches with some fuzz.)

quoted

(If prctl(PR_SET_SECCOMP) could return success when CONFIG_SECCOMP is
not enabled, that would be even worse!)

True, but this seems to have always been broken, right?  :)

Yes, so far as I can see.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.