All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	"Alasdair G. Kergon" <agk@redhat.com>,
	Mike Snitzer <msnitzer@redhat.com>,
	Milan Broz <gmazyland@gmail.com>,
	kkolasa@winsoft.pl, dm-devel@redhat.com
Subject: Re: [PATCH] slab: implement kmalloc guard
Date: Mon, 8 Sep 2014 09:36:38 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.11.1409080932490.20388@gentwo.org> (raw)
In-Reply-To: <alpine.LRH.2.02.1409051833510.9790@file01.intranet.prod.int.rdu2.redhat.com>

On Fri, 5 Sep 2014, Mikulas Patocka wrote:

> This patch adds a new option DEBUG_KMALLOC that makes it possible to
> detect writes beyond the end of space allocated with kmalloc. Normally,
> the kmalloc function rounds the size to the next power of two (there is
> exception to this rule - sizes 96 and 192). Slab debugging detects only
> writes beyond the end of the slab object, it is unable to detect writes
> beyond the end of kmallocated size that fit into the slab object.
>
> The motivation for this patch was this: There was 6 year old bug in
> dm-crypt (d49ec52ff6ddcda178fc2476a109cf1bd1fa19ed) where the driver would
> write beyond the end of kmallocated space, but the bug went undetected
> because the write would fit into the power-of-two-sized slab object. Only
> recent changes to dm-crypt made the bug show up. There is similar problem
> in the nx-crypto driver in the function nx_crypto_ctx_init - again,
> because kmalloc rounds the size up to the next power of two, this bug went
> undetected.

The problem with the kmalloc array for debugging is inded that it is
only for powers of two for efficiency purposes. In the debug
situation we may not have the need for that efficiency. Maybe simply
creating kmalloc arrays for each size will do the trick?

> This patch works for slab, slub and slob subsystems. The end of slab block
> can be found out with ksize (this patch renames it to __ksize). At the end
> of the block, we put a structure kmalloc_guard. This structure contains a
> magic number and a real size of the block - the exact size given to

We already have a redzone structure to check for writes over the end of
the object. Lets use that.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@linux.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	"Alasdair G. Kergon" <agk@redhat.com>,
	Mike Snitzer <msnitzer@redhat.com>,
	Milan Broz <gmazyland@gmail.com>,
	kkolasa@winsoft.pl, dm-devel@redhat.com
Subject: Re: [PATCH] slab: implement kmalloc guard
Date: Mon, 8 Sep 2014 09:36:38 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.11.1409080932490.20388@gentwo.org> (raw)
In-Reply-To: <alpine.LRH.2.02.1409051833510.9790@file01.intranet.prod.int.rdu2.redhat.com>

On Fri, 5 Sep 2014, Mikulas Patocka wrote:

> This patch adds a new option DEBUG_KMALLOC that makes it possible to
> detect writes beyond the end of space allocated with kmalloc. Normally,
> the kmalloc function rounds the size to the next power of two (there is
> exception to this rule - sizes 96 and 192). Slab debugging detects only
> writes beyond the end of the slab object, it is unable to detect writes
> beyond the end of kmallocated size that fit into the slab object.
>
> The motivation for this patch was this: There was 6 year old bug in
> dm-crypt (d49ec52ff6ddcda178fc2476a109cf1bd1fa19ed) where the driver would
> write beyond the end of kmallocated space, but the bug went undetected
> because the write would fit into the power-of-two-sized slab object. Only
> recent changes to dm-crypt made the bug show up. There is similar problem
> in the nx-crypto driver in the function nx_crypto_ctx_init - again,
> because kmalloc rounds the size up to the next power of two, this bug went
> undetected.

The problem with the kmalloc array for debugging is inded that it is
only for powers of two for efficiency purposes. In the debug
situation we may not have the need for that efficiency. Maybe simply
creating kmalloc arrays for each size will do the trick?

> This patch works for slab, slub and slob subsystems. The end of slab block
> can be found out with ksize (this patch renames it to __ksize). At the end
> of the block, we put a structure kmalloc_guard. This structure contains a
> magic number and a real size of the block - the exact size given to

We already have a redzone structure to check for writes over the end of
the object. Lets use that.

--
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>

  reply	other threads:[~2014-09-08 14:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05 22:54 [PATCH] slab: implement kmalloc guard Mikulas Patocka
2014-09-05 22:54 ` Mikulas Patocka
2014-09-08 14:36 ` Christoph Lameter [this message]
2014-09-08 14:36   ` Christoph Lameter
2014-09-08 14:46   ` Mikulas Patocka
2014-09-08 14:46     ` Mikulas Patocka
2014-09-08 16:10     ` Christoph Lameter
2014-09-08 16:10       ` Christoph Lameter
2014-09-12  2:32       ` Mikulas Patocka
2014-09-12  2:32         ` Mikulas Patocka
2014-09-15  2:11         ` Joonsoo Kim
2014-09-15  2:11           ` Joonsoo Kim
2014-10-16 14:55           ` Mikulas Patocka
2014-10-16 14:55             ` Mikulas Patocka

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.11.1409080932490.20388@gentwo.org \
    --to=cl@linux.com \
    --cc=agk@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dm-devel@redhat.com \
    --cc=gmazyland@gmail.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kkolasa@winsoft.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpatocka@redhat.com \
    --cc=msnitzer@redhat.com \
    --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.