Re: [PULL] seccomp update (next)

[James Morris]

On Thu, 7 Jul 2016, Kees Cook wrote:

> Hi,
> 
> Please pull these seccomp changes for next.

Pulled, thanks.

-- 
James Morris

Re: [PULL] seccomp update (next)

[James Morris]

On Thu, 7 Jul 2016, Kees Cook wrote:

> Hi,
> 
> Please pull these seccomp changes for next.

Pulled, thanks.

-- 
James Morris

Re: [PULL] seccomp update (next)

[Andy Lutomirski]

On Sat, Jun 18, 2016 at 3:21 AM, Andy Lutomirski  wrote:
> On Jun 18, 2016 12:02 AM, "Kees Cook"  wrote:
>>
>> On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski  
>> wrote:
>> > On Fri, Jun 17, 2016 at 12:15 AM, James Morris  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

Re: [PULL] seccomp update (next)

[Andy Lutomirski]

On Sat, Jun 18, 2016 at 3:21 AM, Andy Lutomirski  wrote:
> On Jun 18, 2016 12:02 AM, "Kees Cook"  wrote:
>>
>> On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski  
>> wrote:
>> > On Fri, Jun 17, 2016 at 12:15 AM, James Morris  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

Re: [PULL] seccomp update (next)

[Andy Lutomirski]

On Jun 18, 2016 12:02 AM, "Kees Cook"  wrote:
>
> On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski  wrote:
> > On Fri, Jun 17, 2016 at 12:15 AM, James Morris  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.

Re: [PULL] seccomp update (next)

[Andy Lutomirski]

On Jun 18, 2016 12:02 AM, "Kees Cook"  wrote:
>
> On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski  wrote:
> > On Fri, Jun 17, 2016 at 12:15 AM, James Morris  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.

Re: [PULL] seccomp update (next)

[Kees Cook]

On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski  wrote:
> On Fri, Jun 17, 2016 at 12:15 AM, James Morris  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

Re: [PULL] seccomp update (next)

[Kees Cook]

On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski  wrote:
> On Fri, Jun 17, 2016 at 12:15 AM, James Morris  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

Re: [PULL] seccomp update (next)

[Andy Lutomirski]

On Fri, Jun 17, 2016 at 12:15 AM, James Morris  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

Re: [PULL] seccomp update (next)

[Andy Lutomirski]

On Fri, Jun 17, 2016 at 12:15 AM, James Morris  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

Re: [PULL] seccomp update (next)

[James Morris]

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

Re: [PULL] seccomp update (next)

[James Morris]

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

Re: [PULL] seccomp update (next)

[James Morris]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[James Morris]

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
jmor...@namei.org

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[James Morris]

On Mon, 1 Dec 2014, Kees Cook wrote:

> On Mon, Dec 1, 2014 at 2:56 PM, James Morris  wrote:
> > On Mon, 1 Dec 2014, Kees Cook wrote:
> >
> >> On Thu, Nov 27, 2014 at 3:37 PM, James Morris  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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[Kees Cook]

On Mon, Dec 1, 2014 at 2:56 PM, James Morris  wrote:
> On Mon, 1 Dec 2014, Kees Cook wrote:
>
>> On Thu, Nov 27, 2014 at 3:37 PM, James Morris  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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[James Morris]

On Mon, 1 Dec 2014, Kees Cook wrote:

> On Thu, Nov 27, 2014 at 3:37 PM, James Morris  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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[Kees Cook]

On Thu, Nov 27, 2014 at 3:37 PM, James Morris  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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[James Morris]

On Mon, 1 Dec 2014, Kees Cook wrote:

 On Thu, Nov 27, 2014 at 3:37 PM, James Morris jmor...@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
jmor...@namei.org

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[Kees Cook]

On Mon, Dec 1, 2014 at 2:56 PM, James Morris jmor...@namei.org wrote:
 On Mon, 1 Dec 2014, Kees Cook wrote:

 On Thu, Nov 27, 2014 at 3:37 PM, James Morris jmor...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[James Morris]

On Mon, 1 Dec 2014, Kees Cook wrote:

 On Mon, Dec 1, 2014 at 2:56 PM, James Morris jmor...@namei.org wrote:
  On Mon, 1 Dec 2014, Kees Cook wrote:
 
  On Thu, Nov 27, 2014 at 3:37 PM, James Morris jmor...@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
jmor...@namei.org

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[Kees Cook]

On Thu, Nov 27, 2014 at 3:37 PM, James Morris jmor...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[James Morris]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[James Morris]

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
jmor...@namei.org

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[Kees Cook]

On Wed, Nov 26, 2014 at 1:46 PM, Stephen Rothwell  wrote:
> Hi James,
>
> On Thu, 27 Nov 2014 00:23:06 +1100 (AEDT) James Morris  
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[Stephen Rothwell]

Hi James,

On Thu, 27 Nov 2014 00:23:06 +1100 (AEDT) James Morris  
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 Rothwells...@canb.auug.org.au


pgpZzTwST7Odb.pgp
Description: OpenPGP digital signature

Re: [PULL] seccomp update (next)

[James Morris]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[James Morris]

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
jmor...@namei.org

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL] seccomp update (next)

[Stephen Rothwell]

Hi James,

On Thu, 27 Nov 2014 00:23:06 +1100 (AEDT) James Morris jmor...@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 Rothwells...@canb.auug.org.au


pgpZzTwST7Odb.pgp
Description: OpenPGP digital signature

Re: [PULL] seccomp update (next)

[Kees Cook]

On Wed, Nov 26, 2014 at 1:46 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
 Hi James,

 On Thu, 27 Nov 2014 00:23:06 +1100 (AEDT) James Morris jmor...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/