From: Christoph Lameter <cl@linux.com>
To: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Andy Lutomirski <luto@kernel.org>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Tejun Heo <tj@kernel.org>, Daniel Mack <daniel@zonque.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Helge Deller <deller@gmx.de>, Rik van Riel <riel@redhat.com>,
linux-mm@kvack.org, Tycho Andersen <tycho@docker.com>,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation
Date: Thu, 6 Jul 2017 08:43:19 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.20.1707060841170.23867@east.gentwo.org> (raw)
In-Reply-To: <20170706002718.GA102852@beast>
On Wed, 5 Jul 2017, Kees Cook wrote:
> @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, unsigned long flags)
> {
> s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor);
> s->reserved = 0;
> +#ifdef CONFIG_SLAB_FREELIST_HARDENED
> + s->random = get_random_long();
> +#endif
>
> if (need_reserve_slab_rcu && (s->flags & SLAB_TYPESAFE_BY_RCU))
> s->reserved = sizeof(struct rcu_head);
>
So if an attacker knows the internal structure of data then he can simply
dereference page->kmem_cache->random to decode the freepointer.
Assuming someone is already targeting a freelist pointer (which indicates
detailed knowledge of the internal structure) then I would think that
someone like that will also figure out how to follow the pointer links to
get to the random value.
Not seeing the point of all of this.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@linux.com>
To: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Andy Lutomirski <luto@kernel.org>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Tejun Heo <tj@kernel.org>, Daniel Mack <daniel@zonque.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Helge Deller <deller@gmx.de>, Rik van Riel <riel@redhat.com>,
linux-mm@kvack.org, Tycho Andersen <tycho@docker.com>,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation
Date: Thu, 6 Jul 2017 08:43:19 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.20.1707060841170.23867@east.gentwo.org> (raw)
In-Reply-To: <20170706002718.GA102852@beast>
On Wed, 5 Jul 2017, Kees Cook wrote:
> @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, unsigned long flags)
> {
> s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor);
> s->reserved = 0;
> +#ifdef CONFIG_SLAB_FREELIST_HARDENED
> + s->random = get_random_long();
> +#endif
>
> if (need_reserve_slab_rcu && (s->flags & SLAB_TYPESAFE_BY_RCU))
> s->reserved = sizeof(struct rcu_head);
>
So if an attacker knows the internal structure of data then he can simply
dereference page->kmem_cache->random to decode the freepointer.
Assuming someone is already targeting a freelist pointer (which indicates
detailed knowledge of the internal structure) then I would think that
someone like that will also figure out how to follow the pointer links to
get to the random value.
Not seeing the point of all of this.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@linux.com>
To: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Andy Lutomirski <luto@kernel.org>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Tejun Heo <tj@kernel.org>, Daniel Mack <daniel@zonque.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Helge Deller <deller@gmx.de>, Rik van Riel <riel@redhat.com>,
linux-mm@kvack.org, Tycho Andersen <tycho@docker.com>,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation
Date: Thu, 6 Jul 2017 08:43:19 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.20.1707060841170.23867@east.gentwo.org> (raw)
In-Reply-To: <20170706002718.GA102852@beast>
On Wed, 5 Jul 2017, Kees Cook wrote:
> @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, unsigned long flags)
> {
> s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor);
> s->reserved = 0;
> +#ifdef CONFIG_SLAB_FREELIST_HARDENED
> + s->random = get_random_long();
> +#endif
>
> if (need_reserve_slab_rcu && (s->flags & SLAB_TYPESAFE_BY_RCU))
> s->reserved = sizeof(struct rcu_head);
>
So if an attacker knows the internal structure of data then he can simply
dereference page->kmem_cache->random to decode the freepointer.
Assuming someone is already targeting a freelist pointer (which indicates
detailed knowledge of the internal structure) then I would think that
someone like that will also figure out how to follow the pointer links to
get to the random value.
Not seeing the point of all of this.
next prev parent reply other threads:[~2017-07-06 13:43 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-06 0:27 [PATCH v3] mm: Add SLUB free list pointer obfuscation Kees Cook
2017-07-06 0:27 ` [kernel-hardening] " Kees Cook
2017-07-06 0:27 ` Kees Cook
2017-07-06 13:43 ` Christoph Lameter [this message]
2017-07-06 13:43 ` [kernel-hardening] " Christoph Lameter
2017-07-06 13:43 ` Christoph Lameter
2017-07-06 15:48 ` Kees Cook
2017-07-06 15:48 ` [kernel-hardening] " Kees Cook
2017-07-06 15:48 ` Kees Cook
2017-07-06 15:55 ` Christoph Lameter
2017-07-06 15:55 ` [kernel-hardening] " Christoph Lameter
2017-07-06 15:55 ` Christoph Lameter
2017-07-06 16:16 ` [kernel-hardening] " Daniel Micay
2017-07-06 16:16 ` Daniel Micay
2017-07-06 16:16 ` Daniel Micay
2017-07-06 17:53 ` Rik van Riel
2017-07-06 17:53 ` [kernel-hardening] " Rik van Riel
2017-07-06 17:53 ` Rik van Riel
2017-07-06 18:50 ` Kees Cook
2017-07-06 18:50 ` [kernel-hardening] " Kees Cook
2017-07-06 18:50 ` Kees Cook
2017-07-07 13:50 ` Christoph Lameter
2017-07-07 13:50 ` [kernel-hardening] " Christoph Lameter
2017-07-07 13:50 ` Christoph Lameter
2017-07-07 16:51 ` Kees Cook
2017-07-07 16:51 ` [kernel-hardening] " Kees Cook
2017-07-07 16:51 ` Kees Cook
2017-07-07 17:06 ` Christoph Lameter
2017-07-07 17:06 ` [kernel-hardening] " Christoph Lameter
2017-07-07 17:06 ` Christoph Lameter
2017-07-07 18:43 ` Kees Cook
2017-07-07 18:43 ` [kernel-hardening] " Kees Cook
2017-07-07 18:43 ` Kees Cook
2017-07-24 21:17 ` [v3] " Alexander Popov
2017-07-24 21:17 ` [kernel-hardening] " Alexander Popov
2017-07-24 21:17 ` Alexander Popov
2017-07-25 9:42 ` Alexander Popov
2017-07-25 9:42 ` [kernel-hardening] " Alexander Popov
2017-07-25 9:42 ` Alexander Popov
2017-07-26 0:21 ` Kees Cook
2017-07-26 0:21 ` [kernel-hardening] " Kees Cook
2017-07-26 0:21 ` Kees Cook
2017-07-26 14:08 ` Christopher Lameter
2017-07-26 14:08 ` [kernel-hardening] " Christopher Lameter
2017-07-26 14:08 ` Christopher Lameter
2017-07-26 16:20 ` Kees Cook
2017-07-26 16:20 ` [kernel-hardening] " Kees Cook
2017-07-26 16:20 ` Kees Cook
2017-07-26 16:55 ` Christopher Lameter
2017-07-26 16:55 ` [kernel-hardening] " Christopher Lameter
2017-07-26 16:55 ` Christopher Lameter
2017-07-26 17:13 ` Kees Cook
2017-07-26 17:13 ` [kernel-hardening] " Kees Cook
2017-07-26 17:13 ` Kees Cook
2017-07-27 15:15 ` Christopher Lameter
2017-07-27 15:15 ` [kernel-hardening] " Christopher Lameter
2017-07-27 15:15 ` Christopher Lameter
2017-07-27 22:48 ` Alexander Popov
2017-07-27 22:48 ` [kernel-hardening] " Alexander Popov
2017-07-27 22:48 ` Alexander Popov
2017-07-27 23:53 ` Christopher Lameter
2017-07-27 23:53 ` [kernel-hardening] " Christopher Lameter
2017-07-27 23:53 ` Christopher Lameter
2017-07-31 20:17 ` Alexander Popov
2017-07-31 20:17 ` [kernel-hardening] " Alexander Popov
2017-07-31 20:17 ` Alexander Popov
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=alpine.DEB.2.20.1707060841170.23867@east.gentwo.org \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=daniel@zonque.org \
--cc=deller@gmx.de \
--cc=iamjoonsoo.kim@lge.com \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=penberg@kernel.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tj@kernel.org \
--cc=tycho@docker.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.