From: Kees Cook <keescook@chromium.org>
To: Christopher Lameter <cl@linux.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
David Windsor <dave@nullcore.net>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
linux-xfs@vger.kernel.org,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches
Date: Thu, 21 Sep 2017 11:26:43 -0700 [thread overview]
Message-ID: <CAGXu5jKqWShVMqm6-moqgO7JUaJuFxw-9mMKak+WG1HgNJqc1Q@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1709211102320.14742@nuc-kabylake>
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
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Christopher Lameter <cl@linux.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
David Windsor <dave@nullcore.net>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
linux-xfs@vger.kernel.org,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches
Date: Thu, 21 Sep 2017 11:26:43 -0700 [thread overview]
Message-ID: <CAGXu5jKqWShVMqm6-moqgO7JUaJuFxw-9mMKak+WG1HgNJqc1Q@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1709211102320.14742@nuc-kabylake>
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
--
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:[~2017-09-21 18:26 UTC|newest]
Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 20:45 [PATCH v3 00/31] Hardened usercopy whitelisting Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 01/31] usercopy: Prepare for " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-21 15:21 ` Christopher Lameter
2017-09-21 15:21 ` [kernel-hardening] " Christopher Lameter
2017-09-20 20:45 ` [PATCH v3 02/31] usercopy: Enforce slab cache usercopy region boundaries Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-21 15:23 ` Christopher Lameter
2017-09-21 15:23 ` [kernel-hardening] " Christopher Lameter
2017-09-20 20:45 ` [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-21 15:27 ` Christopher Lameter
2017-09-21 15:27 ` [kernel-hardening] " Christopher Lameter
2017-09-21 15:40 ` Kees Cook
2017-09-21 15:40 ` Kees Cook
2017-09-21 15:40 ` Kees Cook
2017-09-21 16:04 ` Christopher Lameter
2017-09-21 16:04 ` Christopher Lameter
2017-09-21 18:26 ` Kees Cook [this message]
2017-09-21 18:26 ` Kees Cook
2017-09-21 18:26 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 04/31] dcache: Define usercopy region in dentry_cache slab cache Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 05/31] vfs: Define usercopy region in names_cache slab caches Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 06/31] vfs: Copy struct mount.mnt_id to userspace using put_user() Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 07/31] ext4: Define usercopy region in ext4_inode_cache slab cache Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 08/31] ext2: Define usercopy region in ext2_inode_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 09/31] jfs: Define usercopy region in jfs_ip " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-22 2:54 ` Dave Kleikamp
2017-09-22 2:54 ` [kernel-hardening] " Dave Kleikamp
2017-09-22 2:54 ` Dave Kleikamp
2017-09-20 20:45 ` [PATCH v3 10/31] befs: Define usercopy region in befs_inode_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-21 9:34 ` Luis de Bethencourt
2017-09-21 9:34 ` [kernel-hardening] " Luis de Bethencourt
2017-09-21 9:34 ` Luis de Bethencourt
2017-09-20 20:45 ` [PATCH v3 11/31] exofs: Define usercopy region in exofs_inode_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 12/31] orangefs: Define usercopy region in orangefs_inode_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 13/31] ufs: Define usercopy region in ufs_inode_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 14/31] vxfs: Define usercopy region in vxfs_inode " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:56 ` Christoph Hellwig
2017-09-20 20:56 ` [kernel-hardening] " Christoph Hellwig
2017-09-20 20:56 ` Christoph Hellwig
2017-09-20 21:21 ` Kees Cook
2017-09-20 21:21 ` [kernel-hardening] " Kees Cook
2017-09-20 21:21 ` Kees Cook
2017-09-20 23:22 ` Christoph Hellwig
2017-09-20 23:22 ` [kernel-hardening] " Christoph Hellwig
2017-09-20 23:22 ` Christoph Hellwig
2017-09-20 23:22 ` Christoph Hellwig
2017-09-20 20:45 ` [PATCH v3 15/31] xfs: Define usercopy region in xfs_inode " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
[not found] ` <1505940337-79069-1-git-send-email-keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2017-09-20 20:45 ` [PATCH v3 16/31] cifs: Define usercopy region in cifs_request " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 17/31] scsi: Define usercopy region in scsi_sense_cache " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 18/31] net: Define usercopy region in struct proto " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 19/31] ip: Define usercopy region in IP " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 20/31] caif: Define usercopy region in caif " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 21/31] sctp: Define usercopy region in SCTP " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 22/31] sctp: Copy struct sctp_sock.autoclose to userspace using put_user() Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 23/31] net: Restrict unwhitelisted proto caches to size 0 Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 24/31] fork: Define usercopy region in mm_struct slab caches Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 25/31] fork: Define usercopy region in thread_stack " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 26/31] fork: Provide usercopy whitelisting for task_struct Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 27/31] x86: Implement thread_struct whitelist for hardened usercopy Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 28/31] arm64: " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 29/31] arm: " Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 30/31] usercopy: Restrict non-usercopy caches to size 0 Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` Kees Cook
2017-09-20 20:45 ` [PATCH v3 31/31] lkdtm: Update usercopy tests for whitelisting Kees Cook
2017-09-20 20:45 ` [kernel-hardening] " Kees Cook
2017-09-20 20:45 ` 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=CAGXu5jKqWShVMqm6-moqgO7JUaJuFxw-9mMKak+WG1HgNJqc1Q@mail.gmail.com \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dave@nullcore.net \
--cc=iamjoonsoo.kim@lge.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
/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.