From: Laura Abbott <laura@labbott.name>
To: Kees Cook <keescook@chromium.org>
Cc: 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>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: [kernel-hardening] Re: [RFC][PATCH 7/7] lkdtm: Add READ_AFTER_FREE test
Date: Tue, 5 Jan 2016 18:49:32 -0800 [thread overview]
Message-ID: <568C80BC.4080507@labbott.name> (raw)
In-Reply-To: <CAGXu5jKZTg9jfg9CtXxjDOO_DDBW=c5iyLtkfJr7zAqzxWgQ4Q@mail.gmail.com>
On 1/5/16 4:15 PM, Kees Cook wrote:
> On Mon, Dec 21, 2015 at 7:40 PM, Laura Abbott <laura@labbott.name> wrote:
>>
>> In a similar manner to WRITE_AFTER_FREE, add a READ_AFTER_FREE
>> test to test free poisoning features. Sample output when
>> no poison is present:
>>
>> [ 20.222501] lkdtm: Performing direct entry READ_AFTER_FREE
>> [ 20.226163] lkdtm: Freed val: 12345678
>>
>> with poison:
>>
>> [ 24.203748] lkdtm: Performing direct entry READ_AFTER_FREE
>> [ 24.207261] general protection fault: 0000 [#1] SMP
>> [ 24.208193] Modules linked in:
>> [ 24.208193] CPU: 0 PID: 866 Comm: sh Not tainted 4.4.0-rc5-work+ #108
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Laura Abbott <laura@labbott.name>
>> ---
>> drivers/misc/lkdtm.c | 29 +++++++++++++++++++++++++++++
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
>> index 11fdadc..c641fb7 100644
>> --- a/drivers/misc/lkdtm.c
>> +++ b/drivers/misc/lkdtm.c
>> @@ -92,6 +92,7 @@ enum ctype {
>> CT_UNALIGNED_LOAD_STORE_WRITE,
>> CT_OVERWRITE_ALLOCATION,
>> CT_WRITE_AFTER_FREE,
>> + CT_READ_AFTER_FREE,
>> CT_SOFTLOCKUP,
>> CT_HARDLOCKUP,
>> CT_SPINLOCKUP,
>> @@ -129,6 +130,7 @@ static char* cp_type[] = {
>> "UNALIGNED_LOAD_STORE_WRITE",
>> "OVERWRITE_ALLOCATION",
>> "WRITE_AFTER_FREE",
>> + "READ_AFTER_FREE",
>> "SOFTLOCKUP",
>> "HARDLOCKUP",
>> "SPINLOCKUP",
>> @@ -417,6 +419,33 @@ static void lkdtm_do_action(enum ctype which)
>> memset(data, 0x78, len);
>> break;
>> }
>> + case CT_READ_AFTER_FREE: {
>> + int **base;
>> + int *val, *tmp;
>> +
>> + base = kmalloc(1024, GFP_KERNEL);
>> + if (!base)
>> + return;
>> +
>> + val = kmalloc(1024, GFP_KERNEL);
>> + if (!val)
>> + return;
>
> For both of these test failure return, I think there should be a
> pr_warn too (see CT_EXEC_USERSPACE).
>
I was going by the usual rule that messages on memory failures are
redundant because something somewhere else is going to be printing
out error messages.
>> +
>> + *val = 0x12345678;
>> +
>> + /*
>> + * Don't just use the first entry since that's where the
>> + * freelist goes for the slab allocator
>> + */
>> + base[1] = val;
>
> Maybe just aim at the middle, in case allocator freelist tracking ever
> grows? base[1024/sizeof(int)/2] or something?
>
Good point.
>> + kfree(base);
>> +
>> + tmp = base[1];
>> + pr_info("Freed val: %x\n", *tmp);
>
> Instead of depending on the deref to fail, maybe just use a simple
> BUG_ON to test that the value did actually change? Or, change the
> pr_info to "Failed to Oops when reading freed value: ..." just to be
> slightly more verbose about what failed?
>
I'll come up with something to be more explicit here.
Thanks,
Laura
WARNING: multiple messages have this Message-ID (diff)
From: Laura Abbott <laura@labbott.name>
To: Kees Cook <keescook@chromium.org>
Cc: 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>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [RFC][PATCH 7/7] lkdtm: Add READ_AFTER_FREE test
Date: Tue, 5 Jan 2016 18:49:32 -0800 [thread overview]
Message-ID: <568C80BC.4080507@labbott.name> (raw)
In-Reply-To: <CAGXu5jKZTg9jfg9CtXxjDOO_DDBW=c5iyLtkfJr7zAqzxWgQ4Q@mail.gmail.com>
On 1/5/16 4:15 PM, Kees Cook wrote:
> On Mon, Dec 21, 2015 at 7:40 PM, Laura Abbott <laura@labbott.name> wrote:
>>
>> In a similar manner to WRITE_AFTER_FREE, add a READ_AFTER_FREE
>> test to test free poisoning features. Sample output when
>> no poison is present:
>>
>> [ 20.222501] lkdtm: Performing direct entry READ_AFTER_FREE
>> [ 20.226163] lkdtm: Freed val: 12345678
>>
>> with poison:
>>
>> [ 24.203748] lkdtm: Performing direct entry READ_AFTER_FREE
>> [ 24.207261] general protection fault: 0000 [#1] SMP
>> [ 24.208193] Modules linked in:
>> [ 24.208193] CPU: 0 PID: 866 Comm: sh Not tainted 4.4.0-rc5-work+ #108
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Laura Abbott <laura@labbott.name>
>> ---
>> drivers/misc/lkdtm.c | 29 +++++++++++++++++++++++++++++
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
>> index 11fdadc..c641fb7 100644
>> --- a/drivers/misc/lkdtm.c
>> +++ b/drivers/misc/lkdtm.c
>> @@ -92,6 +92,7 @@ enum ctype {
>> CT_UNALIGNED_LOAD_STORE_WRITE,
>> CT_OVERWRITE_ALLOCATION,
>> CT_WRITE_AFTER_FREE,
>> + CT_READ_AFTER_FREE,
>> CT_SOFTLOCKUP,
>> CT_HARDLOCKUP,
>> CT_SPINLOCKUP,
>> @@ -129,6 +130,7 @@ static char* cp_type[] = {
>> "UNALIGNED_LOAD_STORE_WRITE",
>> "OVERWRITE_ALLOCATION",
>> "WRITE_AFTER_FREE",
>> + "READ_AFTER_FREE",
>> "SOFTLOCKUP",
>> "HARDLOCKUP",
>> "SPINLOCKUP",
>> @@ -417,6 +419,33 @@ static void lkdtm_do_action(enum ctype which)
>> memset(data, 0x78, len);
>> break;
>> }
>> + case CT_READ_AFTER_FREE: {
>> + int **base;
>> + int *val, *tmp;
>> +
>> + base = kmalloc(1024, GFP_KERNEL);
>> + if (!base)
>> + return;
>> +
>> + val = kmalloc(1024, GFP_KERNEL);
>> + if (!val)
>> + return;
>
> For both of these test failure return, I think there should be a
> pr_warn too (see CT_EXEC_USERSPACE).
>
I was going by the usual rule that messages on memory failures are
redundant because something somewhere else is going to be printing
out error messages.
>> +
>> + *val = 0x12345678;
>> +
>> + /*
>> + * Don't just use the first entry since that's where the
>> + * freelist goes for the slab allocator
>> + */
>> + base[1] = val;
>
> Maybe just aim at the middle, in case allocator freelist tracking ever
> grows? base[1024/sizeof(int)/2] or something?
>
Good point.
>> + kfree(base);
>> +
>> + tmp = base[1];
>> + pr_info("Freed val: %x\n", *tmp);
>
> Instead of depending on the deref to fail, maybe just use a simple
> BUG_ON to test that the value did actually change? Or, change the
> pr_info to "Failed to Oops when reading freed value: ..." just to be
> slightly more verbose about what failed?
>
I'll come up with something to be more explicit here.
Thanks,
Laura
--
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: Laura Abbott <laura@labbott.name>
To: Kees Cook <keescook@chromium.org>
Cc: 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>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [RFC][PATCH 7/7] lkdtm: Add READ_AFTER_FREE test
Date: Tue, 5 Jan 2016 18:49:32 -0800 [thread overview]
Message-ID: <568C80BC.4080507@labbott.name> (raw)
In-Reply-To: <CAGXu5jKZTg9jfg9CtXxjDOO_DDBW=c5iyLtkfJr7zAqzxWgQ4Q@mail.gmail.com>
On 1/5/16 4:15 PM, Kees Cook wrote:
> On Mon, Dec 21, 2015 at 7:40 PM, Laura Abbott <laura@labbott.name> wrote:
>>
>> In a similar manner to WRITE_AFTER_FREE, add a READ_AFTER_FREE
>> test to test free poisoning features. Sample output when
>> no poison is present:
>>
>> [ 20.222501] lkdtm: Performing direct entry READ_AFTER_FREE
>> [ 20.226163] lkdtm: Freed val: 12345678
>>
>> with poison:
>>
>> [ 24.203748] lkdtm: Performing direct entry READ_AFTER_FREE
>> [ 24.207261] general protection fault: 0000 [#1] SMP
>> [ 24.208193] Modules linked in:
>> [ 24.208193] CPU: 0 PID: 866 Comm: sh Not tainted 4.4.0-rc5-work+ #108
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Laura Abbott <laura@labbott.name>
>> ---
>> drivers/misc/lkdtm.c | 29 +++++++++++++++++++++++++++++
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
>> index 11fdadc..c641fb7 100644
>> --- a/drivers/misc/lkdtm.c
>> +++ b/drivers/misc/lkdtm.c
>> @@ -92,6 +92,7 @@ enum ctype {
>> CT_UNALIGNED_LOAD_STORE_WRITE,
>> CT_OVERWRITE_ALLOCATION,
>> CT_WRITE_AFTER_FREE,
>> + CT_READ_AFTER_FREE,
>> CT_SOFTLOCKUP,
>> CT_HARDLOCKUP,
>> CT_SPINLOCKUP,
>> @@ -129,6 +130,7 @@ static char* cp_type[] = {
>> "UNALIGNED_LOAD_STORE_WRITE",
>> "OVERWRITE_ALLOCATION",
>> "WRITE_AFTER_FREE",
>> + "READ_AFTER_FREE",
>> "SOFTLOCKUP",
>> "HARDLOCKUP",
>> "SPINLOCKUP",
>> @@ -417,6 +419,33 @@ static void lkdtm_do_action(enum ctype which)
>> memset(data, 0x78, len);
>> break;
>> }
>> + case CT_READ_AFTER_FREE: {
>> + int **base;
>> + int *val, *tmp;
>> +
>> + base = kmalloc(1024, GFP_KERNEL);
>> + if (!base)
>> + return;
>> +
>> + val = kmalloc(1024, GFP_KERNEL);
>> + if (!val)
>> + return;
>
> For both of these test failure return, I think there should be a
> pr_warn too (see CT_EXEC_USERSPACE).
>
I was going by the usual rule that messages on memory failures are
redundant because something somewhere else is going to be printing
out error messages.
>> +
>> + *val = 0x12345678;
>> +
>> + /*
>> + * Don't just use the first entry since that's where the
>> + * freelist goes for the slab allocator
>> + */
>> + base[1] = val;
>
> Maybe just aim at the middle, in case allocator freelist tracking ever
> grows? base[1024/sizeof(int)/2] or something?
>
Good point.
>> + kfree(base);
>> +
>> + tmp = base[1];
>> + pr_info("Freed val: %x\n", *tmp);
>
> Instead of depending on the deref to fail, maybe just use a simple
> BUG_ON to test that the value did actually change? Or, change the
> pr_info to "Failed to Oops when reading freed value: ..." just to be
> slightly more verbose about what failed?
>
I'll come up with something to be more explicit here.
Thanks,
Laura
next prev parent reply other threads:[~2016-01-06 2:49 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-22 3:40 [kernel-hardening] [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` [kernel-hardening] [RFC][PATCH 1/7] mm/slab_common.c: Add common support for slab saniziation Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 20:48 ` [kernel-hardening] " Vlastimil Babka
2015-12-22 20:48 ` Vlastimil Babka
2015-12-22 20:48 ` Vlastimil Babka
2016-01-06 0:17 ` [kernel-hardening] " Kees Cook
2016-01-06 0:17 ` Kees Cook
2016-01-06 0:17 ` Kees Cook
2016-01-06 2:06 ` [kernel-hardening] " Laura Abbott
2016-01-06 2:06 ` Laura Abbott
2016-01-06 2:06 ` Laura Abbott
2016-01-06 0:19 ` [kernel-hardening] " Kees Cook
2016-01-06 0:19 ` Kees Cook
2016-01-06 0:19 ` Kees Cook
2015-12-22 3:40 ` [kernel-hardening] [RFC][PATCH 2/7] slub: Add support for sanitization Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` [kernel-hardening] [RFC][PATCH 3/7] slab: " Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` [kernel-hardening] [RFC][PATCH 4/7] slob: " Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` [kernel-hardening] [RFC][PATCH 5/7] mm: Mark several cases as SLAB_NO_SANITIZE Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2016-01-06 0:21 ` [kernel-hardening] " Kees Cook
2016-01-06 0:21 ` Kees Cook
2016-01-06 0:21 ` Kees Cook
2016-01-06 2:11 ` [kernel-hardening] " Laura Abbott
2016-01-06 2:11 ` Laura Abbott
2016-01-06 2:11 ` Laura Abbott
2015-12-22 3:40 ` [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 9:33 ` [kernel-hardening] " Mathias Krause
2015-12-22 9:33 ` Mathias Krause
2015-12-22 17:51 ` Laura Abbott
2015-12-22 17:51 ` Laura Abbott
2015-12-22 18:37 ` Mathias Krause
2015-12-22 18:37 ` Mathias Krause
2015-12-22 19:18 ` Laura Abbott
2015-12-22 19:18 ` Laura Abbott
2015-12-22 20:01 ` Christoph Lameter
2015-12-22 20:01 ` Christoph Lameter
2015-12-22 20:06 ` Mathias Krause
2015-12-22 20:06 ` Mathias Krause
2015-12-22 14:57 ` Dave Hansen
2015-12-22 14:57 ` Dave Hansen
2015-12-22 16:25 ` Christoph Lameter
2015-12-22 16:25 ` Christoph Lameter
2015-12-22 17:22 ` Dave Hansen
2015-12-22 17:24 ` Christoph Lameter
2015-12-22 17:28 ` Dave Hansen
2015-12-22 17:28 ` Dave Hansen
2015-12-22 18:08 ` Christoph Lameter
2015-12-22 18:08 ` Christoph Lameter
2015-12-22 18:19 ` Dave Hansen
2015-12-22 18:19 ` Dave Hansen
2015-12-22 19:13 ` Laura Abbott
2015-12-22 19:13 ` Laura Abbott
2015-12-22 19:32 ` Dave Hansen
2015-12-22 19:32 ` Dave Hansen
2016-01-06 0:29 ` Kees Cook
2016-01-06 0:29 ` Kees Cook
2016-01-06 2:46 ` Laura Abbott
2016-01-06 2:46 ` Laura Abbott
2015-12-22 3:40 ` [kernel-hardening] [RFC][PATCH 7/7] lkdtm: Add READ_AFTER_FREE test Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2015-12-22 3:40 ` Laura Abbott
2016-01-06 0:15 ` [kernel-hardening] " Kees Cook
2016-01-06 0:15 ` Kees Cook
2016-01-06 0:15 ` Kees Cook
2016-01-06 2:49 ` Laura Abbott [this message]
2016-01-06 2:49 ` Laura Abbott
2016-01-06 2:49 ` Laura Abbott
2015-12-22 16:08 ` [kernel-hardening] Re: [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX Christoph Lameter
2015-12-22 16:08 ` Christoph Lameter
2015-12-22 16:08 ` Christoph Lameter
2015-12-22 16:15 ` [kernel-hardening] " Dave Hansen
2015-12-22 16:15 ` Dave Hansen
2015-12-22 16:38 ` Daniel Micay
2015-12-22 20:04 ` Laura Abbott
2015-12-22 20:04 ` Laura Abbott
2015-12-22 20:04 ` Laura Abbott
2016-01-06 0:09 ` [kernel-hardening] " Kees Cook
2016-01-06 0:09 ` Kees Cook
2016-01-06 0:09 ` Kees Cook
2016-01-06 3:17 ` [kernel-hardening] " Laura Abbott
2016-01-06 3:17 ` Laura Abbott
2016-01-06 3:17 ` Laura Abbott
2016-01-07 16:26 ` [kernel-hardening] " Christoph Lameter
2016-01-07 16:26 ` Christoph Lameter
2016-01-07 16:26 ` Christoph Lameter
2016-01-08 1:23 ` [kernel-hardening] " Laura Abbott
2016-01-08 1:23 ` Laura Abbott
2016-01-08 1:23 ` Laura Abbott
2016-01-08 14:07 ` [kernel-hardening] " Christoph Lameter
2016-01-08 14:07 ` Christoph Lameter
2016-01-08 14:07 ` Christoph Lameter
2016-01-14 3:49 ` [kernel-hardening] " Laura Abbott
2016-01-14 3:49 ` Laura Abbott
2016-01-14 3:49 ` Laura Abbott
2016-01-21 3:35 ` [kernel-hardening] " Laura Abbott
2016-01-21 3:35 ` Laura Abbott
2016-01-21 3:35 ` Laura Abbott
2016-01-21 15:39 ` [kernel-hardening] " Christoph Lameter
2016-01-21 15:39 ` Christoph Lameter
2016-01-21 15:39 ` Christoph Lameter
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=568C80BC.4080507@labbott.name \
--to=laura@labbott.name \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=cl@linux.com \
--cc=gregkh@linuxfoundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.