From: Michael Ellerman <mpe@ellerman.id.au>
To: David Laight <David.Laight@ACULAB.COM>,
"'Josh Poimboeuf'" <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>
Cc: "linux-ia64\@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"kernel-hardening\@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, Linux-MM <linux-mm@kvack.org>,
sparclinux <sparclinux@vger.kernel.org>, Jan Kara <jack@suse.cz>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"x86\@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Dmitry Vyukov <dvyukov@google.com>,
David Rientjes <rientjes@google.com>,
PaX Team <pageexec@freemail.hu>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>,
linux-arch <linux-arch@vger.kernel.org>,
Rik van Riel <riel@redhat.com>,
Brad Spengler <spender@grsecurity.net>,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-arm-kernel\@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Laura Abbott <labbott@fedoraproject.org>,
Tony Luck <tony.luck@intel.com>,
Ard Biesh euvel <ard.biesheuvel@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Fenghua Yu <fenghua.yu@intel.com>,
Pekka Enberg <penberg@kernel.org>,
Daniel Micay <danielmicay@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"linuxppc-dev\@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH v3 02/11] mm: Hardened usercopy
Date: Tue, 26 Jul 2016 12:09:14 +1000 [thread overview]
Message-ID: <87mvl5jgl1.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com>
David Laight <David.Laight@ACULAB.COM> writes:
> From: Josh Poimboeuf
>> Sent: 22 July 2016 18:46
>> >
>> > e.g. then if the pointer was in the thread_info, the second test would
>> > fail, triggering the protection.
>>
>> FWIW, this won't work right on x86 after Andy's
>> CONFIG_THREAD_INFO_IN_TASK patches get merged.
>
> What ends up in the 'thread_info' area?
It depends on the arch.
> If it contains the fp save area then programs like gdb may end up requesting
> copy_in/out directly from that area.
On the arches I've seen thread_info doesn't usually contain register save areas,
but if it did then it would be up to the arch helper to allow that copy to go
through.
However given thread_info generally contains lots of low level flags that would
be a good target for an attacker, the best way to cope with ptrace wanting to
copy to/from it would be to use a temporary, and prohibit copying directly
to/from thread_info - IMHO.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: David Laight <David.Laight@ACULAB.COM>,
'Josh Poimboeuf' <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>
Cc: "linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, Linux-MM <linux-mm@kvack.org>,
sparclinux <sparclinux@vger.kernel.org>, Jan Kara <jack@suse.cz>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"x86@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Dmitry Vyukov <dvyukov@google.com>,
David Rientjes <rientjes@google.com>,
PaX Team <pageexec@freemail.hu>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>,
linux-arch <linux-arch@vger.kernel.org>,
Rik van Riel <riel@redhat.com>,
Brad Spengler <spender@grsecurity.net>,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton
<akpm@linux-foundation.org>"linux-arm-kernel@lists.infradead.org"
<li>
Subject: RE: [PATCH v3 02/11] mm: Hardened usercopy
Date: Tue, 26 Jul 2016 12:09:14 +1000 [thread overview]
Message-ID: <87mvl5jgl1.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com>
David Laight <David.Laight@ACULAB.COM> writes:
> From: Josh Poimboeuf
>> Sent: 22 July 2016 18:46
>> >
>> > e.g. then if the pointer was in the thread_info, the second test would
>> > fail, triggering the protection.
>>
>> FWIW, this won't work right on x86 after Andy's
>> CONFIG_THREAD_INFO_IN_TASK patches get merged.
>
> What ends up in the 'thread_info' area?
It depends on the arch.
> If it contains the fp save area then programs like gdb may end up requesting
> copy_in/out directly from that area.
On the arches I've seen thread_info doesn't usually contain register save areas,
but if it did then it would be up to the arch helper to allow that copy to go
through.
However given thread_info generally contains lots of low level flags that would
be a good target for an attacker, the best way to cope with ptrace wanting to
copy to/from it would be to use a temporary, and prohibit copying directly
to/from thread_info - IMHO.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: David Laight <David.Laight@ACULAB.COM>,
'Josh Poimboeuf' <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>
Cc: "linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, Linux-MM <linux-mm@kvack.org>,
sparclinux <sparclinux@vger.kernel.org>, Jan Kara <jack@suse.cz>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"x86@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Dmitry Vyukov <dvyukov@google.com>,
David Rientjes <rientjes@google.com>,
PaX Team <pageexec@freemail.hu>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>,
linux-arch <linux-arch@vger.kernel.org>,
Rik van Riel <riel@redhat.com>,
Brad Spengler <spender@grsecurity.net>,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Laura Abbott <labbott@fedoraproject.org>,
Tony Luck <tony.luck@intel.com>,
Ard Biesh euvel <ard.biesheuvel@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Fenghua Yu <fenghua.yu@intel.com>,
Pekka Enberg <penberg@kernel.org>,
Daniel Micay <danielmicay@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH v3 02/11] mm: Hardened usercopy
Date: Tue, 26 Jul 2016 12:09:14 +1000 [thread overview]
Message-ID: <87mvl5jgl1.fsf@concordia.ellerman.id.au> (raw)
Message-ID: <20160726020914.mstAG_KBDVX5zCrgFQ6dbo9L_JisUxkzm1YQTJWcCRs@z> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com>
David Laight <David.Laight@ACULAB.COM> writes:
> From: Josh Poimboeuf
>> Sent: 22 July 2016 18:46
>> >
>> > e.g. then if the pointer was in the thread_info, the second test would
>> > fail, triggering the protection.
>>
>> FWIW, this won't work right on x86 after Andy's
>> CONFIG_THREAD_INFO_IN_TASK patches get merged.
>
> What ends up in the 'thread_info' area?
It depends on the arch.
> If it contains the fp save area then programs like gdb may end up requesting
> copy_in/out directly from that area.
On the arches I've seen thread_info doesn't usually contain register save areas,
but if it did then it would be up to the arch helper to allow that copy to go
through.
However given thread_info generally contains lots of low level flags that would
be a good target for an attacker, the best way to cope with ptrace wanting to
copy to/from it would be to use a temporary, and prohibit copying directly
to/from thread_info - IMHO.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: David Laight <David.Laight@ACULAB.COM>,
'Josh Poimboeuf' <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>
Cc: "linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, Linux-MM <linux-mm@kvack.org>,
sparclinux <sparclinux@vger.kernel.org>, Jan Kara <jack@suse.cz>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"x86@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Dmitry Vyukov <dvyukov@google.com>,
David Rientjes <rientjes@google.com>,
PaX Team <pageexec@freemail.hu>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>,
linux-arch <linux-arch@vger.kernel.org>,
Rik van Riel <riel@redhat.com>,
Brad Spengler <spender@grsecurity.net>,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Laura Abbott <labbott@fedoraproject.org>,
Tony Luck <tony.luck@intel.com>,
Ard Biesh euvel <ard.biesheuvel@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Fenghua Yu <fenghua.yu@intel.com>,
Pekka Enberg <penberg@kernel.org>,
Daniel Micay <danielmicay@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH v3 02/11] mm: Hardened usercopy
Date: Tue, 26 Jul 2016 02:09:14 +0000 [thread overview]
Message-ID: <87mvl5jgl1.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com>
David Laight <David.Laight@ACULAB.COM> writes:
> From: Josh Poimboeuf
>> Sent: 22 July 2016 18:46
>> >
>> > e.g. then if the pointer was in the thread_info, the second test would
>> > fail, triggering the protection.
>>
>> FWIW, this won't work right on x86 after Andy's
>> CONFIG_THREAD_INFO_IN_TASK patches get merged.
>
> What ends up in the 'thread_info' area?
It depends on the arch.
> If it contains the fp save area then programs like gdb may end up requesting
> copy_in/out directly from that area.
On the arches I've seen thread_info doesn't usually contain register save areas,
but if it did then it would be up to the arch helper to allow that copy to go
through.
However given thread_info generally contains lots of low level flags that would
be a good target for an attacker, the best way to cope with ptrace wanting to
copy to/from it would be to use a temporary, and prohibit copying directly
to/from thread_info - IMHO.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: David Laight <David.Laight@ACULAB.COM>,
'Josh Poimboeuf' <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>
Cc: "linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, Linux-MM <linux-mm@kvack.org>,
sparclinux <sparclinux@vger.kernel.org>, Jan Kara <jack@suse.cz>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"x86@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Dmitry Vyukov <dvyukov@google.com>,
David Rientjes <rientjes@google.com>,
PaX Team <pageexec@freemail.hu>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>,
linux-arch <linux-arch@vger.kernel.org>,
Rik van Riel <riel@redhat.com>,
Brad Spengler <spender@grsecurity.net>,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Laura Abbott <labbott@fedoraproject.org>,
Tony Luck <tony.luck@intel.com>,
Ard Biesh euvel <ard.biesheuvel@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Fenghua Yu <fenghua.yu@intel.com>,
Pekka Enberg <penberg@kernel.org>,
Daniel Micay <danielmicay@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH v3 02/11] mm: Hardened usercopy
Date: Tue, 26 Jul 2016 12:09:14 +1000 [thread overview]
Message-ID: <87mvl5jgl1.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com>
David Laight <David.Laight@ACULAB.COM> writes:
> From: Josh Poimboeuf
>> Sent: 22 July 2016 18:46
>> >
>> > e.g. then if the pointer was in the thread_info, the second test would
>> > fail, triggering the protection.
>>
>> FWIW, this won't work right on x86 after Andy's
>> CONFIG_THREAD_INFO_IN_TASK patches get merged.
>
> What ends up in the 'thread_info' area?
It depends on the arch.
> If it contains the fp save area then programs like gdb may end up requesting
> copy_in/out directly from that area.
On the arches I've seen thread_info doesn't usually contain register save areas,
but if it did then it would be up to the arch helper to allow that copy to go
through.
However given thread_info generally contains lots of low level flags that would
be a good target for an attacker, the best way to cope with ptrace wanting to
copy to/from it would be to use a temporary, and prohibit copying directly
to/from thread_info - IMHO.
cheers
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: mpe@ellerman.id.au (Michael Ellerman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 02/11] mm: Hardened usercopy
Date: Tue, 26 Jul 2016 12:09:14 +1000 [thread overview]
Message-ID: <87mvl5jgl1.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com>
David Laight <David.Laight@ACULAB.COM> writes:
> From: Josh Poimboeuf
>> Sent: 22 July 2016 18:46
>> >
>> > e.g. then if the pointer was in the thread_info, the second test would
>> > fail, triggering the protection.
>>
>> FWIW, this won't work right on x86 after Andy's
>> CONFIG_THREAD_INFO_IN_TASK patches get merged.
>
> What ends up in the 'thread_info' area?
It depends on the arch.
> If it contains the fp save area then programs like gdb may end up requesting
> copy_in/out directly from that area.
On the arches I've seen thread_info doesn't usually contain register save areas,
but if it did then it would be up to the arch helper to allow that copy to go
through.
However given thread_info generally contains lots of low level flags that would
be a good target for an attacker, the best way to cope with ptrace wanting to
copy to/from it would be to use a temporary, and prohibit copying directly
to/from thread_info - IMHO.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: David Laight <David.Laight@ACULAB.COM>,
'Josh Poimboeuf' <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>
Cc: "linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, Linux-MM <linux-mm@kvack.org>,
sparclinux <sparclinux@vger.kernel.org>, Jan Kara <jack@suse.cz>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"x86@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Dmitry Vyukov <dvyukov@google.com>,
David Rientjes <rientjes@google.com>,
PaX Team <pageexec@freemail.hu>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>,
linux-arch <linux-arch@vger.kernel.org>,
Rik van Riel <riel@redhat.com>,
Brad Spengler <spender@grsecurity.net>,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Laura Abbott <labbott@fedoraproject.org>,
Tony Luck <tony.luck@intel.com>,
Ard Biesh euvel <ard.biesheuvel@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Fenghua Yu <fenghua.yu@intel.com>,
Pekka Enberg <penberg@kernel.org>,
Daniel Micay <danielmicay@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: [kernel-hardening] RE: [PATCH v3 02/11] mm: Hardened usercopy
Date: Tue, 26 Jul 2016 12:09:14 +1000 [thread overview]
Message-ID: <87mvl5jgl1.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com>
David Laight <David.Laight@ACULAB.COM> writes:
> From: Josh Poimboeuf
>> Sent: 22 July 2016 18:46
>> >
>> > e.g. then if the pointer was in the thread_info, the second test would
>> > fail, triggering the protection.
>>
>> FWIW, this won't work right on x86 after Andy's
>> CONFIG_THREAD_INFO_IN_TASK patches get merged.
>
> What ends up in the 'thread_info' area?
It depends on the arch.
> If it contains the fp save area then programs like gdb may end up requesting
> copy_in/out directly from that area.
On the arches I've seen thread_info doesn't usually contain register save areas,
but if it did then it would be up to the arch helper to allow that copy to go
through.
However given thread_info generally contains lots of low level flags that would
be a good target for an attacker, the best way to cope with ptrace wanting to
copy to/from it would be to use a temporary, and prohibit copying directly
to/from thread_info - IMHO.
cheers
next prev parent reply other threads:[~2016-07-26 2:09 UTC|newest]
Thread overview: 257+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-15 21:44 [PATCH v3 00/11] mm: Hardened usercopy Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 01/11] mm: Implement stack frame object validation Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 02/11] mm: Hardened usercopy Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-19 1:06 ` Laura Abbott
2016-07-19 1:06 ` [kernel-hardening] " Laura Abbott
2016-07-19 1:06 ` Laura Abbott
2016-07-19 1:06 ` Laura Abbott
2016-07-19 1:06 ` Laura Abbott
2016-07-19 1:06 ` Laura Abbott
2016-07-19 18:48 ` Kees Cook
2016-07-19 18:48 ` [kernel-hardening] " Kees Cook
2016-07-19 18:48 ` Kees Cook
2016-07-19 18:48 ` Kees Cook
2016-07-19 18:48 ` Kees Cook
2016-07-19 18:48 ` Kees Cook
2016-07-19 18:48 ` Kees Cook
2016-07-19 22:00 ` [PATCH] mm: Add is_migrate_cma_page Laura Abbott
2016-07-19 22:00 ` [kernel-hardening] " Laura Abbott
2016-07-19 22:00 ` Laura Abbott
2016-07-19 22:00 ` Laura Abbott
2016-07-19 22:00 ` Laura Abbott
2016-07-19 22:00 ` Laura Abbott
2016-07-19 22:40 ` Kees Cook
2016-07-19 22:40 ` [kernel-hardening] " Kees Cook
2016-07-19 22:40 ` Kees Cook
2016-07-19 22:40 ` Kees Cook
2016-07-19 22:40 ` Kees Cook
2016-07-19 22:40 ` Kees Cook
2016-07-19 22:40 ` Kees Cook
2016-07-20 10:24 ` [PATCH v3 02/11] mm: Hardened usercopy Balbir Singh
2016-07-20 10:24 ` [kernel-hardening] " Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 15:36 ` Laura Abbott
2016-07-20 15:36 ` [kernel-hardening] " Laura Abbott
2016-07-20 15:36 ` Laura Abbott
2016-07-20 15:36 ` Laura Abbott
2016-07-20 15:36 ` Laura Abbott
2016-07-20 15:36 ` Laura Abbott
2016-07-20 15:36 ` Laura Abbott
2016-07-19 1:52 ` Laura Abbott
2016-07-19 1:52 ` [kernel-hardening] " Laura Abbott
2016-07-19 1:52 ` Laura Abbott
2016-07-19 1:52 ` Laura Abbott
2016-07-19 1:52 ` Laura Abbott
2016-07-19 1:52 ` Laura Abbott
2016-07-19 19:12 ` Kees Cook
2016-07-19 19:12 ` [kernel-hardening] " Kees Cook
2016-07-19 19:12 ` Kees Cook
2016-07-19 19:12 ` Kees Cook
2016-07-19 19:12 ` Kees Cook
2016-07-19 19:12 ` Kees Cook
2016-07-19 19:12 ` Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 22:55 ` [kernel-hardening] " Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 9:21 ` Christian Borntraeger
2016-07-19 9:21 ` [kernel-hardening] " Christian Borntraeger
2016-07-19 9:21 ` Christian Borntraeger
2016-07-19 9:21 ` Christian Borntraeger
2016-07-19 9:21 ` Christian Borntraeger
2016-07-19 9:21 ` Christian Borntraeger
2016-07-19 19:31 ` Kees Cook
2016-07-19 19:31 ` [kernel-hardening] " Kees Cook
2016-07-19 19:31 ` Kees Cook
2016-07-19 19:31 ` Kees Cook
2016-07-19 19:31 ` Kees Cook
2016-07-19 19:31 ` Kees Cook
2016-07-19 19:31 ` Kees Cook
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:14 ` [kernel-hardening] " Christian Borntraeger
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:34 ` [kernel-hardening] " Kees Cook
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:44 ` Christian Borntraeger
2016-07-19 20:44 ` [kernel-hardening] " Christian Borntraeger
2016-07-19 20:44 ` Christian Borntraeger
2016-07-19 20:44 ` Christian Borntraeger
2016-07-19 20:44 ` Christian Borntraeger
2016-07-19 20:44 ` Christian Borntraeger
2016-07-19 20:44 ` Christian Borntraeger
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` [kernel-hardening] " Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
[not found] ` <5790711f.2350420a.b4287.2cc0SMTPIN_ADDED_BROKEN@mx.google.com>
2016-07-21 18:34 ` Kees Cook
2016-07-21 18:34 ` [kernel-hardening] " Kees Cook
2016-07-21 18:34 ` Kees Cook
2016-07-21 18:34 ` Kees Cook
2016-07-21 18:34 ` Kees Cook
2016-07-21 18:34 ` Kees Cook
2016-07-21 18:34 ` Kees Cook
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-22 17:45 ` [kernel-hardening] " Josh Poimboeuf
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-25 9:27 ` David Laight
2016-07-25 9:27 ` [kernel-hardening] " David Laight
2016-07-25 9:27 ` David Laight
2016-07-25 9:27 ` David Laight
2016-07-25 9:27 ` David Laight
2016-07-25 9:27 ` David Laight
2016-07-25 9:27 ` David Laight
2016-07-26 2:09 ` Michael Ellerman [this message]
2016-07-26 2:09 ` [kernel-hardening] " Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:03 ` Michael Ellerman
2016-07-26 2:03 ` [kernel-hardening] " Michael Ellerman
2016-07-26 2:03 ` Michael Ellerman
2016-07-26 2:03 ` Michael Ellerman
2016-07-26 4:46 ` Kees Cook
2016-07-26 4:46 ` [kernel-hardening] " Kees Cook
2016-07-26 4:46 ` Kees Cook
2016-07-26 4:46 ` Kees Cook
2016-07-26 4:46 ` Kees Cook
2016-07-26 4:46 ` Kees Cook
2016-07-26 4:46 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 03/11] x86/uaccess: Enable hardened usercopy Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 04/11] ARM: uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 05/11] arm64/uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 06/11] ia64/uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 07/11] powerpc/uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 08/11] sparc/uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 09/11] s390/uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 10/11] mm: SLAB hardened usercopy support Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 11/11] mm: SLUB " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-18 8:26 ` [PATCH v3 00/11] mm: Hardened usercopy Balbir Singh
2016-07-18 8:26 ` [kernel-hardening] " Balbir Singh
2016-07-18 8:26 ` Balbir Singh
2016-07-18 8:26 ` Balbir Singh
2016-07-18 8:26 ` Balbir Singh
2016-07-18 8:26 ` Balbir Singh
2016-07-18 8:26 ` Balbir Singh
2016-07-20 9:52 ` David Laight
2016-07-20 9:52 ` [kernel-hardening] " David Laight
2016-07-20 9:52 ` David Laight
2016-07-20 9:52 ` David Laight
2016-07-20 9:52 ` David Laight
2016-07-20 9:52 ` David Laight
2016-07-20 9:52 ` David Laight
2016-07-20 15:31 ` Kees Cook
2016-07-20 15:31 ` [kernel-hardening] " Kees Cook
2016-07-20 15:31 ` Kees Cook
2016-07-20 15:31 ` Kees Cook
2016-07-20 15:31 ` Kees Cook
2016-07-20 15:31 ` Kees Cook
2016-07-20 15:31 ` Kees Cook
2016-07-20 16:02 ` David Laight
2016-07-20 16:02 ` [kernel-hardening] " David Laight
2016-07-20 16:02 ` David Laight
2016-07-20 16:02 ` David Laight
2016-07-20 16:02 ` David Laight
2016-07-20 16:02 ` David Laight
2016-07-20 16:02 ` David Laight
2016-07-20 16:22 ` Rik van Riel
2016-07-20 16:22 ` [kernel-hardening] " Rik van Riel
2016-07-20 16:22 ` Rik van Riel
2016-07-20 16:22 ` Rik van Riel
2016-07-20 16:22 ` Rik van Riel
2016-07-20 16:22 ` Rik van Riel
2016-07-20 17:44 ` Kees Cook
2016-07-20 17:44 ` [kernel-hardening] " Kees Cook
2016-07-20 17:44 ` Kees Cook
2016-07-20 17:44 ` Kees Cook
2016-07-20 17:44 ` Kees Cook
2016-07-20 17:44 ` Kees Cook
2016-07-20 17:44 ` Kees Cook
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=87mvl5jgl1.fsf@concordia.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=David.Laight@ACULAB.COM \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=bp@suse.de \
--cc=casey@schaufler-ca.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=danielmicay@gmail.com \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=fenghua.yu@intel.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jack@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@fedoraproject.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=minipli@googlemail.com \
--cc=pageexec@freemail.hu \
--cc=penberg@kernel.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=sparclinux@vger.kernel.org \
--cc=spender@grsecurity.net \
--cc=tony.luck@intel.com \
--cc=will.deacon@arm.com \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.