All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: kernel-hardening@lists.openwall.com,
	Brad Spengler <spender@grsecurity.net>,
	PaX Team <pageexec@freemail.hu>,
	Casey Schaufler <casey.schaufler@intel.com>,
	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>
Subject: [kernel-hardening] Re: [PATCH v2 2/4] usercopy: avoid direct copying to userspace
Date: Thu, 9 Jun 2016 19:37:14 -0400	[thread overview]
Message-ID: <20160609193714.0f302022@annuminas.surriel.com> (raw)
In-Reply-To: <1465420302-23754-3-git-send-email-keescook@chromium.org>

On Wed,  8 Jun 2016 14:11:40 -0700
Kees Cook <keescook@chromium.org> wrote:

> Some non-whitelisted heap memory has small areas that need to be copied
> to userspace. For these cases, explicitly copy the needed contents out
> to stack first before sending to userspace. This lets their respective
> caches remain un-whitelisted (i.e. no SLAB_USERCOPY), since the bulk of
> their contents should not be exposed to userspace.
> 
> These changes, based on code by Brad Spengler and PaX Team, were extracted
> from grsecurity/PaX on a case-by-case basis as I ran into errors during
> testing of CONFIG_HARDENED_USERCOPY_WHITELIST:

You will want this bit as well. It is an adaptation, with
a slight change after digging through XFS code for an hour
and a half or so, of code originally from grsecurity.

With this change, my system boots a usercopy kernel without
any visible issues.

---8<---

Subject: mm,xfs: bounce buffer the file name in xfs_dir2_sf_getdents

"Short form" directories in XFS have the directory content inside the
in-memory inode, or other kernel memory. The directory contents can be
in the same slab object as other, more sensitive, contents.

Instead of marking the xfs_inode slab accessible to copy_from_user and
copy_to_user, bounce buffer the file name when doing getdents on a short
form directory.

This only affects short form directories, which will have a very small
number of entries. Large directories use different code.

Adapted from the grsecurity patch set. Thanks go out to pipacs and spender.

Signed-off-by: Rik van Riel <riel@redhat.com>
---
 fs/xfs/xfs_dir2_readdir.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_dir2_readdir.c b/fs/xfs/xfs_dir2_readdir.c
index f44f79996978..bc6c78cbe4c6 100644
--- a/fs/xfs/xfs_dir2_readdir.c
+++ b/fs/xfs/xfs_dir2_readdir.c
@@ -127,6 +127,7 @@ xfs_dir2_sf_getdents(
 	 */
 	sfep = xfs_dir2_sf_firstentry(sfp);
 	for (i = 0; i < sfp->count; i++) {
+		char name[sfep->namelen];
 		__uint8_t filetype;
 
 		off = xfs_dir2_db_off_to_dataptr(geo, geo->datablk,
@@ -140,7 +141,14 @@ xfs_dir2_sf_getdents(
 		ino = dp->d_ops->sf_get_ino(sfp, sfep);
 		filetype = dp->d_ops->sf_get_ftype(sfep);
 		ctx->pos = off & 0x7fffffff;
-		if (!dir_emit(ctx, (char *)sfep->name, sfep->namelen, ino,
+		/*
+		 * Short form directories have the file name stored in
+		 * memory that is not directly accessible to copy_to_user.
+		 * Bounce buffer the name, instead of potentially making
+		 * the other data accessible.
+		 */
+		memcpy(name, sfep->name, sfep->namelen);
+		if (!dir_emit(ctx, name, sfep->namelen, ino,
 			    xfs_dir3_get_dtype(dp->i_mount, filetype)))
 			return 0;
 		sfep = dp->d_ops->sf_nextentry(sfp, sfep);

  reply	other threads:[~2016-06-09 23:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-08 21:11 [kernel-hardening] [RFC][PATCH v2 0/4] mm: Hardened usercopy Kees Cook
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 1/4] " Kees Cook
2016-06-09  0:47   ` [kernel-hardening] " Brad Spengler
2016-06-09  1:39     ` Rik van Riel
2016-06-09  2:58     ` Kees Cook
2016-07-12 23:04   ` Kees Cook
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 2/4] usercopy: avoid direct copying to userspace Kees Cook
2016-06-09 23:37   ` Rik van Riel [this message]
2016-06-10 21:09   ` [kernel-hardening] " Kees Cook
2016-06-11  1:08     ` Rik van Riel
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 3/4] usercopy: whitelist user-copyable caches Kees Cook
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 4/4] usercopy: provide split of user-controlled slabs Kees Cook
2016-06-09  3:02 ` [kernel-hardening] [RFC][PATCH v2 5/4] arm: fixes for usercopy Kees Cook
2016-06-09 15:35 ` [kernel-hardening] RE: [RFC][PATCH v2 0/4] mm: Hardened usercopy Schaufler, Casey
2016-06-09 17:48   ` [kernel-hardening] " Kees Cook
2016-06-09 23:39 ` [kernel-hardening] [RFC][PATCH 6/4] mm: disallow user copy to/from separately allocated pages Rik van Riel
2016-06-10 19:44   ` [kernel-hardening] [RFC][PATCH v2 " Rik van Riel
2016-06-10 20:46     ` [kernel-hardening] " Kees Cook
2016-06-24 20:53     ` Kees Cook
2016-06-24 20:57       ` Rik van Riel
2016-06-24 20:59         ` Kees Cook
2016-06-16  1:30 ` [kernel-hardening] [RFC][PATCH v2 0/4] mm: Hardened usercopy Valdis.Kletnieks
2016-06-16  1:38   ` Kees Cook
2016-06-16 23:36     ` Valdis.Kletnieks
2016-06-17  1:38       ` Valdis.Kletnieks
2016-06-18 19:30         ` 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=20160609193714.0f302022@annuminas.surriel.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=casey.schaufler@intel.com \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=pageexec@freemail.hu \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=spender@grsecurity.net \
    /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.