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:
> > On Thu, 2014-06-12 at 14:05 -0700, Greg KH wrote:
> > > On Thu, Jun 12, 2014 at 02:03:23PM -0700, Greg KH wrote:
> > > > On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:
> > > > > On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
> > > > > > 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 <markos.chand...@imgtec.com>
> > > > > 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 <r...@linux-mips.org>
> > > > > 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.)

> > (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.
From: Markos Chandras <markos.chand...@imgtec.com>
Date: Wed, 22 Jan 2014 14:40:00 +0000
Subject: MIPS: asm: thread_info: Add _TIF_SECCOMP flag
Origin: https://git.kernel.org/linus/137f7df8cead00688524c82360930845396b8a21

Add _TIF_SECCOMP flag to _TIF_WORK_SYSCALL_ENTRY to indicate
that the system call needs to be checked against a seccomp filter.

Signed-off-by: Markos Chandras <markos.chand...@imgtec.com>
Reviewed-by: Paul Burton <paul.bur...@imgtec.com>
Reviewed-by: James Hogan <james.ho...@imgtec.com>
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6405/
Signed-off-by: Ralf Baechle <r...@linux-mips.org>
[bwh: Backported to 3.2: various other flags are not included in
 _TIF_WORK_SYSCALL_ENTRY]
Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
--- a/arch/mips/include/asm/thread_info.h
+++ b/arch/mips/include/asm/thread_info.h
@@ -149,7 +149,7 @@ register struct thread_info *__current_t
 #define _TIF_FPUBOUND		(1<<TIF_FPUBOUND)
 #define _TIF_LOAD_WATCH		(1<<TIF_LOAD_WATCH)
 
-#define _TIF_WORK_SYSCALL_ENTRY	(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT)
+#define _TIF_WORK_SYSCALL_ENTRY	(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | _TIF_SECCOMP)
 
 /* work to do in syscall_trace_leave() */
 #define _TIF_WORK_SYSCALL_EXIT	(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT)

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to