* [PULL] seccomp update (next)
@ 2015-07-15 18:56 Kees Cook
2015-07-20 6:58 ` James Morris
0 siblings, 1 reply; 20+ messages in thread
From: Kees Cook @ 2015-07-15 18:56 UTC (permalink / raw)
To: James Morris
Cc: linux-security-module, linux-kernel, Andy Lutomirski, Kees Cook,
Oleg Nesterov, Pranith Kumar, Tycho Andersen
Hi,
Please pull these seccomp changes for next.
Thanks!
-Kees
The following changes since commit b3bddffd35a0b77eee89760eb94cafa18dc431f5:
Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into next (2015-06-18 23:28:40 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
for you to fetch changes up to 221272f97ca528048a577a3ff23d7774286ca5fd:
seccomp: swap hard-coded zeros to defined name (2015-07-15 11:52:54 -0700)
----------------------------------------------------------------
Various updates and cleanups for seccomp
----------------------------------------------------------------
Kees Cook (1):
seccomp: swap hard-coded zeros to defined name
Pranith Kumar (1):
seccomp: Replace smp_read_barrier_depends() with lockless_dereference()
Tycho Andersen (1):
seccomp: add ptrace options for suspend/resume
include/linux/ptrace.h | 1 +
include/linux/seccomp.h | 2 +-
include/uapi/linux/ptrace.h | 6 ++++--
kernel/ptrace.c | 13 +++++++++++++
kernel/seccomp.c | 17 ++++++++++++-----
5 files changed, 31 insertions(+), 8 deletions(-)
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2015-07-15 18:56 [PULL] seccomp update (next) Kees Cook
@ 2015-07-20 6:58 ` James Morris
0 siblings, 0 replies; 20+ messages in thread
From: James Morris @ 2015-07-20 6:58 UTC (permalink / raw)
To: Kees Cook
Cc: linux-security-module, linux-kernel, Andy Lutomirski,
Oleg Nesterov, Pranith Kumar, Tycho Andersen
On Wed, 15 Jul 2015, Kees Cook wrote:
> Hi,
>
> Please pull these seccomp changes for next.
>
> Thanks!
>
> -Kees
>
> The following changes since commit b3bddffd35a0b77eee89760eb94cafa18dc431f5:
>
> Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into next (2015-06-18 23:28:40 +1000)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
>
> for you to fetch changes up to 221272f97ca528048a577a3ff23d7774286ca5fd:
>
Pulled.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2016-07-07 17:59 Kees Cook
@ 2016-07-07 23:47 ` James Morris
0 siblings, 0 replies; 20+ messages in thread
From: James Morris @ 2016-07-07 23:47 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-security-module, linux-kernel, Olof Johansson
On Thu, 7 Jul 2016, Kees Cook wrote:
> Hi,
>
> Please pull these seccomp changes for next.
Pulled, thanks.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PULL] seccomp update (next)
@ 2016-07-07 17:59 Kees Cook
2016-07-07 23:47 ` James Morris
0 siblings, 1 reply; 20+ messages in thread
From: Kees Cook @ 2016-07-07 17:59 UTC (permalink / raw)
To: James Morris; +Cc: linux-security-module, linux-kernel, Olof Johansson
Hi,
Please pull these seccomp changes for next.
Thanks!
-Kees
The following changes since commit d011a4d861ce583466a8ae72a0c8e7f51c8cba4e:
Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/selinux into next (2016-07-07 10:15:34 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
for you to fetch changes up to f6041c1d8a0825e41219a0443d365318d238d7b3:
samples/seccomp: Add standalone config option (2016-07-07 10:58:03 -0700)
----------------------------------------------------------------
Seccomp samples building fix
----------------------------------------------------------------
Olof Johansson (1):
samples/seccomp: Add standalone config option
samples/Kconfig | 7 +++++++
samples/seccomp/Makefile | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2016-06-18 10:21 ` Andy Lutomirski
@ 2016-06-19 22:45 ` Andy Lutomirski
0 siblings, 0 replies; 20+ messages in thread
From: Andy Lutomirski @ 2016-06-19 22:45 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-kernel, James Morris, LSM List
On Sat, Jun 18, 2016 at 3:21 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Jun 18, 2016 12:02 AM, "Kees Cook" <keescook@chromium.org> wrote:
>>
>> On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> > On Fri, Jun 17, 2016 at 12:15 AM, James Morris <jmorris@namei.org> wrote:
>> >> On Tue, 14 Jun 2016, Kees Cook wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> Please pull these seccomp changes for next. These have been tested by
>> >>> myself and Andy, and close a long-standing issue with seccomp where tracers
>> >>> could change the syscall out from under seccomp.
>> >>
>> >> Pulled to security -next.
>> >
>> > As a heads up: I think this doesn't quite close the hole on x86. Consider:
>> >
>> > 64-bit task arranges to be traced by a 32-bit task (or presumably a
>> > 64-bit task that calls ptrace via int80).
>> >
>> > Tracer does PTRACE_SYSCALL.
>> >
>> > Tracee does a normal syscall.
>> >
>> > Tracer writes tracee's orig_ax, thus invoking this thing in
>> > arch/x86/kernel/ptrace.c:
>> >
>> > if (syscall_get_nr(child, regs) >= 0)
>> > child->thread.status |= TS_COMPAT;
>> >
>> > Tracer resumes and gets confused.
>> >
>> > I think the right fix is to just delete:
>> >
>> > if (syscall_get_nr(child, regs) >= 0)
>> > child->thread.status |= TS_COMPAT;
>> >
>> > from ptrace.c. The comment above it is garbage, too.
>>
>> I'm perfectly happy to see it removed. I can't make sense of the comment. :)
>>
>> That said, the only confusion I see is pretty minor. The arch is saved
>> before the tracer could force TS_COMPAT, so nothing confused is handed
>> to seccomp (the first time). And the syscall will continue to be
>> looked up on sys_call_table not ia32_sys_call_table.
>
> Hmm, right, but...
>
>>
>> The only thing I see is if the tracer has also added a
>> SECCOMP_RET_TRACE filter, after which the recheck will reload all the
>> seccomp info, including the arch. And at this point, a sensible filter
>> will reject a non-matching architecture.
>>
>
> Yes for some filters, but others might have different logic for
> different arches, at which point there's a minor bypass.
>
>> Maybe I'm missing something more?
>>
>
> You can also use this to do a 64-bit syscall with in_compat_syscall()
> returning true, which could cause issues for audit and maybe some
> ioctl handlers irrespective of this patch series. I'll see about
> getting it fixed in x86/urgent.
Hi Kees and James-
On further consideration:
(a) that TS_COMPAT thing is highly, highly buggy -- much buggier and
more confusing than I thought, and not in the way I thought.
(b) it doesn't interfere with seccomp at all, so fixing it is not at
all a prerequisite for these changes.
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2016-06-18 7:02 ` Kees Cook
@ 2016-06-18 10:21 ` Andy Lutomirski
2016-06-19 22:45 ` Andy Lutomirski
0 siblings, 1 reply; 20+ messages in thread
From: Andy Lutomirski @ 2016-06-18 10:21 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-kernel, James Morris, LSM List
On Jun 18, 2016 12:02 AM, "Kees Cook" <keescook@chromium.org> wrote:
>
> On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> > On Fri, Jun 17, 2016 at 12:15 AM, James Morris <jmorris@namei.org> wrote:
> >> On Tue, 14 Jun 2016, Kees Cook wrote:
> >>
> >>> Hi,
> >>>
> >>> Please pull these seccomp changes for next. These have been tested by
> >>> myself and Andy, and close a long-standing issue with seccomp where tracers
> >>> could change the syscall out from under seccomp.
> >>
> >> Pulled to security -next.
> >
> > As a heads up: I think this doesn't quite close the hole on x86. Consider:
> >
> > 64-bit task arranges to be traced by a 32-bit task (or presumably a
> > 64-bit task that calls ptrace via int80).
> >
> > Tracer does PTRACE_SYSCALL.
> >
> > Tracee does a normal syscall.
> >
> > Tracer writes tracee's orig_ax, thus invoking this thing in
> > arch/x86/kernel/ptrace.c:
> >
> > if (syscall_get_nr(child, regs) >= 0)
> > child->thread.status |= TS_COMPAT;
> >
> > Tracer resumes and gets confused.
> >
> > I think the right fix is to just delete:
> >
> > if (syscall_get_nr(child, regs) >= 0)
> > child->thread.status |= TS_COMPAT;
> >
> > from ptrace.c. The comment above it is garbage, too.
>
> I'm perfectly happy to see it removed. I can't make sense of the comment. :)
>
> That said, the only confusion I see is pretty minor. The arch is saved
> before the tracer could force TS_COMPAT, so nothing confused is handed
> to seccomp (the first time). And the syscall will continue to be
> looked up on sys_call_table not ia32_sys_call_table.
Hmm, right, but...
>
> The only thing I see is if the tracer has also added a
> SECCOMP_RET_TRACE filter, after which the recheck will reload all the
> seccomp info, including the arch. And at this point, a sensible filter
> will reject a non-matching architecture.
>
Yes for some filters, but others might have different logic for
different arches, at which point there's a minor bypass.
> Maybe I'm missing something more?
>
You can also use this to do a 64-bit syscall with in_compat_syscall()
returning true, which could cause issues for audit and maybe some
ioctl handlers irrespective of this patch series. I'll see about
getting it fixed in x86/urgent.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2016-06-17 18:55 ` Andy Lutomirski
@ 2016-06-18 7:02 ` Kees Cook
2016-06-18 10:21 ` Andy Lutomirski
0 siblings, 1 reply; 20+ messages in thread
From: Kees Cook @ 2016-06-18 7:02 UTC (permalink / raw)
To: Andy Lutomirski; +Cc: James Morris, LSM List, linux-kernel, Andy Lutomirski
On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Fri, Jun 17, 2016 at 12:15 AM, James Morris <jmorris@namei.org> wrote:
>> On Tue, 14 Jun 2016, Kees Cook wrote:
>>
>>> Hi,
>>>
>>> Please pull these seccomp changes for next. These have been tested by
>>> myself and Andy, and close a long-standing issue with seccomp where tracers
>>> could change the syscall out from under seccomp.
>>
>> Pulled to security -next.
>
> As a heads up: I think this doesn't quite close the hole on x86. Consider:
>
> 64-bit task arranges to be traced by a 32-bit task (or presumably a
> 64-bit task that calls ptrace via int80).
>
> Tracer does PTRACE_SYSCALL.
>
> Tracee does a normal syscall.
>
> Tracer writes tracee's orig_ax, thus invoking this thing in
> arch/x86/kernel/ptrace.c:
>
> if (syscall_get_nr(child, regs) >= 0)
> child->thread.status |= TS_COMPAT;
>
> Tracer resumes and gets confused.
>
> I think the right fix is to just delete:
>
> if (syscall_get_nr(child, regs) >= 0)
> child->thread.status |= TS_COMPAT;
>
> from ptrace.c. The comment above it is garbage, too.
I'm perfectly happy to see it removed. I can't make sense of the comment. :)
That said, the only confusion I see is pretty minor. The arch is saved
before the tracer could force TS_COMPAT, so nothing confused is handed
to seccomp (the first time). And the syscall will continue to be
looked up on sys_call_table not ia32_sys_call_table.
The only thing I see is if the tracer has also added a
SECCOMP_RET_TRACE filter, after which the recheck will reload all the
seccomp info, including the arch. And at this point, a sensible filter
will reject a non-matching architecture.
Maybe I'm missing something more?
-Kees
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2016-06-17 7:15 ` James Morris
@ 2016-06-17 18:55 ` Andy Lutomirski
2016-06-18 7:02 ` Kees Cook
0 siblings, 1 reply; 20+ messages in thread
From: Andy Lutomirski @ 2016-06-17 18:55 UTC (permalink / raw)
To: James Morris; +Cc: Kees Cook, LSM List, linux-kernel, Andy Lutomirski
On Fri, Jun 17, 2016 at 12:15 AM, James Morris <jmorris@namei.org> wrote:
> On Tue, 14 Jun 2016, Kees Cook wrote:
>
>> Hi,
>>
>> Please pull these seccomp changes for next. These have been tested by
>> myself and Andy, and close a long-standing issue with seccomp where tracers
>> could change the syscall out from under seccomp.
>
> Pulled to security -next.
As a heads up: I think this doesn't quite close the hole on x86. Consider:
64-bit task arranges to be traced by a 32-bit task (or presumably a
64-bit task that calls ptrace via int80).
Tracer does PTRACE_SYSCALL.
Tracee does a normal syscall.
Tracer writes tracee's orig_ax, thus invoking this thing in
arch/x86/kernel/ptrace.c:
if (syscall_get_nr(child, regs) >= 0)
child->thread.status |= TS_COMPAT;
Tracer resumes and gets confused.
I think the right fix is to just delete:
if (syscall_get_nr(child, regs) >= 0)
child->thread.status |= TS_COMPAT;
from ptrace.c. The comment above it is garbage, too.
--Andy
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2016-06-14 17:57 Kees Cook
@ 2016-06-17 7:15 ` James Morris
2016-06-17 18:55 ` Andy Lutomirski
0 siblings, 1 reply; 20+ messages in thread
From: James Morris @ 2016-06-17 7:15 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-security-module, linux-kernel, Andy Lutomirski
On Tue, 14 Jun 2016, Kees Cook wrote:
> Hi,
>
> Please pull these seccomp changes for next. These have been tested by
> myself and Andy, and close a long-standing issue with seccomp where tracers
> could change the syscall out from under seccomp.
Pulled to security -next.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PULL] seccomp update (next)
@ 2016-06-14 17:57 Kees Cook
2016-06-17 7:15 ` James Morris
0 siblings, 1 reply; 20+ messages in thread
From: Kees Cook @ 2016-06-14 17:57 UTC (permalink / raw)
To: James Morris
Cc: linux-security-module, linux-kernel, Andy Lutomirski, Kees Cook
Hi,
Please pull these seccomp changes for next. These have been tested by
myself and Andy, and close a long-standing issue with seccomp where tracers
could change the syscall out from under seccomp.
Thanks!
-Kees
The following changes since commit 40d273782ff16fe1a7445cc05c66a447dfea3433:
security: tomoyo: simplify the gc kthread creation (2016-06-06 20:23:55 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
for you to fetch changes up to 26703c636c1f3272b39bd0f6d04d2e970984f1b6:
um/ptrace: run seccomp after ptrace (2016-06-14 10:54:47 -0700)
----------------------------------------------------------------
Fix seccomp vs ptrace ordering to plug syscall filter bypass issue.
----------------------------------------------------------------
Andy Lutomirski (2):
seccomp: Add a seccomp_data parameter secure_computing()
x86/entry: Get rid of two-phase syscall entry work
Kees Cook (12):
seccomp: add tests for ptrace hole
seccomp: remove 2-phase API
seccomp: recheck the syscall after RET_TRACE
x86/ptrace: run seccomp after ptrace
arm/ptrace: run seccomp after ptrace
arm64/ptrace: run seccomp after ptrace
MIPS/ptrace: run seccomp after ptrace
parisc/ptrace: run seccomp after ptrace
s390/ptrace: run seccomp after ptrace
powerpc/ptrace: run seccomp after ptrace
tile/ptrace: run seccomp after ptrace
um/ptrace: run seccomp after ptrace
arch/arm/kernel/ptrace.c | 13 +-
arch/arm64/kernel/ptrace.c | 8 +-
arch/mips/kernel/ptrace.c | 9 +-
arch/parisc/kernel/ptrace.c | 9 +-
arch/powerpc/kernel/ptrace.c | 46 +++----
arch/s390/kernel/ptrace.c | 21 ++-
arch/tile/kernel/ptrace.c | 11 +-
arch/um/kernel/skas/syscall.c | 9 +-
arch/x86/entry/common.c | 106 +++-------------
arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
arch/x86/include/asm/ptrace.h | 6 -
include/linux/seccomp.h | 14 +-
kernel/seccomp.c | 144 ++++++++-------------
tools/testing/selftests/seccomp/seccomp_bpf.c | 176 ++++++++++++++++++++++++--
14 files changed, 309 insertions(+), 265 deletions(-)
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PULL] seccomp update (next)
@ 2016-01-05 23:40 Kees Cook
0 siblings, 0 replies; 20+ messages in thread
From: Kees Cook @ 2016-01-05 23:40 UTC (permalink / raw)
To: James Morris
Cc: linux-security-module, linux-kernel, Jann Horn, Andy Lutomirski
Hi,
Please pull these seccomp changes for next.
Thanks!
-Kees
The following changes since commit aa98b942cbf305cf2abe5dc3aff11f579c7d7fdc:
Merge branch 'smack-for-4.5' of https://github.com/cschaufler/smack-next into next (2015-12-26 16:11:13 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
for you to fetch changes up to d96c17fcc58f8a486fea74d6f96a4a9407109d97:
seccomp: always propagate NO_NEW_PRIVS on tsync (2016-01-05 15:35:41 -0800)
----------------------------------------------------------------
Fix NNP when already under root-created filter
----------------------------------------------------------------
Jann Horn (1):
seccomp: always propagate NO_NEW_PRIVS on tsync
kernel/seccomp.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2014-12-01 23:06 ` Kees Cook
@ 2014-12-02 7:56 ` James Morris
0 siblings, 0 replies; 20+ messages in thread
From: James Morris @ 2014-12-02 7:56 UTC (permalink / raw)
To: Kees Cook; +Cc: Stephen Rothwell, linux-security-module, LKML, Pranith Kumar
On Mon, 1 Dec 2014, Kees Cook wrote:
> On Mon, Dec 1, 2014 at 2:56 PM, James Morris <jmorris@namei.org> wrote:
> > On Mon, 1 Dec 2014, Kees Cook wrote:
> >
> >> On Thu, Nov 27, 2014 at 3:37 PM, James Morris <jmorris@namei.org> wrote:
> >> > On Wed, 26 Nov 2014, Kees Cook wrote:
> >> >
> >> >> > That would be because your tree is based on v3.17 and Kees' is based on
> >> >> > v3.18-rc6 ...
> >> >>
> >> >> James, I can base on whatever you like. I can do v3.17, or even
> >> >> against your security-next. It seems everyone uses something
> >> >> different. :)
> >> >
> >> > It's best to track my next branch as your upstream.
> >>
> >> It'll trigger collisions with what's the x86 -next from luto's
> >> changes. Should I just let Stephen sort that out?
> >
> > Yep.
>
> Hm, it depends on 54ef6df3f3f1353d99c80c437259d317b2cd1cbd, so basing
> against security-next would make the tree unbuildable. Perhaps I
> should just wait for -rc1 to land first?
Yep, that will work.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2014-12-01 22:56 ` James Morris
@ 2014-12-01 23:06 ` Kees Cook
2014-12-02 7:56 ` James Morris
0 siblings, 1 reply; 20+ messages in thread
From: Kees Cook @ 2014-12-01 23:06 UTC (permalink / raw)
To: James Morris; +Cc: Stephen Rothwell, linux-security-module, LKML, Pranith Kumar
On Mon, Dec 1, 2014 at 2:56 PM, James Morris <jmorris@namei.org> wrote:
> On Mon, 1 Dec 2014, Kees Cook wrote:
>
>> On Thu, Nov 27, 2014 at 3:37 PM, James Morris <jmorris@namei.org> wrote:
>> > On Wed, 26 Nov 2014, Kees Cook wrote:
>> >
>> >> > That would be because your tree is based on v3.17 and Kees' is based on
>> >> > v3.18-rc6 ...
>> >>
>> >> James, I can base on whatever you like. I can do v3.17, or even
>> >> against your security-next. It seems everyone uses something
>> >> different. :)
>> >
>> > It's best to track my next branch as your upstream.
>>
>> It'll trigger collisions with what's the x86 -next from luto's
>> changes. Should I just let Stephen sort that out?
>
> Yep.
Hm, it depends on 54ef6df3f3f1353d99c80c437259d317b2cd1cbd, so basing
against security-next would make the tree unbuildable. Perhaps I
should just wait for -rc1 to land first?
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2014-12-01 20:34 ` Kees Cook
@ 2014-12-01 22:56 ` James Morris
2014-12-01 23:06 ` Kees Cook
0 siblings, 1 reply; 20+ messages in thread
From: James Morris @ 2014-12-01 22:56 UTC (permalink / raw)
To: Kees Cook; +Cc: Stephen Rothwell, linux-security-module, LKML, Pranith Kumar
On Mon, 1 Dec 2014, Kees Cook wrote:
> On Thu, Nov 27, 2014 at 3:37 PM, James Morris <jmorris@namei.org> wrote:
> > On Wed, 26 Nov 2014, Kees Cook wrote:
> >
> >> > That would be because your tree is based on v3.17 and Kees' is based on
> >> > v3.18-rc6 ...
> >>
> >> James, I can base on whatever you like. I can do v3.17, or even
> >> against your security-next. It seems everyone uses something
> >> different. :)
> >
> > It's best to track my next branch as your upstream.
>
> It'll trigger collisions with what's the x86 -next from luto's
> changes. Should I just let Stephen sort that out?
Yep.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2014-11-27 23:37 ` James Morris
@ 2014-12-01 20:34 ` Kees Cook
2014-12-01 22:56 ` James Morris
0 siblings, 1 reply; 20+ messages in thread
From: Kees Cook @ 2014-12-01 20:34 UTC (permalink / raw)
To: James Morris; +Cc: Stephen Rothwell, linux-security-module, LKML, Pranith Kumar
On Thu, Nov 27, 2014 at 3:37 PM, James Morris <jmorris@namei.org> wrote:
> On Wed, 26 Nov 2014, Kees Cook wrote:
>
>> > That would be because your tree is based on v3.17 and Kees' is based on
>> > v3.18-rc6 ...
>>
>> James, I can base on whatever you like. I can do v3.17, or even
>> against your security-next. It seems everyone uses something
>> different. :)
>
> It's best to track my next branch as your upstream.
It'll trigger collisions with what's the x86 -next from luto's
changes. Should I just let Stephen sort that out?
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2014-11-26 21:59 ` Kees Cook
@ 2014-11-27 23:37 ` James Morris
2014-12-01 20:34 ` Kees Cook
0 siblings, 1 reply; 20+ messages in thread
From: James Morris @ 2014-11-27 23:37 UTC (permalink / raw)
To: Kees Cook; +Cc: Stephen Rothwell, linux-security-module, LKML, Pranith Kumar
On Wed, 26 Nov 2014, Kees Cook wrote:
> > That would be because your tree is based on v3.17 and Kees' is based on
> > v3.18-rc6 ...
>
> James, I can base on whatever you like. I can do v3.17, or even
> against your security-next. It seems everyone uses something
> different. :)
It's best to track my next branch as your upstream.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2014-11-26 21:46 ` Stephen Rothwell
@ 2014-11-26 21:59 ` Kees Cook
2014-11-27 23:37 ` James Morris
0 siblings, 1 reply; 20+ messages in thread
From: Kees Cook @ 2014-11-26 21:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: James Morris, linux-security-module, LKML, Pranith Kumar
On Wed, Nov 26, 2014 at 1:46 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi James,
>
> On Thu, 27 Nov 2014 00:23:06 +1100 (AEDT) James Morris <jmorris@namei.org> wrote:
>>
>> On Tue, 25 Nov 2014, Kees Cook wrote:
>>
>> > Please pull these seccomp changes for next.
>> >
>> > Thanks!
>> >
>> > -Kees
>> >
>> > The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:
>> >
>> > Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)
>> >
>> > are available in the git repository at:
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
>> >
>> > for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:
>> >
>> > seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)
>> >
>> > ----------------------------------------------------------------
>> > Improves SMP dereferencing with new macro.
>> >
>> > ----------------------------------------------------------------
>> > Pranith Kumar (1):
>> > seccomp: Replace smp_read_barrier_depends() with lockless_dereference()
>> >
>> > kernel/seccomp.c | 7 +++----
>> > 1 file changed, 3 insertions(+), 4 deletions(-)
>> >
>>
>> This is what I get when pulling to my next branch:
>>
>> 9128 files changed, 468773 insertions(+), 340317 deletions(-)
>
> That would be because your tree is based on v3.17 and Kees' is based on
> v3.18-rc6 ...
James, I can base on whatever you like. I can do v3.17, or even
against your security-next. It seems everyone uses something
different. :)
Thanks!
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2014-11-26 13:23 ` James Morris
@ 2014-11-26 21:46 ` Stephen Rothwell
2014-11-26 21:59 ` Kees Cook
0 siblings, 1 reply; 20+ messages in thread
From: Stephen Rothwell @ 2014-11-26 21:46 UTC (permalink / raw)
To: James Morris
Cc: Kees Cook, linux-security-module, linux-kernel, Pranith Kumar
[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]
Hi James,
On Thu, 27 Nov 2014 00:23:06 +1100 (AEDT) James Morris <jmorris@namei.org> wrote:
>
> On Tue, 25 Nov 2014, Kees Cook wrote:
>
> > Please pull these seccomp changes for next.
> >
> > Thanks!
> >
> > -Kees
> >
> > The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:
> >
> > Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
> >
> > for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:
> >
> > seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)
> >
> > ----------------------------------------------------------------
> > Improves SMP dereferencing with new macro.
> >
> > ----------------------------------------------------------------
> > Pranith Kumar (1):
> > seccomp: Replace smp_read_barrier_depends() with lockless_dereference()
> >
> > kernel/seccomp.c | 7 +++----
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
>
> This is what I get when pulling to my next branch:
>
> 9128 files changed, 468773 insertions(+), 340317 deletions(-)
That would be because your tree is based on v3.17 and Kees' is based on
v3.18-rc6 ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL] seccomp update (next)
2014-11-25 19:43 Kees Cook
@ 2014-11-26 13:23 ` James Morris
2014-11-26 21:46 ` Stephen Rothwell
0 siblings, 1 reply; 20+ messages in thread
From: James Morris @ 2014-11-26 13:23 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-security-module, linux-kernel, Pranith Kumar
On Tue, 25 Nov 2014, Kees Cook wrote:
> Hi,
>
> Please pull these seccomp changes for next.
>
> Thanks!
>
> -Kees
>
> The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:
>
> Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
>
> for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:
>
> seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)
>
> ----------------------------------------------------------------
> Improves SMP dereferencing with new macro.
>
> ----------------------------------------------------------------
> Pranith Kumar (1):
> seccomp: Replace smp_read_barrier_depends() with lockless_dereference()
>
> kernel/seccomp.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
This is what I get when pulling to my next branch:
9128 files changed, 468773 insertions(+), 340317 deletions(-)
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PULL] seccomp update (next)
@ 2014-11-25 19:43 Kees Cook
2014-11-26 13:23 ` James Morris
0 siblings, 1 reply; 20+ messages in thread
From: Kees Cook @ 2014-11-25 19:43 UTC (permalink / raw)
To: James Morris; +Cc: linux-security-module, linux-kernel, Pranith Kumar
Hi,
Please pull these seccomp changes for next.
Thanks!
-Kees
The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:
Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:
seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)
----------------------------------------------------------------
Improves SMP dereferencing with new macro.
----------------------------------------------------------------
Pranith Kumar (1):
seccomp: Replace smp_read_barrier_depends() with lockless_dereference()
kernel/seccomp.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2016-07-07 23:47 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-15 18:56 [PULL] seccomp update (next) Kees Cook
2015-07-20 6:58 ` James Morris
-- strict thread matches above, loose matches on Subject: below --
2016-07-07 17:59 Kees Cook
2016-07-07 23:47 ` James Morris
2016-06-14 17:57 Kees Cook
2016-06-17 7:15 ` James Morris
2016-06-17 18:55 ` Andy Lutomirski
2016-06-18 7:02 ` Kees Cook
2016-06-18 10:21 ` Andy Lutomirski
2016-06-19 22:45 ` Andy Lutomirski
2016-01-05 23:40 Kees Cook
2014-11-25 19:43 Kees Cook
2014-11-26 13:23 ` James Morris
2014-11-26 21:46 ` Stephen Rothwell
2014-11-26 21:59 ` Kees Cook
2014-11-27 23:37 ` James Morris
2014-12-01 20:34 ` Kees Cook
2014-12-01 22:56 ` James Morris
2014-12-01 23:06 ` Kees Cook
2014-12-02 7:56 ` James Morris
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).