From: Eric Biggers <ebiggers3@gmail.com> To: Kees Cook <keescook@chromium.org> Cc: kernel-hardening@lists.openwall.com, David Windsor <dave@nullcore.net>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [kernel-hardening] [PATCH 22/23] usercopy: split user-controlled slabs to separate caches Date: Mon, 19 Jun 2017 21:24:42 -0700 [thread overview] Message-ID: <20170620042442.GC610@zzz.localdomain> (raw) In-Reply-To: <1497915397-93805-23-git-send-email-keescook@chromium.org> On Mon, Jun 19, 2017 at 04:36:36PM -0700, Kees Cook wrote: > From: David Windsor <dave@nullcore.net> > > Some userspace APIs (e.g. ipc, seq_file) provide precise control over > the size of kernel kmallocs, which provides a trivial way to perform > heap overflow attacks where the attacker must control neighboring > allocations of a specific size. Instead, move these APIs into their own > cache so they cannot interfere with standard kmallocs. This is enabled > with CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC. > This is a logically separate change which IMO should be its own patch, not just patch 22/23. Also, is this really just about heap overflows? I thought the main purpose of separate heaps is to make it more difficult to exploit use-after-frees, since anything allocating an object from heap A cannot overwrite freed memory in heap B. (At least, not at the SLAB level; it may still be done at the page level.) > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index a89d37e8b387..ff4f4a698ad0 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -45,6 +45,7 @@ struct vm_area_struct; > #else > #define ___GFP_NOLOCKDEP 0 > #endif > +#define ___GFP_USERCOPY 0x4000000u > /* If the above are modified, __GFP_BITS_SHIFT may need updating */ > > /* > @@ -83,12 +84,17 @@ struct vm_area_struct; > * node with no fallbacks or placement policy enforcements. > * > * __GFP_ACCOUNT causes the allocation to be accounted to kmemcg. > + * > + * __GFP_USERCOPY indicates that the page will be explicitly copied to/from > + * userspace, and may be allocated from a separate kmalloc pool. > + * > */ The "page", or the allocation? It's only for slab objects, is it not? More importantly, the purpose of this needs to be clearly documented; otherwise people won't know what this is and whether they should/need to use it or not. - Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com> To: Kees Cook <keescook@chromium.org> Cc: kernel-hardening@lists.openwall.com, David Windsor <dave@nullcore.net>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [kernel-hardening] [PATCH 22/23] usercopy: split user-controlled slabs to separate caches Date: Mon, 19 Jun 2017 21:24:42 -0700 [thread overview] Message-ID: <20170620042442.GC610@zzz.localdomain> (raw) In-Reply-To: <1497915397-93805-23-git-send-email-keescook@chromium.org> On Mon, Jun 19, 2017 at 04:36:36PM -0700, Kees Cook wrote: > From: David Windsor <dave@nullcore.net> > > Some userspace APIs (e.g. ipc, seq_file) provide precise control over > the size of kernel kmallocs, which provides a trivial way to perform > heap overflow attacks where the attacker must control neighboring > allocations of a specific size. Instead, move these APIs into their own > cache so they cannot interfere with standard kmallocs. This is enabled > with CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC. > This is a logically separate change which IMO should be its own patch, not just patch 22/23. Also, is this really just about heap overflows? I thought the main purpose of separate heaps is to make it more difficult to exploit use-after-frees, since anything allocating an object from heap A cannot overwrite freed memory in heap B. (At least, not at the SLAB level; it may still be done at the page level.) > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index a89d37e8b387..ff4f4a698ad0 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -45,6 +45,7 @@ struct vm_area_struct; > #else > #define ___GFP_NOLOCKDEP 0 > #endif > +#define ___GFP_USERCOPY 0x4000000u > /* If the above are modified, __GFP_BITS_SHIFT may need updating */ > > /* > @@ -83,12 +84,17 @@ struct vm_area_struct; > * node with no fallbacks or placement policy enforcements. > * > * __GFP_ACCOUNT causes the allocation to be accounted to kmemcg. > + * > + * __GFP_USERCOPY indicates that the page will be explicitly copied to/from > + * userspace, and may be allocated from a separate kmalloc pool. > + * > */ The "page", or the allocation? It's only for slab objects, is it not? More importantly, the purpose of this needs to be clearly documented; otherwise people won't know what this is and whether they should/need to use it or not. - Eric -- 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-06-20 4:24 UTC|newest] Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-06-19 23:36 [PATCH 00/23] Hardened usercopy whitelisting Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 01/23] usercopy: Prepare for " Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 02/23] usercopy: Enforce slab cache usercopy region boundaries Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 03/23] vfs: define usercopy region in names_cache slab caches Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 04/23] vfs: copy struct mount.mnt_id to userspace using put_user() Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 05/23] befs: define usercopy region in befs_inode_cache slab cache Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 06/23] cifs: define usercopy region in cifs_request " Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 07/23] exofs: define usercopy region in exofs_inode_cache " Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 08/23] ext2: define usercopy region in ext2_inode_cache " Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 09/23] ext4: define usercopy region in ext4_inode_cache " Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 10/23] vxfs: define usercopy region in vxfs_inode " Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 11/23] jfs: define usercopy region in jfs_ip " Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 12/23] orangefs: define usercopy region in orangefs_inode_cache " Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 13/23] ufs: define usercopy region in ufs_inode_cache " Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 14/23] fork: define usercopy region in thread_stack, task_struct, mm_struct slab caches Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 15/23] net: define usercopy region in struct proto slab cache Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 16/23] net: copy struct sctp_sock.autoclose to userspace using put_user() Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 17/23] dcache: define usercopy region in dentry_cache slab cache Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-20 4:08 ` [kernel-hardening] " Eric Biggers 2017-06-20 4:08 ` Eric Biggers 2017-06-28 16:44 ` Kees Cook 2017-06-28 16:44 ` Kees Cook 2017-06-28 16:44 ` Kees Cook 2017-06-28 16:55 ` Eric Biggers 2017-06-28 16:55 ` Eric Biggers 2017-06-28 16:55 ` Eric Biggers 2017-06-19 23:36 ` [PATCH 18/23] scsi: define usercopy region in scsi_sense_cache " Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 19/23] xfs: define usercopy region in xfs_inode " Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 20/23] usercopy: convert kmalloc caches to usercopy caches Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-19 23:36 ` [PATCH 21/23] usercopy: Restrict non-usercopy caches to size 0 Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-20 4:04 ` [kernel-hardening] " Eric Biggers 2017-06-20 4:04 ` Eric Biggers 2017-06-28 17:03 ` Kees Cook 2017-06-28 17:03 ` Kees Cook 2017-06-28 17:03 ` Kees Cook 2017-06-19 23:36 ` [PATCH 22/23] usercopy: split user-controlled slabs to separate caches Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-20 4:24 ` Eric Biggers [this message] 2017-06-20 4:24 ` [kernel-hardening] " Eric Biggers 2017-06-20 4:47 ` Eric Biggers 2017-06-20 4:47 ` Eric Biggers 2017-06-20 22:27 ` Kees Cook 2017-06-20 22:27 ` Kees Cook 2017-06-20 22:27 ` Kees Cook 2017-06-20 20:24 ` Laura Abbott 2017-06-20 20:24 ` [kernel-hardening] " Laura Abbott 2017-06-20 20:24 ` Laura Abbott 2017-06-20 22:22 ` Kees Cook 2017-06-20 22:22 ` [kernel-hardening] " Kees Cook 2017-06-20 22:22 ` Kees Cook 2017-06-27 7:31 ` Michal Hocko 2017-06-27 7:31 ` [kernel-hardening] " Michal Hocko 2017-06-27 7:31 ` Michal Hocko 2017-06-27 22:07 ` Kees Cook 2017-06-27 22:07 ` [kernel-hardening] " Kees Cook 2017-06-27 22:07 ` Kees Cook 2017-06-28 8:54 ` Michal Hocko 2017-06-28 8:54 ` [kernel-hardening] " Michal Hocko 2017-06-28 8:54 ` Michal Hocko 2017-06-19 23:36 ` [PATCH 23/23] mm: Allow slab_nomerge to be set at build time Kees Cook 2017-06-19 23:36 ` [kernel-hardening] " Kees Cook 2017-06-19 23:36 ` Kees Cook 2017-06-20 4:09 ` [kernel-hardening] " Daniel Micay 2017-06-20 4:09 ` Daniel Micay 2017-06-20 22:51 ` Kees Cook 2017-06-20 22:51 ` Kees Cook 2017-06-20 22:51 ` Kees Cook 2017-06-20 4:29 ` Eric Biggers 2017-06-20 4:29 ` Eric Biggers 2017-06-20 23:09 ` Kees Cook 2017-06-20 23:09 ` Kees Cook 2017-06-20 23:09 ` Kees Cook 2017-06-20 19:41 ` [kernel-hardening] [PATCH 00/23] Hardened usercopy whitelisting Rik van Riel 2017-10-20 22:40 ` Paolo Bonzini 2017-10-20 22:40 ` [kernel-hardening] " Paolo Bonzini 2017-10-20 22:40 ` Paolo Bonzini 2017-10-20 23:25 ` Paolo Bonzini 2017-10-20 23:25 ` [kernel-hardening] " Paolo Bonzini 2017-10-20 23:25 ` Paolo Bonzini 2017-10-21 3:04 ` Kees Cook 2017-10-21 3:04 ` [kernel-hardening] " Kees Cook 2017-10-21 3:04 ` 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=20170620042442.GC610@zzz.localdomain \ --to=ebiggers3@gmail.com \ --cc=dave@nullcore.net \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.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: linkBe 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.