diff mbox

[v9,11/13] powerpc: select HAVE_SECCOMP_FILTER and provide seccomp_execve

Message ID 1308875813-20122-11-git-send-email-wad@chromium.org (mailing list archive)
State Not Applicable
Headers show

Commit Message

Will Drewry June 24, 2011, 12:36 a.m. UTC
Facilitate the use of CONFIG_SECCOMP_FILTER by wrapping compatibility
system call numbering for execve and selecting HAVE_SECCOMP_FILTER.

v9: rebase on to bccaeafd7c117acee36e90d37c7e05c19be9e7bf

Signed-off-by: Will Drewry <wad@chromium.org>
---
 arch/powerpc/Kconfig               |    1 +
 arch/powerpc/include/asm/seccomp.h |    2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

Comments

Benjamin Herrenschmidt Aug. 30, 2011, 5:28 a.m. UTC | #1
On Thu, 2011-06-23 at 19:36 -0500, Will Drewry wrote:
> Facilitate the use of CONFIG_SECCOMP_FILTER by wrapping compatibility
> system call numbering for execve and selecting HAVE_SECCOMP_FILTER.
> 
> v9: rebase on to bccaeafd7c117acee36e90d37c7e05c19be9e7bf
> 
> Signed-off-by: Will Drewry <wad@chromium.org>

Seen these around for a while ... :-)

I don't see a harm in the patches per-se tho I haven't reviewed the
actual seccomp filter stuff and it's good (or bad) behaviour on ppc.

Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Cheers,
Ben.

> ---
>  arch/powerpc/Kconfig               |    1 +
>  arch/powerpc/include/asm/seccomp.h |    2 ++
>  2 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 2729c66..030d392 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -129,6 +129,7 @@ config PPC
>  	select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
>  	select HAVE_GENERIC_HARDIRQS
>  	select HAVE_SPARSE_IRQ
> +	select HAVE_SECCOMP_FILTER
>  	select IRQ_PER_CPU
>  	select GENERIC_IRQ_SHOW
>  	select GENERIC_IRQ_SHOW_LEVEL
> diff --git a/arch/powerpc/include/asm/seccomp.h b/arch/powerpc/include/asm/seccomp.h
> index 00c1d91..3cb9cc1 100644
> --- a/arch/powerpc/include/asm/seccomp.h
> +++ b/arch/powerpc/include/asm/seccomp.h
> @@ -7,10 +7,12 @@
>  #define __NR_seccomp_write __NR_write
>  #define __NR_seccomp_exit __NR_exit
>  #define __NR_seccomp_sigreturn __NR_rt_sigreturn
> +#define __NR_seccomp_execve __NR_execve
>  
>  #define __NR_seccomp_read_32 __NR_read
>  #define __NR_seccomp_write_32 __NR_write
>  #define __NR_seccomp_exit_32 __NR_exit
>  #define __NR_seccomp_sigreturn_32 __NR_sigreturn
> +#define __NR_seccomp_execve_32 __NR_execve
>  
>  #endif	/* _ASM_POWERPC_SECCOMP_H */
Benjamin Herrenschmidt Nov. 28, 2011, 12:14 a.m. UTC | #2
On Tue, 2011-08-30 at 15:28 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2011-06-23 at 19:36 -0500, Will Drewry wrote:
> > Facilitate the use of CONFIG_SECCOMP_FILTER by wrapping compatibility
> > system call numbering for execve and selecting HAVE_SECCOMP_FILTER.
> > 
> > v9: rebase on to bccaeafd7c117acee36e90d37c7e05c19be9e7bf
> > 
> > Signed-off-by: Will Drewry <wad@chromium.org>
> 
> Seen these around for a while ... :-)
> 
> I don't see a harm in the patches per-se tho I haven't reviewed the
> actual seccomp filter stuff and it's good (or bad) behaviour on ppc.

Did that stuff every got anywhere ? I don't see HAVE_SECCOMP_FILTER
upsteam ... should I just drop the powerpc patch from patchwork ?

Cheers,
Ben.
Will Drewry Nov. 28, 2011, 1:45 a.m. UTC | #3
On Sun, Nov 27, 2011 at 6:14 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2011-08-30 at 15:28 +1000, Benjamin Herrenschmidt wrote:
>> On Thu, 2011-06-23 at 19:36 -0500, Will Drewry wrote:
>> > Facilitate the use of CONFIG_SECCOMP_FILTER by wrapping compatibility
>> > system call numbering for execve and selecting HAVE_SECCOMP_FILTER.
>> >
>> > v9: rebase on to bccaeafd7c117acee36e90d37c7e05c19be9e7bf
>> >
>> > Signed-off-by: Will Drewry <wad@chromium.org>
>>
>> Seen these around for a while ... :-)
>>
>> I don't see a harm in the patches per-se tho I haven't reviewed the
>> actual seccomp filter stuff and it's good (or bad) behaviour on ppc.
>
> Did that stuff every got anywhere ? I don't see HAVE_SECCOMP_FILTER
> upsteam ... should I just drop the powerpc patch from patchwork ?

Thanks for following up! At present, it stalled out, so I think it'd
make sense to just drop it.  I will repost the series soon-ish and see
if any progress can be made.  [I've explored a number of alternative
approaches and still think something along the seccomp_filter lines is
still rational.]

cheers!
will
diff mbox

Patch

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2729c66..030d392 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -129,6 +129,7 @@  config PPC
 	select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
 	select HAVE_GENERIC_HARDIRQS
 	select HAVE_SPARSE_IRQ
+	select HAVE_SECCOMP_FILTER
 	select IRQ_PER_CPU
 	select GENERIC_IRQ_SHOW
 	select GENERIC_IRQ_SHOW_LEVEL
diff --git a/arch/powerpc/include/asm/seccomp.h b/arch/powerpc/include/asm/seccomp.h
index 00c1d91..3cb9cc1 100644
--- a/arch/powerpc/include/asm/seccomp.h
+++ b/arch/powerpc/include/asm/seccomp.h
@@ -7,10 +7,12 @@ 
 #define __NR_seccomp_write __NR_write
 #define __NR_seccomp_exit __NR_exit
 #define __NR_seccomp_sigreturn __NR_rt_sigreturn
+#define __NR_seccomp_execve __NR_execve
 
 #define __NR_seccomp_read_32 __NR_read
 #define __NR_seccomp_write_32 __NR_write
 #define __NR_seccomp_exit_32 __NR_exit
 #define __NR_seccomp_sigreturn_32 __NR_sigreturn
+#define __NR_seccomp_execve_32 __NR_execve
 
 #endif	/* _ASM_POWERPC_SECCOMP_H */