From: Greg KH <gregkh@linuxfoundation.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, Will Drewry <wad@chromium.org>,
Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 3.5 0/2] seccomp and vsyscall fixes
Date: Thu, 27 Sep 2012 10:36:22 -0700 [thread overview]
Message-ID: <20120927173622.GB21025@kroah.com> (raw)
In-Reply-To: <cover.1342566495.git.luto@amacapital.net>
On Tue, Jul 17, 2012 at 04:19:18PM -0700, Andy Lutomirski wrote:
> Apologies for the lateness of this stuff. I was at a conference last
> week when the Chrome issue was discovered and I couldn't do this
> properly until I got back.
>
> Will, can you confirm that this version is okay and passes your tests?
> It passes mine.
>
> While there are no known seccomp users that will have trouble,
> SECCOMP_RET_TRAP and SECCOMP_RET_TRACE currently interact oddly with
> emulated vsyscalls. This might lead to ABI issues down the road (if
> something starts to rely on current behavior) or unexpected malfunctions
> (if something tries to change, say, sys_gettimeofday, into a different
> syscall and gets completely bogus results on a vsyscall-using distro.
>
> It's unlikely that fixing this later will cause issues, but it would be
> nice to nail down and document the vsyscall quirks for the first
> released kernel with seccomp mode 2 support.
>
> (Patch 2/2 is very much optional. It fixes a strange corner case. It
> ought to be fine for 3.6, since I very much doubt that any real code
> will hit that corner case and cause ABI problems.)
>
> Andy Lutomirski (2):
> seccomp: Make syscall skipping and nr changes more consistent
> seccomp: Future-proof against silly tracers
>
> Documentation/prctl/seccomp_filter.txt | 74 ++++++++++++++++++++--
> arch/x86/include/asm/syscall.h | 11 +++
> arch/x86/kernel/vsyscall_64.c | 110 +++++++++++++++++---------------
> kernel/seccomp.c | 28 +++++++-
> 4 files changed, 163 insertions(+), 60 deletions(-)
What ever happened to these patches? I don't see them in 3.6-rc7, are
they pending for 3.7?
thanks,
greg k-h
next prev parent reply other threads:[~2012-09-27 17:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-17 23:19 Andy Lutomirski
2012-07-17 23:19 ` [PATCH 3.5 1/2] seccomp: Make syscall skipping and nr changes more consistent Andy Lutomirski
2012-07-18 18:31 ` Will Drewry
2012-07-18 20:00 ` Andy Lutomirski
2012-07-26 15:43 ` Andy Lutomirski
2012-07-17 23:19 ` [PATCH 3.5 2/2] seccomp: Future-proof against silly tracers Andy Lutomirski
2012-07-18 2:13 ` Will Drewry
2012-07-18 18:35 ` Will Drewry
2012-07-18 20:08 ` Andy Lutomirski
2012-07-26 15:41 ` Andy Lutomirski
2012-08-02 14:32 ` Will Drewry
2012-08-02 16:54 ` Andy Lutomirski
2012-07-18 2:10 ` [PATCH 3.5 0/2] seccomp and vsyscall fixes Will Drewry
2012-09-27 17:36 ` Greg KH [this message]
2012-09-27 19:40 ` Andy Lutomirski
2012-09-27 20:09 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120927173622.GB21025@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=torvalds@linux-foundation.org \
--cc=wad@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®