[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABqD9haSh=Tof9n2m8PHBaoqac1kcUZq-f5BcjDBv++5APGTCg@mail.gmail.com>
Date: Tue, 22 May 2012 15:48:40 -0500
From: Will Drewry <wad@...omium.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Al Viro <viro@...iv.linux.org.uk>, Indan Zupancic <indan@....nu>,
Roland McGrath <mcgrathr@...gle.com>, Eric Paris <netdev@...isplace.org>,
linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org,
kernel-hardening@...ts.openwall.com, mingo@...hat.com, oleg@...hat.com,
peterz@...radead.org, rdunlap@...otime.net, tglx@...utronix.de, luto@....edu,
eparis@...hat.com, serge.hallyn@...onical.com, pmoore@...hat.com,
akpm@...ux-foundation.org, corbet@....net, eric.dumazet@...il.com,
markus@...omium.org, coreyb@...ux.vnet.ibm.com, keescook@...omium.org
Subject: Re: seccomp and ptrace. what is the correct order?
On Tue, May 22, 2012 at 3:34 PM, H. Peter Anvin <hpa@...or.com> wrote:
> The proposed patch seems to duplicate the functionality in
> <asm/syscall.h>. Those macros also try to do the right thing in the
> presence of compat.
That was my first thought too, so I ran a few simple tests. gcc isn't
smart enough to not add ~344 bytes of code to get the number and
arguments for the x86/kernel/ptrace.c case I included (in the
naive-est of integrations). But I don't know that it justifies the
extra patchwork or enforcing shared code across arches.
Regardless, the syscall entry + trace code can use some attention
across the architectures. I don't know that
one-more-layer-of-abstraction is the right answer (rather than just
fixing the code). The biggest benefit would be having one-true
syscall_trace_entry slow path. That said, the fast paths will be
forever divergent so the opportunity for bugs like the ones pointed
out will still be there.
cheers!
will
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
