Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1736107 > unrolled thread

[PATCH v3 00/31] Hardened usercopy whitelisting

Started byKees Cook <keescook@chromium.org>
First post2017-09-20 22:50 +0200
Last post2017-09-21 20:30 +0200
Articles 6 on this page of 26 — 2 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 00/31] Hardened usercopy whitelisting Kees Cook <keescook@chromium.org> - 2017-09-20 22:50 +0200
    [PATCH v3 26/31] fork: Provide usercopy whitelisting for task_struct Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 15/31] xfs: Define usercopy region in xfs_inode slab cache Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 07/31] ext4: Define usercopy region in ext4_inode_cache slab cache Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 29/31] arm: Implement thread_struct whitelist for hardened usercopy Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 25/31] fork: Define usercopy region in thread_stack slab caches Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 02/31] usercopy: Enforce slab cache usercopy region boundaries Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
      Re: [PATCH v3 02/31] usercopy: Enforce slab cache usercopy region  boundaries Christopher Lameter <cl@linux.com> - 2017-09-21 17:30 +0200
    [PATCH v3 23/31] net: Restrict unwhitelisted proto caches to size 0 Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 17/31] scsi: Define usercopy region in scsi_sense_cache slab cache Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 19/31] ip: Define usercopy region in IP proto slab cache Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 28/31] arm64: Implement thread_struct whitelist for hardened usercopy Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 21/31] sctp: Define usercopy region in SCTP proto slab cache Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 31/31] lkdtm: Update usercopy tests for whitelisting Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 01/31] usercopy: Prepare for usercopy whitelisting Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
      Re: [PATCH v3 01/31] usercopy: Prepare for usercopy whitelisting Christopher Lameter <cl@linux.com> - 2017-09-21 17:30 +0200
    [PATCH v3 08/31] ext2: Define usercopy region in ext2_inode_cache slab cache Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 18/31] net: Define usercopy region in struct proto slab cache Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 24/31] fork: Define usercopy region in mm_struct slab caches Kees Cook <keescook@chromium.org> - 2017-09-20 23:00 +0200
    [PATCH v3 04/31] dcache: Define usercopy region in dentry_cache slab cache Kees Cook <keescook@chromium.org> - 2017-09-20 23:10 +0200
    [PATCH v3 27/31] x86: Implement thread_struct whitelist for hardened usercopy Kees Cook <keescook@chromium.org> - 2017-09-20 23:10 +0200
    [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches Kees Cook <keescook@chromium.org> - 2017-09-20 23:10 +0200
      Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy  caches Christopher Lameter <cl@linux.com> - 2017-09-21 17:30 +0200
        Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc  caches as usercopy caches Kees Cook <keescook@chromium.org> - 2017-09-21 17:50 +0200
          Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc  caches as usercopy caches Christopher Lameter <cl@linux.com> - 2017-09-21 18:10 +0200
            Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc  caches as usercopy caches Kees Cook <keescook@chromium.org> - 2017-09-21 20:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1736141 — [PATCH v3 27/31] x86: Implement thread_struct whitelist for hardened usercopy

FromKees Cook <keescook@chromium.org>
Date2017-09-20 23:10 +0200
Subject[PATCH v3 27/31] x86: Implement thread_struct whitelist for hardened usercopy
Message-ID<urUpP-8nU-7@gated-at.bofh.it>
In reply to#1736107
This whitelists the FPU register state portion of the thread_struct for
copying to userspace, instead of the default entire struct.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Borislav Petkov <bp@suse.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
---
 arch/x86/Kconfig                 | 1 +
 arch/x86/include/asm/processor.h | 8 ++++++++
 2 files changed, 9 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 971feac13506..6642e8eaff45 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -114,6 +114,7 @@ config X86
 	select HAVE_ARCH_MMAP_RND_COMPAT_BITS	if MMU && COMPAT
 	select HAVE_ARCH_COMPAT_MMAP_BASES	if MMU && COMPAT
 	select HAVE_ARCH_SECCOMP_FILTER
+	select HAVE_ARCH_THREAD_STRUCT_WHITELIST
 	select HAVE_ARCH_TRACEHOOK
 	select HAVE_ARCH_TRANSPARENT_HUGEPAGE
 	select HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD if X86_64
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 3fa26a61eabc..868235b967ed 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -488,6 +488,14 @@ struct thread_struct {
 	 */
 };
 
+/* Whitelist the FPU state from the task_struct for hardened usercopy. */
+static inline void arch_thread_struct_whitelist(unsigned long *offset,
+						unsigned long *size)
+{
+	*offset = offsetof(struct thread_struct, fpu.state);
+	*size = fpu_kernel_xstate_size;
+}
+
 /*
  * Thread-synchronous status.
  *
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1736143 — [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches

FromKees Cook <keescook@chromium.org>
Date2017-09-20 23:10 +0200
Subject[PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches
Message-ID<urUpQ-8nU-21@gated-at.bofh.it>
In reply to#1736107
From: David Windsor <dave@nullcore.net>

Mark the kmalloc slab caches as entirely whitelisted. These caches
are frequently used to fulfill kernel allocations that contain data
to be copied to/from userspace. Internal-only uses are also common,
but are scattered in the kernel. For now, mark all the kmalloc caches
as whitelisted.

This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
whitelisting code in the last public patch of grsecurity/PaX based on my
understanding of the code. Changes or omissions from the original code are
mine and don't reflect the original grsecurity/PaX code.

Signed-off-by: David Windsor <dave@nullcore.net>
[kees: merged in moved kmalloc hunks, adjust commit log]
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
Cc: linux-xfs@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 mm/slab.c        |  3 ++-
 mm/slab.h        |  3 ++-
 mm/slab_common.c | 10 ++++++----
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index df268999cf02..9af16f675927 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1291,7 +1291,8 @@ void __init kmem_cache_init(void)
 	 */
 	kmalloc_caches[INDEX_NODE] = create_kmalloc_cache(
 				kmalloc_info[INDEX_NODE].name,
-				kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS);
+				kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS,
+				0, kmalloc_size(INDEX_NODE));
 	slab_state = PARTIAL_NODE;
 	setup_kmalloc_cache_index_table();
 
diff --git a/mm/slab.h b/mm/slab.h
index 044755ff9632..2e0fe357d777 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -97,7 +97,8 @@ struct kmem_cache *kmalloc_slab(size_t, gfp_t);
 extern int __kmem_cache_create(struct kmem_cache *, unsigned long flags);
 
 extern struct kmem_cache *create_kmalloc_cache(const char *name, size_t size,
-			unsigned long flags);
+			unsigned long flags, size_t useroffset,
+			size_t usersize);
 extern void create_boot_cache(struct kmem_cache *, const char *name,
 			size_t size, unsigned long flags, size_t useroffset,
 			size_t usersize);
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 36408f5f2a34..d4e6442f9bbc 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -920,14 +920,15 @@ void __init create_boot_cache(struct kmem_cache *s, const char *name, size_t siz
 }
 
 struct kmem_cache *__init create_kmalloc_cache(const char *name, size_t size,
-				unsigned long flags)
+				unsigned long flags, size_t useroffset,
+				size_t usersize)
 {
 	struct kmem_cache *s = kmem_cache_zalloc(kmem_cache, GFP_NOWAIT);
 
 	if (!s)
 		panic("Out of memory when creating slab %s\n", name);
 
-	create_boot_cache(s, name, size, flags, 0, size);
+	create_boot_cache(s, name, size, flags, useroffset, usersize);
 	list_add(&s->list, &slab_caches);
 	memcg_link_cache(s);
 	s->refcount = 1;
@@ -1081,7 +1082,8 @@ void __init setup_kmalloc_cache_index_table(void)
 static void __init new_kmalloc_cache(int idx, unsigned long flags)
 {
 	kmalloc_caches[idx] = create_kmalloc_cache(kmalloc_info[idx].name,
-					kmalloc_info[idx].size, flags);
+					kmalloc_info[idx].size, flags, 0,
+					kmalloc_info[idx].size);
 }
 
 /*
@@ -1122,7 +1124,7 @@ void __init create_kmalloc_caches(unsigned long flags)
 
 			BUG_ON(!n);
 			kmalloc_dma_caches[i] = create_kmalloc_cache(n,
-				size, SLAB_CACHE_DMA | flags);
+				size, SLAB_CACHE_DMA | flags, 0, 0);
 		}
 	}
 #endif
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1736777 — Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches

FromChristopher Lameter <cl@linux.com>
Date2017-09-21 17:30 +0200
SubjectRe: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches
Message-ID<usbAm-2Ne-17@gated-at.bofh.it>
In reply to#1736143
On Wed, 20 Sep 2017, Kees Cook wrote:

> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -1291,7 +1291,8 @@ void __init kmem_cache_init(void)
>  	 */
>  	kmalloc_caches[INDEX_NODE] = create_kmalloc_cache(
>  				kmalloc_info[INDEX_NODE].name,
> -				kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS);
> +				kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS,
> +				0, kmalloc_size(INDEX_NODE));
>  	slab_state = PARTIAL_NODE;
>  	setup_kmalloc_cache_index_table();

Ok this presumes that at some point we will be able to restrict the number
of bytes writeable and thus set the offset and size field to different
values. Is that realistic?

We already whitelist all kmalloc caches (see first patch).

So what is the point of this patch?

[toc] | [prev] | [next] | [standalone]

#1736800 — Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches

FromKees Cook <keescook@chromium.org>
Date2017-09-21 17:50 +0200
SubjectRe: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches
Message-ID<usbTI-2TP-17@gated-at.bofh.it>
In reply to#1736777
On Thu, Sep 21, 2017 at 8:27 AM, Christopher Lameter <cl@linux.com> wrote:
> On Wed, 20 Sep 2017, Kees Cook wrote:
>
>> --- a/mm/slab.c
>> +++ b/mm/slab.c
>> @@ -1291,7 +1291,8 @@ void __init kmem_cache_init(void)
>>        */
>>       kmalloc_caches[INDEX_NODE] = create_kmalloc_cache(
>>                               kmalloc_info[INDEX_NODE].name,
>> -                             kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS);
>> +                             kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS,
>> +                             0, kmalloc_size(INDEX_NODE));
>>       slab_state = PARTIAL_NODE;
>>       setup_kmalloc_cache_index_table();
>
> Ok this presumes that at some point we will be able to restrict the number
> of bytes writeable and thus set the offset and size field to different
> values. Is that realistic?
>
> We already whitelist all kmalloc caches (see first patch).
>
> So what is the point of this patch?

The DMA kmalloc caches are not whitelisted:

>>                         kmalloc_dma_caches[i] = create_kmalloc_cache(n,
>> -                               size, SLAB_CACHE_DMA | flags);
>> +                               size, SLAB_CACHE_DMA | flags, 0, 0);

So this is creating the distinction between the kmallocs that go to
userspace and those that don't. The expectation is that future work
can start to distinguish between "for userspace" and "only kernel"
kmalloc allocations, as is already done here for DMA.

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1736818 — Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches

FromChristopher Lameter <cl@linux.com>
Date2017-09-21 18:10 +0200
SubjectRe: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches
Message-ID<uscd3-3f6-7@gated-at.bofh.it>
In reply to#1736800
On Thu, 21 Sep 2017, Kees Cook wrote:

> > So what is the point of this patch?
>
> The DMA kmalloc caches are not whitelisted:

The DMA kmalloc caches are pretty obsolete and mostly there for obscure
drivers.

??

> >>                         kmalloc_dma_caches[i] = create_kmalloc_cache(n,
> >> -                               size, SLAB_CACHE_DMA | flags);
> >> +                               size, SLAB_CACHE_DMA | flags, 0, 0);
>
> So this is creating the distinction between the kmallocs that go to
> userspace and those that don't. The expectation is that future work
> can start to distinguish between "for userspace" and "only kernel"
> kmalloc allocations, as is already done here for DMA.

The creation of the kmalloc caches in earlier patches already setup the
"whitelisting". Why do it twice?

[toc] | [prev] | [next] | [standalone]

#1736995 — Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches

FromKees Cook <keescook@chromium.org>
Date2017-09-21 20:30 +0200
SubjectRe: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches
Message-ID<useox-4rm-7@gated-at.bofh.it>
In reply to#1736818
On Thu, Sep 21, 2017 at 9:04 AM, Christopher Lameter <cl@linux.com> wrote:
> On Thu, 21 Sep 2017, Kees Cook wrote:
>
>> > So what is the point of this patch?
>>
>> The DMA kmalloc caches are not whitelisted:
>
> The DMA kmalloc caches are pretty obsolete and mostly there for obscure
> drivers.
>
> ??

They may be obsolete, but they're still in the kernel, and they aren't
copied to userspace, so we can mark them.

>> >>                         kmalloc_dma_caches[i] = create_kmalloc_cache(n,
>> >> -                               size, SLAB_CACHE_DMA | flags);
>> >> +                               size, SLAB_CACHE_DMA | flags, 0, 0);
>>
>> So this is creating the distinction between the kmallocs that go to
>> userspace and those that don't. The expectation is that future work
>> can start to distinguish between "for userspace" and "only kernel"
>> kmalloc allocations, as is already done here for DMA.
>
> The creation of the kmalloc caches in earlier patches already setup the
> "whitelisting". Why do it twice?

Patch 1 is to allow for things to mark their whitelists. Patch 30
disables the full whitelisting, since then we've defined them all, so
the kmalloc caches need to mark themselves as whitelisted.

Patch 1 leaves unmarked things whitelisted so we can progressively
tighten the restriction and have a bisectable series. (i.e. if there
is something wrong with one of the whitelists in the series, it will
bisect to that one, not the one that removes the global whitelist from
patch 1.)

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web