All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laura Abbott <labbott@redhat.com>
To: Kees Cook <keescook@chromium.org>,
	Laura Abbott <labbott@fedoraproject.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: [kernel-hardening] Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test
Date: Fri, 19 Feb 2016 14:11:13 -0800	[thread overview]
Message-ID: <56C79301.5040003@redhat.com> (raw)
In-Reply-To: <CAGXu5jLREPiCHSwk1LGKJm0pPGpD8O4S+4xu5=Aw_x+COLBXWg@mail.gmail.com>

On 02/19/2016 11:12 AM, Kees Cook wrote:
> On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott <labbott@fedoraproject.org> wrote:
>>
>> In a similar manner to WRITE_AFTER_FREE, add a READ_AFTER_FREE
>> test to test free poisoning features. Sample output when
>> no sanitization is present:
>>
>> [   22.414170] lkdtm: Performing direct entry READ_AFTER_FREE
>> [   22.415124] lkdtm: Value in memory before free: 12345678
>> [   22.415900] lkdtm: Attempting to read from freed memory
>> [   22.416394] lkdtm: Successfully read value: 12345678
>>
>> with sanitization:
>>
>> [   25.874585] lkdtm: Performing direct entry READ_AFTER_FREE
>> [   25.875527] lkdtm: Value in memory before free: 12345678
>> [   25.876382] lkdtm: Attempting to read from freed memory
>> [   25.876900] general protection fault: 0000 [#1] SMP
>>
>> Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
>
> Excellent! Could you mention in the changelog which CONFIG (or runtime
> values) will change the lkdtm test? (I thought there was a poisoning
> style that would result in a zero-read instead of a GP?)
>

There was a zeroing patch in the first draft but given the direction
things are going, I don't see it going in. I'll mention the debug
options which will show this though.

> -Kees
>
>> ---
>> I split this out from the previous series
>> (http://article.gmane.org/gmane.linux.kernel.mm/143486) since
>> that series is going to be going in more incrementally.
>> Having the test in sooner than later will be helpful I think
>>
>> v2: Tweaked the output text to be clearer about what's going on.
>> Switched to using the middle of an allocated block instead of the beginning.
>> ---
>>   drivers/misc/lkdtm.c | 34 ++++++++++++++++++++++++++++++++++
>>   1 file changed, 34 insertions(+)
>>
>> diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
>> index 11fdadc..24d0ac7 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,38 @@ static void lkdtm_do_action(enum ctype which)
>>                  memset(data, 0x78, len);
>>                  break;
>>          }
>> +       case CT_READ_AFTER_FREE: {
>> +               int **base;
>> +               int *val, *tmp;
>> +               size_t len = 1024;
>> +               /*
>> +                * The slub allocator uses the first word to store the free
>> +                * pointer in some configurations. Use the middle of the
>> +                * allocation to avoid running into the freelist
>> +                */
>> +               size_t offset = (len/sizeof(int *))/2;
>> +
>> +               base = kmalloc(len, GFP_KERNEL);
>> +               if (!base)
>> +                       return;
>> +
>> +               val = kmalloc(len, GFP_KERNEL);
>> +               if (!val)
>> +                       return;
>> +
>> +               *val = 0x12345678;
>> +               pr_info("Value in memory before free: %x\n", *val);
>> +
>> +               base[offset] = val;
>> +               kfree(base);
>> +
>> +               tmp = base[offset];
>> +               pr_info("Attempting to read from freed memory");
>> +               pr_info("Successfully read value: %x\n", *tmp);
>> +
>> +               kfree(val);
>> +               break;
>> +       }
>>          case CT_SOFTLOCKUP:
>>                  preempt_disable();
>>                  for (;;)
>> --
>> 2.5.0
>>
>
>
>

WARNING: multiple messages have this Message-ID (diff)
From: Laura Abbott <labbott@redhat.com>
To: Kees Cook <keescook@chromium.org>,
	Laura Abbott <labbott@fedoraproject.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test
Date: Fri, 19 Feb 2016 14:11:13 -0800	[thread overview]
Message-ID: <56C79301.5040003@redhat.com> (raw)
In-Reply-To: <CAGXu5jLREPiCHSwk1LGKJm0pPGpD8O4S+4xu5=Aw_x+COLBXWg@mail.gmail.com>

On 02/19/2016 11:12 AM, Kees Cook wrote:
> On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott <labbott@fedoraproject.org> wrote:
>>
>> In a similar manner to WRITE_AFTER_FREE, add a READ_AFTER_FREE
>> test to test free poisoning features. Sample output when
>> no sanitization is present:
>>
>> [   22.414170] lkdtm: Performing direct entry READ_AFTER_FREE
>> [   22.415124] lkdtm: Value in memory before free: 12345678
>> [   22.415900] lkdtm: Attempting to read from freed memory
>> [   22.416394] lkdtm: Successfully read value: 12345678
>>
>> with sanitization:
>>
>> [   25.874585] lkdtm: Performing direct entry READ_AFTER_FREE
>> [   25.875527] lkdtm: Value in memory before free: 12345678
>> [   25.876382] lkdtm: Attempting to read from freed memory
>> [   25.876900] general protection fault: 0000 [#1] SMP
>>
>> Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
>
> Excellent! Could you mention in the changelog which CONFIG (or runtime
> values) will change the lkdtm test? (I thought there was a poisoning
> style that would result in a zero-read instead of a GP?)
>

There was a zeroing patch in the first draft but given the direction
things are going, I don't see it going in. I'll mention the debug
options which will show this though.

> -Kees
>
>> ---
>> I split this out from the previous series
>> (http://article.gmane.org/gmane.linux.kernel.mm/143486) since
>> that series is going to be going in more incrementally.
>> Having the test in sooner than later will be helpful I think
>>
>> v2: Tweaked the output text to be clearer about what's going on.
>> Switched to using the middle of an allocated block instead of the beginning.
>> ---
>>   drivers/misc/lkdtm.c | 34 ++++++++++++++++++++++++++++++++++
>>   1 file changed, 34 insertions(+)
>>
>> diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
>> index 11fdadc..24d0ac7 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,38 @@ static void lkdtm_do_action(enum ctype which)
>>                  memset(data, 0x78, len);
>>                  break;
>>          }
>> +       case CT_READ_AFTER_FREE: {
>> +               int **base;
>> +               int *val, *tmp;
>> +               size_t len = 1024;
>> +               /*
>> +                * The slub allocator uses the first word to store the free
>> +                * pointer in some configurations. Use the middle of the
>> +                * allocation to avoid running into the freelist
>> +                */
>> +               size_t offset = (len/sizeof(int *))/2;
>> +
>> +               base = kmalloc(len, GFP_KERNEL);
>> +               if (!base)
>> +                       return;
>> +
>> +               val = kmalloc(len, GFP_KERNEL);
>> +               if (!val)
>> +                       return;
>> +
>> +               *val = 0x12345678;
>> +               pr_info("Value in memory before free: %x\n", *val);
>> +
>> +               base[offset] = val;
>> +               kfree(base);
>> +
>> +               tmp = base[offset];
>> +               pr_info("Attempting to read from freed memory");
>> +               pr_info("Successfully read value: %x\n", *tmp);
>> +
>> +               kfree(val);
>> +               break;
>> +       }
>>          case CT_SOFTLOCKUP:
>>                  preempt_disable();
>>                  for (;;)
>> --
>> 2.5.0
>>
>
>
>

  reply	other threads:[~2016-02-19 22:11 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-19  1:15 [kernel-hardening] [PATCHv2] lkdtm: Add READ_AFTER_FREE test Laura Abbott
2016-02-19  1:15 ` Laura Abbott
2016-02-19 19:12 ` [kernel-hardening] " Kees Cook
2016-02-19 19:12   ` Kees Cook
2016-02-19 22:11   ` Laura Abbott [this message]
2016-02-19 22:11     ` Laura Abbott
2016-02-19 22:19     ` [kernel-hardening] " Kees Cook
2016-02-19 22:19       ` Kees Cook
2016-02-19 23:07       ` [kernel-hardening] " Laura Abbott
2016-02-19 23:07         ` Laura Abbott
2016-02-22 19:27         ` [kernel-hardening] " Kees Cook
2016-02-22 19:27           ` Kees Cook
2016-02-22 22:06           ` [kernel-hardening] " Laura Abbott
2016-02-22 22:06             ` Laura Abbott
2016-02-23 21:25             ` [kernel-hardening] " Kees Cook
2016-02-23 21:25               ` Kees Cook
2016-02-23 22:37               ` [kernel-hardening] " Kees Cook
2016-02-23 22:37                 ` Kees Cook
2016-02-24 18:59                 ` [kernel-hardening] " Laura Abbott
2016-02-24 18:59                   ` Laura Abbott
2016-02-24 17:22               ` [kernel-hardening] " Kees Cook
2016-02-24 17:22                 ` Kees Cook
2016-02-24 19:40                 ` [kernel-hardening] " Laura Abbott
2016-02-24 19:40                   ` Laura Abbott
2016-02-24 21:48                   ` [kernel-hardening] " Kees Cook
2016-02-24 21:48                     ` Kees Cook
2016-02-24 23:37                     ` [kernel-hardening] " Kees Cook
2016-02-24 23:37                       ` Kees Cook
2016-02-25  1:28                       ` [kernel-hardening] " Laura Abbott
2016-02-25  1:28                         ` Laura Abbott
2016-02-25 17:35                         ` [kernel-hardening] " Kees Cook
2016-02-25 17:35                           ` Kees Cook
2016-02-25 23:15                           ` [kernel-hardening] " Laura Abbott
2016-02-25 23:15                             ` Laura Abbott
2016-02-26 16:03                             ` [kernel-hardening] " Kees Cook
2016-02-26 16:03                               ` Kees Cook
2016-02-26 22:19                               ` [kernel-hardening] " Laura Abbott
2016-02-26 22:19                                 ` Laura Abbott
2016-02-26 22:33                                 ` [kernel-hardening] " Kees Cook
2016-02-26 22:33                                   ` Kees Cook
2016-03-01  1:37                                   ` [kernel-hardening] " Laura Abbott
2016-03-01  1:37                                     ` Laura Abbott

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=56C79301.5040003@redhat.com \
    --to=labbott@redhat.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@fedoraproject.org \
    --cc=linux-kernel@vger.kernel.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: 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.