* Dave Hansen <dave@xxxxxxxx> wrote: > > There are some minor updates here from last time: > * added a def_bool instead of separate lines in config > * clarified that the /proc interface is *GONE* > > cc'ing a bunch of folks directly now instead of depending > on linux-arch@ to awaken them. I think it's most appropriate > for this to go in via the security tree, but I guess it > could also go directly to Linus. > > -- > > From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> > > There are 7 architecures with "config SECCOMP". They all have > virtually the same help text except for those referencing the > /proc interface. The /proc interface was removed in 2007. > > There is *NOTHING* architecture-specific about SECCOMP except > that the syscalls have per-architecture definitions, like every > other syscall. It is absurd to have the option in the > arch-specific menus. > > Move it to the security menu, consolidate the 7 down to one, and > remove the embarassingly-ancient help text references and > dependencies on /proc. > > Signed-off-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> > Cc: linux-security-module@xxxxxxxxxxxxxxx > Cc: linux-arch@xxxxxxxxxxxxxxx > Cc: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> > Cc: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> > Cc: Russell King <linux@xxxxxxxxxxxxxxxx> > Cc: Michal Simek <monstr@xxxxxxxxx> > Cc: Ralf Baechle <ralf@xxxxxxxxxxxxxx> > Cc: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> > Cc: Paul Mackerras <paulus@xxxxxxxxx> > Cc: Martin Schwidefsky <schwidefsky@xxxxxxxxxx> > Cc: Heiko Carstens <heiko.carstens@xxxxxxxxxx> > Cc: Paul Mundt <lethal@xxxxxxxxxxxx> > Cc: x86@xxxxxxxxxx > Cc: James Morris <james.l.morris@xxxxxxxxxx> > > --- > > b/arch/arm/Kconfig | 15 +-------------- > b/arch/microblaze/Kconfig | 18 +----------------- > b/arch/mips/Kconfig | 18 +----------------- > b/arch/powerpc/Kconfig | 18 +----------------- > b/arch/s390/Kconfig | 18 +----------------- > b/arch/sh/Kconfig | 17 +---------------- > b/arch/sparc/Kconfig | 18 +----------------- > b/arch/x86/Kconfig | 17 +---------------- > --- a/security/Kconfig~consolidate-seccomp-options 2014-01-29 11:02:31.607008738 -0800 > +++ b/security/Kconfig 2014-01-29 11:02:31.616009147 -0800 > @@ -167,5 +167,24 @@ config DEFAULT_SECURITY > default "yama" if DEFAULT_SECURITY_YAMA > default "" if DEFAULT_SECURITY_DAC > > -endmenu > +config HAVE_ARCH_SECCOMP > + bool > + > +config SECCOMP > + def_bool y > + depends on HAVE_ARCH_SECCOMP > + prompt "Enable seccomp to safely compute untrusted bytecode" > + ---help--- > + This kernel feature is useful for number crunching applications > + that may need to compute untrusted bytecode during their > + execution. By using pipes or other transports made available to I'd change and simplify the first sentence to: > + This kernel feature is useful to sandbox runtimes that need > + to execute untrusted machine code. Seccomp isn't primarily about number crunching anymore, and it's definitely not about 'bytecode' in the classical sense either. > + the process as file descriptors supporting the read/write > + syscalls, it's possible to isolate those applications in > + their own address space using seccomp. Once seccomp is > + enabled via prctl(PR_SET_SECCOMP), it cannot be disabled > + and the task is only allowed to execute a few safe syscalls > + defined by each seccomp mode. > > + If unsure, say Y. Only embedded should say N here. > + > +endmenu Other than that: Acked-by: Ingo Molnar <mingo@xxxxxxxxxx> Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
