From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Kees Cook <keescook@chromium.org>, linux-kernel@vger.kernel.org
Cc: Rik van Riel <riel@redhat.com>,
Casey Schaufler <casey@schaufler-ca.com>,
PaX Team <pageexec@freemail.hu>,
Brad Spengler <spender@grsecurity.net>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
"David S. Miller" <davem@davemloft.net>,
x86@kernel.org, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>, Jan Kara <jack@suse.cz>,
Vitaly Wool <vitalywool@gmail.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Dmitry Vyukov <dvyukov@google.com>,
Laura Abbott <labbott@fedoraproject.org>,
linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
linux-arch@vger.kernel.org, linux-mm@kvack.org,
kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] Re: [PATCH 0/9] mm: Hardened usercopy
Date: Thu, 7 Jul 2016 09:30:07 +0200 [thread overview]
Message-ID: <577E04FF.1090000@de.ibm.com> (raw)
In-Reply-To: <1467843928-29351-1-git-send-email-keescook@chromium.org>
On 07/07/2016 12:25 AM, Kees Cook wrote:
> Hi,
>
> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
> kept tweaking things further and further until I ended up with a whole
> new patch series. To that end, I took Rik's feedback and made a number
> of other changes and clean-ups as well.
>
> Based on my understanding, PAX_USERCOPY was designed to catch a few
> classes of flaws around the use of copy_to_user()/copy_from_user(). These
> changes don't touch get_user() and put_user(), since these operate on
> constant sized lengths, and tend to be much less vulnerable. There
> are effectively three distinct protections in the whole series,
> each of which I've given a separate CONFIG, though this patch set is
> only the first of the three intended protections. (Generally speaking,
> PAX_USERCOPY covers what I'm calling CONFIG_HARDENED_USERCOPY (this) and
> CONFIG_HARDENED_USERCOPY_WHITELIST (future), and PAX_USERCOPY_SLABS covers
> CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC (future).)
>
> This series, which adds CONFIG_HARDENED_USERCOPY, checks that objects
> being copied to/from userspace meet certain criteria:
> - if address is a heap object, the size must not exceed the object's
> allocated size. (This will catch all kinds of heap overflow flaws.)
> - if address range is in the current process stack, it must be within the
> current stack frame (if such checking is possible) or at least entirely
> within the current process's stack. (This could catch large lengths that
> would have extended beyond the current process stack, or overflows if
> their length extends back into the original stack.)
> - if the address range is part of kernel data, rodata, or bss, allow it.
> - if address range is page-allocated, that it doesn't span multiple
> allocations.
> - if address is within the kernel text, reject it.
> - everything else is accepted
>
> The patches in the series are:
> - The core copy_to/from_user() checks, without the slab object checks:
> 1- mm: Hardened usercopy
> - Per-arch enablement of the protection:
> 2- x86/uaccess: Enable hardened usercopy
> 3- ARM: uaccess: Enable hardened usercopy
> 4- arm64/uaccess: Enable hardened usercopy
> 5- ia64/uaccess: Enable hardened usercopy
> 6- powerpc/uaccess: Enable hardened usercopy
> 7- sparc/uaccess: Enable hardened usercopy
Was there a reason why you did not change s390?
WARNING: multiple messages have this Message-ID (diff)
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Kees Cook <keescook@chromium.org>, linux-kernel@vger.kernel.org
Cc: Rik van Riel <riel@redhat.com>,
Casey Schaufler <casey@schaufler-ca.com>,
PaX Team <pageexec@freemail.hu>,
Brad Spengler <spender@grsecurity.net>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
"David S. Miller" <davem@davemloft.net>,
x86@kernel.org, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@suse.de>
Subject: Re: [PATCH 0/9] mm: Hardened usercopy
Date: Thu, 7 Jul 2016 09:30:07 +0200 [thread overview]
Message-ID: <577E04FF.1090000@de.ibm.com> (raw)
In-Reply-To: <1467843928-29351-1-git-send-email-keescook@chromium.org>
On 07/07/2016 12:25 AM, Kees Cook wrote:
> Hi,
>
> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
> kept tweaking things further and further until I ended up with a whole
> new patch series. To that end, I took Rik's feedback and made a number
> of other changes and clean-ups as well.
>
> Based on my understanding, PAX_USERCOPY was designed to catch a few
> classes of flaws around the use of copy_to_user()/copy_from_user(). These
> changes don't touch get_user() and put_user(), since these operate on
> constant sized lengths, and tend to be much less vulnerable. There
> are effectively three distinct protections in the whole series,
> each of which I've given a separate CONFIG, though this patch set is
> only the first of the three intended protections. (Generally speaking,
> PAX_USERCOPY covers what I'm calling CONFIG_HARDENED_USERCOPY (this) and
> CONFIG_HARDENED_USERCOPY_WHITELIST (future), and PAX_USERCOPY_SLABS covers
> CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC (future).)
>
> This series, which adds CONFIG_HARDENED_USERCOPY, checks that objects
> being copied to/from userspace meet certain criteria:
> - if address is a heap object, the size must not exceed the object's
> allocated size. (This will catch all kinds of heap overflow flaws.)
> - if address range is in the current process stack, it must be within the
> current stack frame (if such checking is possible) or at least entirely
> within the current process's stack. (This could catch large lengths that
> would have extended beyond the current process stack, or overflows if
> their length extends back into the original stack.)
> - if the address range is part of kernel data, rodata, or bss, allow it.
> - if address range is page-allocated, that it doesn't span multiple
> allocations.
> - if address is within the kernel text, reject it.
> - everything else is accepted
>
> The patches in the series are:
> - The core copy_to/from_user() checks, without the slab object checks:
> 1- mm: Hardened usercopy
> - Per-arch enablement of the protection:
> 2- x86/uaccess: Enable hardened usercopy
> 3- ARM: uaccess: Enable hardened usercopy
> 4- arm64/uaccess: Enable hardened usercopy
> 5- ia64/uaccess: Enable hardened usercopy
> 6- powerpc/uaccess: Enable hardened usercopy
> 7- sparc/uaccess: Enable hardened usercopy
Was there a reason why you did not change s390?
WARNING: multiple messages have this Message-ID (diff)
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Kees Cook <keescook@chromium.org>, linux-kernel@vger.kernel.org
Cc: Rik van Riel <riel@redhat.com>,
Casey Schaufler <casey@schaufler-ca.com>,
PaX Team <pageexec@freemail.hu>,
Brad Spengler <spender@grsecurity.net>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
"David S. Miller" <davem@davemloft.net>,
x86@kernel.org, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>, Jan Kara <jack@suse.cz>,
Vitaly Wool <vitalywool@gmail.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Dmitry Vyukov <dvyukov@google.com>,
Laura Abbott <labbott@fedoraproject.org>,
linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
linux-arch@vger.kernel.org, linux-mm@kvack.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 0/9] mm: Hardened usercopy
Date: Thu, 7 Jul 2016 09:30:07 +0200 [thread overview]
Message-ID: <577E04FF.1090000@de.ibm.com> (raw)
Message-ID: <20160707073007.q2DGw7Zxqg_nRLJMkyaYVCYEBwotFXx2CCFKvhvFQSg@z> (raw)
In-Reply-To: <1467843928-29351-1-git-send-email-keescook@chromium.org>
On 07/07/2016 12:25 AM, Kees Cook wrote:
> Hi,
>
> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
> kept tweaking things further and further until I ended up with a whole
> new patch series. To that end, I took Rik's feedback and made a number
> of other changes and clean-ups as well.
>
> Based on my understanding, PAX_USERCOPY was designed to catch a few
> classes of flaws around the use of copy_to_user()/copy_from_user(). These
> changes don't touch get_user() and put_user(), since these operate on
> constant sized lengths, and tend to be much less vulnerable. There
> are effectively three distinct protections in the whole series,
> each of which I've given a separate CONFIG, though this patch set is
> only the first of the three intended protections. (Generally speaking,
> PAX_USERCOPY covers what I'm calling CONFIG_HARDENED_USERCOPY (this) and
> CONFIG_HARDENED_USERCOPY_WHITELIST (future), and PAX_USERCOPY_SLABS covers
> CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC (future).)
>
> This series, which adds CONFIG_HARDENED_USERCOPY, checks that objects
> being copied to/from userspace meet certain criteria:
> - if address is a heap object, the size must not exceed the object's
> allocated size. (This will catch all kinds of heap overflow flaws.)
> - if address range is in the current process stack, it must be within the
> current stack frame (if such checking is possible) or at least entirely
> within the current process's stack. (This could catch large lengths that
> would have extended beyond the current process stack, or overflows if
> their length extends back into the original stack.)
> - if the address range is part of kernel data, rodata, or bss, allow it.
> - if address range is page-allocated, that it doesn't span multiple
> allocations.
> - if address is within the kernel text, reject it.
> - everything else is accepted
>
> The patches in the series are:
> - The core copy_to/from_user() checks, without the slab object checks:
> 1- mm: Hardened usercopy
> - Per-arch enablement of the protection:
> 2- x86/uaccess: Enable hardened usercopy
> 3- ARM: uaccess: Enable hardened usercopy
> 4- arm64/uaccess: Enable hardened usercopy
> 5- ia64/uaccess: Enable hardened usercopy
> 6- powerpc/uaccess: Enable hardened usercopy
> 7- sparc/uaccess: Enable hardened usercopy
Was there a reason why you did not change s390?
WARNING: multiple messages have this Message-ID (diff)
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Kees Cook <keescook@chromium.org>, linux-kernel@vger.kernel.org
Cc: Rik van Riel <riel@redhat.com>,
Casey Schaufler <casey@schaufler-ca.com>,
PaX Team <pageexec@freemail.hu>,
Brad Spengler <spender@grsecurity.net>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
"David S. Miller" <davem@davemloft.net>,
x86@kernel.org, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>, Jan Kara <jack@suse.cz>,
Vitaly Wool <vitalywool@gmail.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Dmitry Vyukov <dvyukov@google.com>,
Laura Abbott <labbott@fedoraproject.org>,
linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
linux-arch@vger.kernel.org, linux-mm@kvack.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 0/9] mm: Hardened usercopy
Date: Thu, 07 Jul 2016 07:30:07 +0000 [thread overview]
Message-ID: <577E04FF.1090000@de.ibm.com> (raw)
In-Reply-To: <1467843928-29351-1-git-send-email-keescook@chromium.org>
On 07/07/2016 12:25 AM, Kees Cook wrote:
> Hi,
>
> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
> kept tweaking things further and further until I ended up with a whole
> new patch series. To that end, I took Rik's feedback and made a number
> of other changes and clean-ups as well.
>
> Based on my understanding, PAX_USERCOPY was designed to catch a few
> classes of flaws around the use of copy_to_user()/copy_from_user(). These
> changes don't touch get_user() and put_user(), since these operate on
> constant sized lengths, and tend to be much less vulnerable. There
> are effectively three distinct protections in the whole series,
> each of which I've given a separate CONFIG, though this patch set is
> only the first of the three intended protections. (Generally speaking,
> PAX_USERCOPY covers what I'm calling CONFIG_HARDENED_USERCOPY (this) and
> CONFIG_HARDENED_USERCOPY_WHITELIST (future), and PAX_USERCOPY_SLABS covers
> CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC (future).)
>
> This series, which adds CONFIG_HARDENED_USERCOPY, checks that objects
> being copied to/from userspace meet certain criteria:
> - if address is a heap object, the size must not exceed the object's
> allocated size. (This will catch all kinds of heap overflow flaws.)
> - if address range is in the current process stack, it must be within the
> current stack frame (if such checking is possible) or at least entirely
> within the current process's stack. (This could catch large lengths that
> would have extended beyond the current process stack, or overflows if
> their length extends back into the original stack.)
> - if the address range is part of kernel data, rodata, or bss, allow it.
> - if address range is page-allocated, that it doesn't span multiple
> allocations.
> - if address is within the kernel text, reject it.
> - everything else is accepted
>
> The patches in the series are:
> - The core copy_to/from_user() checks, without the slab object checks:
> 1- mm: Hardened usercopy
> - Per-arch enablement of the protection:
> 2- x86/uaccess: Enable hardened usercopy
> 3- ARM: uaccess: Enable hardened usercopy
> 4- arm64/uaccess: Enable hardened usercopy
> 5- ia64/uaccess: Enable hardened usercopy
> 6- powerpc/uaccess: Enable hardened usercopy
> 7- sparc/uaccess: Enable hardened usercopy
Was there a reason why you did not change s390?
WARNING: multiple messages have this Message-ID (diff)
From: borntraeger@de.ibm.com (Christian Borntraeger)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/9] mm: Hardened usercopy
Date: Thu, 7 Jul 2016 09:30:07 +0200 [thread overview]
Message-ID: <577E04FF.1090000@de.ibm.com> (raw)
In-Reply-To: <1467843928-29351-1-git-send-email-keescook@chromium.org>
On 07/07/2016 12:25 AM, Kees Cook wrote:
> Hi,
>
> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
> kept tweaking things further and further until I ended up with a whole
> new patch series. To that end, I took Rik's feedback and made a number
> of other changes and clean-ups as well.
>
> Based on my understanding, PAX_USERCOPY was designed to catch a few
> classes of flaws around the use of copy_to_user()/copy_from_user(). These
> changes don't touch get_user() and put_user(), since these operate on
> constant sized lengths, and tend to be much less vulnerable. There
> are effectively three distinct protections in the whole series,
> each of which I've given a separate CONFIG, though this patch set is
> only the first of the three intended protections. (Generally speaking,
> PAX_USERCOPY covers what I'm calling CONFIG_HARDENED_USERCOPY (this) and
> CONFIG_HARDENED_USERCOPY_WHITELIST (future), and PAX_USERCOPY_SLABS covers
> CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC (future).)
>
> This series, which adds CONFIG_HARDENED_USERCOPY, checks that objects
> being copied to/from userspace meet certain criteria:
> - if address is a heap object, the size must not exceed the object's
> allocated size. (This will catch all kinds of heap overflow flaws.)
> - if address range is in the current process stack, it must be within the
> current stack frame (if such checking is possible) or at least entirely
> within the current process's stack. (This could catch large lengths that
> would have extended beyond the current process stack, or overflows if
> their length extends back into the original stack.)
> - if the address range is part of kernel data, rodata, or bss, allow it.
> - if address range is page-allocated, that it doesn't span multiple
> allocations.
> - if address is within the kernel text, reject it.
> - everything else is accepted
>
> The patches in the series are:
> - The core copy_to/from_user() checks, without the slab object checks:
> 1- mm: Hardened usercopy
> - Per-arch enablement of the protection:
> 2- x86/uaccess: Enable hardened usercopy
> 3- ARM: uaccess: Enable hardened usercopy
> 4- arm64/uaccess: Enable hardened usercopy
> 5- ia64/uaccess: Enable hardened usercopy
> 6- powerpc/uaccess: Enable hardened usercopy
> 7- sparc/uaccess: Enable hardened usercopy
Was there a reason why you did not change s390?
WARNING: multiple messages have this Message-ID (diff)
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Kees Cook <keescook@chromium.org>, linux-kernel@vger.kernel.org
Cc: Rik van Riel <riel@redhat.com>,
Casey Schaufler <casey@schaufler-ca.com>,
PaX Team <pageexec@freemail.hu>,
Brad Spengler <spender@grsecurity.net>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
"David S. Miller" <davem@davemloft.net>,
x86@kernel.org, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>, Jan Kara <jack@suse.cz>,
Vitaly Wool <vitalywool@gmail.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Dmitry Vyukov <dvyukov@google.com>,
Laura Abbott <labbott@fedoraproject.org>,
linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
linux-arch@vger.kernel.org, linux-mm@kvack.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 0/9] mm: Hardened usercopy
Date: Thu, 7 Jul 2016 09:30:07 +0200 [thread overview]
Message-ID: <577E04FF.1090000@de.ibm.com> (raw)
In-Reply-To: <1467843928-29351-1-git-send-email-keescook@chromium.org>
On 07/07/2016 12:25 AM, Kees Cook wrote:
> Hi,
>
> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
> kept tweaking things further and further until I ended up with a whole
> new patch series. To that end, I took Rik's feedback and made a number
> of other changes and clean-ups as well.
>
> Based on my understanding, PAX_USERCOPY was designed to catch a few
> classes of flaws around the use of copy_to_user()/copy_from_user(). These
> changes don't touch get_user() and put_user(), since these operate on
> constant sized lengths, and tend to be much less vulnerable. There
> are effectively three distinct protections in the whole series,
> each of which I've given a separate CONFIG, though this patch set is
> only the first of the three intended protections. (Generally speaking,
> PAX_USERCOPY covers what I'm calling CONFIG_HARDENED_USERCOPY (this) and
> CONFIG_HARDENED_USERCOPY_WHITELIST (future), and PAX_USERCOPY_SLABS covers
> CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC (future).)
>
> This series, which adds CONFIG_HARDENED_USERCOPY, checks that objects
> being copied to/from userspace meet certain criteria:
> - if address is a heap object, the size must not exceed the object's
> allocated size. (This will catch all kinds of heap overflow flaws.)
> - if address range is in the current process stack, it must be within the
> current stack frame (if such checking is possible) or at least entirely
> within the current process's stack. (This could catch large lengths that
> would have extended beyond the current process stack, or overflows if
> their length extends back into the original stack.)
> - if the address range is part of kernel data, rodata, or bss, allow it.
> - if address range is page-allocated, that it doesn't span multiple
> allocations.
> - if address is within the kernel text, reject it.
> - everything else is accepted
>
> The patches in the series are:
> - The core copy_to/from_user() checks, without the slab object checks:
> 1- mm: Hardened usercopy
> - Per-arch enablement of the protection:
> 2- x86/uaccess: Enable hardened usercopy
> 3- ARM: uaccess: Enable hardened usercopy
> 4- arm64/uaccess: Enable hardened usercopy
> 5- ia64/uaccess: Enable hardened usercopy
> 6- powerpc/uaccess: Enable hardened usercopy
> 7- sparc/uaccess: Enable hardened usercopy
Was there a reason why you did not change s390?
--
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>
next prev parent reply other threads:[~2016-07-07 7:30 UTC|newest]
Thread overview: 336+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 22:25 [kernel-hardening] [PATCH 0/9] mm: Hardened usercopy Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` [kernel-hardening] [PATCH 1/9] " Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-07 5:37 ` [kernel-hardening] " Baruch Siach
2016-07-07 5:37 ` Baruch Siach
2016-07-07 5:37 ` Baruch Siach
2016-07-07 5:37 ` Baruch Siach
2016-07-07 5:37 ` Baruch Siach
2016-07-07 5:37 ` Baruch Siach
2016-07-07 17:25 ` [kernel-hardening] " Kees Cook
2016-07-07 17:25 ` Kees Cook
2016-07-07 17:25 ` Kees Cook
2016-07-07 17:25 ` Kees Cook
2016-07-07 17:25 ` Kees Cook
2016-07-07 17:25 ` Kees Cook
2016-07-07 18:35 ` [kernel-hardening] " Baruch Siach
2016-07-07 18:35 ` Baruch Siach
2016-07-07 18:35 ` Baruch Siach
2016-07-07 18:35 ` Baruch Siach
2016-07-07 18:35 ` Baruch Siach
2016-07-07 18:35 ` Baruch Siach
2016-07-07 7:42 ` [kernel-hardening] " Thomas Gleixner
2016-07-07 7:42 ` Thomas Gleixner
2016-07-07 7:42 ` Thomas Gleixner
2016-07-07 7:42 ` Thomas Gleixner
2016-07-07 7:42 ` Thomas Gleixner
2016-07-07 7:42 ` Thomas Gleixner
2016-07-07 17:29 ` [kernel-hardening] " Kees Cook
2016-07-07 17:29 ` Kees Cook
2016-07-07 17:29 ` Kees Cook
2016-07-07 17:29 ` Kees Cook
2016-07-07 17:29 ` Kees Cook
2016-07-07 17:29 ` Kees Cook
2016-07-07 19:34 ` [kernel-hardening] " Thomas Gleixner
2016-07-07 19:34 ` Thomas Gleixner
2016-07-07 19:34 ` Thomas Gleixner
2016-07-07 19:34 ` Thomas Gleixner
2016-07-07 19:34 ` Thomas Gleixner
2016-07-07 19:34 ` Thomas Gleixner
2016-07-07 8:01 ` [kernel-hardening] " Arnd Bergmann
2016-07-07 8:01 ` Arnd Bergmann
2016-07-07 8:01 ` Arnd Bergmann
2016-07-07 8:01 ` Arnd Bergmann
2016-07-07 8:01 ` Arnd Bergmann
2016-07-07 8:01 ` Arnd Bergmann
2016-07-07 17:37 ` [kernel-hardening] " Kees Cook
2016-07-07 17:37 ` Kees Cook
2016-07-07 17:37 ` Kees Cook
2016-07-07 17:37 ` Kees Cook
2016-07-07 17:37 ` Kees Cook
2016-07-07 17:37 ` Kees Cook
2016-07-08 5:34 ` [kernel-hardening] " Michael Ellerman
2016-07-08 5:34 ` Michael Ellerman
2016-07-08 5:34 ` Michael Ellerman
2016-07-08 5:34 ` Michael Ellerman
2016-07-08 5:34 ` Michael Ellerman
2016-07-08 5:34 ` Michael Ellerman
2016-07-08 5:34 ` Michael Ellerman
2016-07-08 9:22 ` [kernel-hardening] " Arnd Bergmann
2016-07-08 9:22 ` Arnd Bergmann
2016-07-08 9:22 ` Arnd Bergmann
2016-07-08 9:22 ` Arnd Bergmann
2016-07-08 9:22 ` Arnd Bergmann
2016-07-08 9:22 ` Arnd Bergmann
2016-07-07 16:19 ` [kernel-hardening] " Rik van Riel
2016-07-07 16:19 ` Rik van Riel
2016-07-07 16:19 ` Rik van Riel
2016-07-07 16:19 ` Rik van Riel
2016-07-07 16:19 ` Rik van Riel
2016-07-07 16:35 ` [kernel-hardening] " Rik van Riel
2016-07-07 16:35 ` Rik van Riel
2016-07-07 16:35 ` Rik van Riel
2016-07-07 16:35 ` Rik van Riel
2016-07-07 16:35 ` Rik van Riel
2016-07-07 17:41 ` [kernel-hardening] " Kees Cook
2016-07-07 17:41 ` Kees Cook
2016-07-07 17:41 ` Kees Cook
2016-07-07 17:41 ` Kees Cook
2016-07-07 17:41 ` Kees Cook
2016-07-07 17:41 ` Kees Cook
2016-07-06 22:25 ` [kernel-hardening] [PATCH 2/9] x86/uaccess: Enable hardened usercopy Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` [kernel-hardening] [PATCH 3/9] ARM: uaccess: " Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` [kernel-hardening] [PATCH 4/9] arm64/uaccess: " Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-07 10:07 ` [kernel-hardening] " Mark Rutland
2016-07-07 10:07 ` Mark Rutland
2016-07-07 10:07 ` Mark Rutland
2016-07-07 10:07 ` Mark Rutland
2016-07-07 10:07 ` Mark Rutland
2016-07-07 10:07 ` Mark Rutland
2016-07-07 17:19 ` [kernel-hardening] " Kees Cook
2016-07-07 17:19 ` Kees Cook
2016-07-07 17:19 ` Kees Cook
2016-07-07 17:19 ` Kees Cook
2016-07-07 17:19 ` Kees Cook
2016-07-07 17:19 ` Kees Cook
2016-07-06 22:25 ` [kernel-hardening] [PATCH 5/9] ia64/uaccess: " Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` [kernel-hardening] [PATCH 6/9] powerpc/uaccess: " Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` [kernel-hardening] [PATCH 7/9] sparc/uaccess: " Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` [kernel-hardening] [PATCH 8/9] mm: SLAB hardened usercopy support Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` [kernel-hardening] [PATCH 9/9] mm: SLUB " Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-06 22:25 ` Kees Cook
2016-07-07 4:35 ` Michael Ellerman
2016-07-07 4:35 ` Michael Ellerman
2016-07-07 4:35 ` Michael Ellerman
2016-07-07 4:35 ` Michael Ellerman
2016-07-07 4:35 ` [kernel-hardening] " Michael Ellerman
2016-07-07 4:35 ` Michael Ellerman
2016-07-07 4:35 ` Michael Ellerman
[not found] ` <577ddc18.d351190a.1fa54.ffffbe79SMTPIN_ADDED_BROKEN@mx.google.com>
2016-07-07 18:56 ` [kernel-hardening] " Kees Cook
2016-07-07 18:56 ` Kees Cook
2016-07-07 18:56 ` Kees Cook
2016-07-07 18:56 ` Kees Cook
2016-07-08 10:19 ` Michael Ellerman
2016-07-08 13:45 ` Christoph Lameter
2016-07-08 13:45 ` Christoph Lameter
2016-07-08 13:45 ` Christoph Lameter
2016-07-08 13:45 ` Christoph Lameter
2016-07-08 16:07 ` Kees Cook
2016-07-08 16:07 ` Kees Cook
2016-07-08 16:07 ` Kees Cook
2016-07-08 16:07 ` Kees Cook
2016-07-08 16:20 ` Christoph Lameter
2016-07-08 16:20 ` Christoph Lameter
2016-07-08 16:20 ` Christoph Lameter
2016-07-08 16:20 ` Christoph Lameter
2016-07-08 17:41 ` [kernel-hardening] " Kees Cook
2016-07-08 17:41 ` Kees Cook
2016-07-08 17:41 ` Kees Cook
2016-07-08 17:41 ` Kees Cook
2016-07-08 17:41 ` Kees Cook
2016-07-08 20:48 ` Kees Cook
2016-07-08 20:48 ` Kees Cook
2016-07-08 20:48 ` Kees Cook
2016-07-08 20:48 ` Kees Cook
2016-07-08 20:48 ` Kees Cook
2016-07-09 5:58 ` [kernel-hardening] " Michael Ellerman
2016-07-09 5:58 ` Michael Ellerman
2016-07-09 5:58 ` Michael Ellerman
2016-07-09 5:58 ` Michael Ellerman
2016-07-09 5:58 ` [kernel-hardening] " Michael Ellerman
2016-07-09 5:58 ` Michael Ellerman
2016-07-09 5:58 ` Michael Ellerman
2016-07-09 5:58 ` Michael Ellerman
2016-07-09 6:07 ` Michael Ellerman
2016-07-09 6:07 ` [kernel-hardening] " Michael Ellerman
2016-07-09 6:07 ` Michael Ellerman
2016-07-09 6:07 ` Michael Ellerman
2016-07-09 6:07 ` Michael Ellerman
2016-07-09 6:07 ` Michael Ellerman
2016-07-09 6:07 ` Michael Ellerman
2016-07-09 6:07 ` Michael Ellerman
2016-07-09 6:07 ` Michael Ellerman
2016-07-09 5:58 ` Michael Ellerman
[not found] ` <57809299.84b3370a.5390c.ffff9e58SMTPIN_ADDED_BROKEN@mx.google.com>
2016-07-09 6:17 ` Valdis.Kletnieks
2016-07-09 6:17 ` Valdis.Kletnieks at vt.edu
2016-07-09 6:17 ` Valdis.Kletnieks
2016-07-09 6:17 ` Valdis.Kletnieks
2016-07-09 6:17 ` Valdis.Kletnieks
2016-07-09 17:07 ` Kees Cook
2016-07-09 17:07 ` Kees Cook
2016-07-09 17:07 ` Kees Cook
2016-07-09 17:07 ` Kees Cook
2016-07-09 17:07 ` Kees Cook
2016-07-11 6:08 ` Joonsoo Kim
2016-07-11 6:08 ` Joonsoo Kim
2016-07-11 6:08 ` Joonsoo Kim
2016-07-11 6:08 ` Joonsoo Kim
2016-07-11 6:08 ` Joonsoo Kim
2016-07-08 10:19 ` Michael Ellerman
2016-07-08 10:19 ` [kernel-hardening] " Michael Ellerman
2016-07-08 10:19 ` Michael Ellerman
2016-07-08 10:19 ` Michael Ellerman
2016-07-08 10:19 ` Michael Ellerman
2016-07-08 10:19 ` Michael Ellerman
2016-07-07 7:30 ` Christian Borntraeger [this message]
2016-07-07 7:30 ` [PATCH 0/9] mm: Hardened usercopy Christian Borntraeger
2016-07-07 7:30 ` Christian Borntraeger
2016-07-07 7:30 ` Christian Borntraeger
2016-07-07 7:30 ` Christian Borntraeger
2016-07-07 7:30 ` Christian Borntraeger
2016-07-07 17:27 ` [kernel-hardening] " Kees Cook
2016-07-07 17:27 ` Kees Cook
2016-07-07 17:27 ` Kees Cook
2016-07-07 17:27 ` Kees Cook
2016-07-07 17:27 ` Kees Cook
2016-07-07 17:27 ` Kees Cook
2016-07-08 8:46 ` [kernel-hardening] " Ingo Molnar
2016-07-08 8:46 ` Ingo Molnar
2016-07-08 8:46 ` Ingo Molnar
2016-07-08 8:46 ` Ingo Molnar
2016-07-08 8:46 ` Ingo Molnar
2016-07-08 8:46 ` Ingo Molnar
2016-07-08 16:19 ` [kernel-hardening] " Linus Torvalds
2016-07-08 16:19 ` Linus Torvalds
2016-07-08 16:19 ` Linus Torvalds
2016-07-08 16:19 ` Linus Torvalds
2016-07-08 16:19 ` Linus Torvalds
2016-07-08 16:19 ` Linus Torvalds
2016-07-08 18:23 ` [kernel-hardening] " Ingo Molnar
2016-07-08 18:23 ` Ingo Molnar
2016-07-08 18:23 ` Ingo Molnar
2016-07-08 18:23 ` Ingo Molnar
2016-07-08 18:23 ` Ingo Molnar
2016-07-08 18:23 ` Ingo Molnar
2016-07-09 2:22 ` [kernel-hardening] " Laura Abbott
2016-07-09 2:22 ` Laura Abbott
2016-07-09 2:22 ` Laura Abbott
2016-07-09 2:22 ` Laura Abbott
2016-07-09 2:44 ` [kernel-hardening] " Rik van Riel
2016-07-09 2:44 ` Rik van Riel
2016-07-09 2:44 ` Rik van Riel
2016-07-09 2:44 ` Rik van Riel
2016-07-09 2:44 ` Rik van Riel
2016-07-09 7:55 ` [kernel-hardening] " Ingo Molnar
2016-07-09 7:55 ` Ingo Molnar
2016-07-09 7:55 ` Ingo Molnar
2016-07-09 7:55 ` Ingo Molnar
2016-07-09 7:55 ` Ingo Molnar
2016-07-09 7:55 ` Ingo Molnar
2016-07-09 8:25 ` [kernel-hardening] " Ard Biesheuvel
2016-07-09 8:25 ` Ard Biesheuvel
2016-07-09 8:25 ` Ard Biesheuvel
2016-07-09 8:25 ` Ard Biesheuvel
2016-07-09 8:25 ` Ard Biesheuvel
2016-07-09 8:25 ` Ard Biesheuvel
2016-07-09 8:25 ` Ard Biesheuvel
2016-07-09 12:58 ` [kernel-hardening] " Laura Abbott
2016-07-09 12:58 ` Laura Abbott
2016-07-09 12:58 ` Laura Abbott
2016-07-09 17:03 ` [kernel-hardening] " Kees Cook
2016-07-09 17:03 ` Kees Cook
2016-07-09 17:03 ` Kees Cook
2016-07-09 17:03 ` Kees Cook
2016-07-09 17:03 ` Kees Cook
2016-07-09 17:03 ` Kees Cook
2016-07-09 17:03 ` Kees Cook
2016-07-09 17:01 ` [kernel-hardening] " Kees Cook
2016-07-09 17:01 ` Kees Cook
2016-07-09 17:01 ` Kees Cook
2016-07-09 17:01 ` Kees Cook
2016-07-09 17:01 ` Kees Cook
2016-07-09 17:01 ` Kees Cook
2016-07-09 21:27 ` [kernel-hardening] " Andy Lutomirski
2016-07-09 21:27 ` Andy Lutomirski
2016-07-09 21:27 ` Andy Lutomirski
2016-07-09 21:27 ` Andy Lutomirski
2016-07-09 21:27 ` Andy Lutomirski
2016-07-09 21:27 ` Andy Lutomirski
2016-07-09 23:16 ` [kernel-hardening] " PaX Team
2016-07-09 23:16 ` PaX Team
2016-07-09 23:16 ` PaX Team
2016-07-09 23:16 ` PaX Team
2016-07-09 23:16 ` PaX Team
2016-07-09 23:16 ` PaX Team
2016-07-09 23:16 ` PaX Team
2016-07-10 9:16 ` [kernel-hardening] " Ingo Molnar
2016-07-10 9:16 ` Ingo Molnar
2016-07-10 9:16 ` Ingo Molnar
2016-07-10 9:16 ` Ingo Molnar
2016-07-10 9:16 ` Ingo Molnar
2016-07-10 9:16 ` Ingo Molnar
2016-07-10 12:03 ` [kernel-hardening] " PaX Team
2016-07-10 12:03 ` PaX Team
2016-07-10 12:03 ` PaX Team
2016-07-10 12:03 ` PaX Team
2016-07-10 12:03 ` PaX Team
2016-07-10 12:03 ` PaX Team
2016-07-10 12:03 ` PaX Team
2016-07-10 12:38 ` [kernel-hardening] " Andy Lutomirski
2016-07-10 12:38 ` Andy Lutomirski
2016-07-10 12:38 ` Andy Lutomirski
2016-07-10 12:38 ` Andy Lutomirski
2016-07-10 12:38 ` Andy Lutomirski
2016-07-10 12:38 ` Andy Lutomirski
2016-07-11 18:40 ` [kernel-hardening] " Kees Cook
2016-07-11 18:40 ` Kees Cook
2016-07-11 18:40 ` Kees Cook
2016-07-11 18:40 ` Kees Cook
2016-07-11 18:40 ` Kees Cook
2016-07-11 18:40 ` Kees Cook
2016-07-11 18:34 ` [kernel-hardening] " Kees Cook
2016-07-11 18:34 ` Kees Cook
2016-07-11 18:34 ` Kees Cook
2016-07-11 18:34 ` Kees Cook
2016-07-11 18:34 ` Kees Cook
2016-07-11 18:34 ` Kees Cook
2016-07-12 18:26 ` [kernel-hardening] " Valdis.Kletnieks
2016-07-12 18: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=577E04FF.1090000@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=benh@kernel.crashing.org \
--cc=bp@suse.de \
--cc=casey@schaufler-ca.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=fenghua.yu@intel.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jack@suse.cz \
--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=mpe@ellerman.id.au \
--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=vitalywool@gmail.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.