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.chandras@xxxxxxxxxx> > > > > 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 <ralf@xxxxxxxxxxxxxx> > > > > 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? > (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? :) thanks, greg k-h
