From: Kees Cook <keescook@chromium.org> To: Laura Abbott <labbott@redhat.com> Cc: Laura Abbott <labbott@fedoraproject.org>, 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: Thu, 25 Feb 2016 09:35:52 -0800 [thread overview] Message-ID: <CAGXu5jLWqyhspaeoMs+UBu34340OfmKB8EpWRab5=c1uHwKRqw@mail.gmail.com> (raw) In-Reply-To: <56CE58BA.3080900@redhat.com> On Wed, Feb 24, 2016 at 5:28 PM, Laura Abbott <labbott@redhat.com> wrote: > On 02/24/2016 03:37 PM, Kees Cook wrote: >> >> On Wed, Feb 24, 2016 at 1:48 PM, Kees Cook <keescook@chromium.org> wrote: >>> >>> On Wed, Feb 24, 2016 at 11:40 AM, Laura Abbott <labbott@redhat.com> >>> wrote: >>>> >>>> Yep, looks like the v1 patches and not the v2 patches which fix >>>> a known issue with the zeroing. >>> >>> >>> Ah-ha, I'll go find those and retest. >> >> >> I sent out a series that was rebased. It works for me, but I want to >> make sure I didn't make any glaring issues. I've also sent some fixes >> to the lkdtm tests. One thing that stands out to me still is that the >> READ_AFTER_FREE never shows poisoning. I remain confused, since >> obviously if zeroing is working, it's being correctly poisoned... >> >> -Kees >> > > I'll review the rebased series you sent out for the page poisoning patches. > If it's okay with you, I'll pull in the updates to the LKDTM test. Yes, please feel free! > If you > test with slub_debug=P on the command line do you see the READ_AFTER_FREE > test working as expected? Setting that on the command line will set up > the poisoning which should make the READ_AFTER_FREE test fail. Ah-ha, yes, that was one of the missing pieces: [ 10.790970] lkdtm: Performing direct entry READ_AFTER_FREE [ 10.790992] lkdtm: Value in memory before free: 12345678 [ 10.790996] lkdtm: Attempting bad read from freed memory [ 10.790998] lkdtm: Memory correctly poisoned, calling BUG [ 10.791067] ------------[ cut here ]------------ [ 10.792037] kernel BUG at drivers/misc/lkdtm.c:465! I see that "F" is also needed to do the sanity checks, but the poison ends up being different again from what I was expected: [ 8.643902] lkdtm: Performing direct entry WRITE_AFTER_FREE [ 8.645215] lkdtm: Allocated memory ffff88007b446850-ffff88007b446c50 [ 8.646700] lkdtm: Attempting bad write to freed memory at ffff88007b446a50 [ 8.648295] ============================================================================= [ 8.649275] BUG kmalloc-1024 (Tainted: G D ): Poison overwritten [ 8.649275] ----------------------------------------------------------------------------- [ 8.649275] [ 8.649275] INFO: 0xffff88007b446a50-0xffff88007b446a53. First byte 0xf0 instead of 0x6b 0x6b is POISON_FREE: #define POISON_INUSE 0x5a /* for use-uninitialised poisoning */ #define POISON_FREE 0x6b /* for use-after-free poisoning */ #define POISON_END 0xa5 /* end-byte of poisoning */ So it seems like there are separate poisonings going on? Modifying READ_AFTER_FREE a bit more, I see that it looks like only the buddy allocator is getting the zero poisoning? [ 61.755450] lkdtm: Performing direct entry READ_AFTER_FREE [ 61.757436] lkdtm: Value in memory before free: 12345678 [ 61.759390] lkdtm: Attempting bad read from freed memory [ 61.761649] lkdtm: Memory correctly poisoned (6b6b6b6b) [ 62.139408] lkdtm: Performing direct entry READ_BUDDY_AFTER_FREE [ 62.140766] lkdtm: Value in memory before free: 12345678 [ 62.141989] lkdtm: Attempting to read from freed memory [ 62.143225] lkdtm: Memory correctly poisoned (0) Once this series is in, we need to find a way to make a single CONFIG to be more friendly than needing to add "page_poison=on slub_debug=FP" to the command line. :) -Kees -- Kees Cook Chrome OS & Brillo Security
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org> To: Laura Abbott <labbott@redhat.com> Cc: Laura Abbott <labbott@fedoraproject.org>, 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: Thu, 25 Feb 2016 09:35:52 -0800 [thread overview] Message-ID: <CAGXu5jLWqyhspaeoMs+UBu34340OfmKB8EpWRab5=c1uHwKRqw@mail.gmail.com> (raw) In-Reply-To: <56CE58BA.3080900@redhat.com> On Wed, Feb 24, 2016 at 5:28 PM, Laura Abbott <labbott@redhat.com> wrote: > On 02/24/2016 03:37 PM, Kees Cook wrote: >> >> On Wed, Feb 24, 2016 at 1:48 PM, Kees Cook <keescook@chromium.org> wrote: >>> >>> On Wed, Feb 24, 2016 at 11:40 AM, Laura Abbott <labbott@redhat.com> >>> wrote: >>>> >>>> Yep, looks like the v1 patches and not the v2 patches which fix >>>> a known issue with the zeroing. >>> >>> >>> Ah-ha, I'll go find those and retest. >> >> >> I sent out a series that was rebased. It works for me, but I want to >> make sure I didn't make any glaring issues. I've also sent some fixes >> to the lkdtm tests. One thing that stands out to me still is that the >> READ_AFTER_FREE never shows poisoning. I remain confused, since >> obviously if zeroing is working, it's being correctly poisoned... >> >> -Kees >> > > I'll review the rebased series you sent out for the page poisoning patches. > If it's okay with you, I'll pull in the updates to the LKDTM test. Yes, please feel free! > If you > test with slub_debug=P on the command line do you see the READ_AFTER_FREE > test working as expected? Setting that on the command line will set up > the poisoning which should make the READ_AFTER_FREE test fail. Ah-ha, yes, that was one of the missing pieces: [ 10.790970] lkdtm: Performing direct entry READ_AFTER_FREE [ 10.790992] lkdtm: Value in memory before free: 12345678 [ 10.790996] lkdtm: Attempting bad read from freed memory [ 10.790998] lkdtm: Memory correctly poisoned, calling BUG [ 10.791067] ------------[ cut here ]------------ [ 10.792037] kernel BUG at drivers/misc/lkdtm.c:465! I see that "F" is also needed to do the sanity checks, but the poison ends up being different again from what I was expected: [ 8.643902] lkdtm: Performing direct entry WRITE_AFTER_FREE [ 8.645215] lkdtm: Allocated memory ffff88007b446850-ffff88007b446c50 [ 8.646700] lkdtm: Attempting bad write to freed memory at ffff88007b446a50 [ 8.648295] ============================================================================= [ 8.649275] BUG kmalloc-1024 (Tainted: G D ): Poison overwritten [ 8.649275] ----------------------------------------------------------------------------- [ 8.649275] [ 8.649275] INFO: 0xffff88007b446a50-0xffff88007b446a53. First byte 0xf0 instead of 0x6b 0x6b is POISON_FREE: #define POISON_INUSE 0x5a /* for use-uninitialised poisoning */ #define POISON_FREE 0x6b /* for use-after-free poisoning */ #define POISON_END 0xa5 /* end-byte of poisoning */ So it seems like there are separate poisonings going on? Modifying READ_AFTER_FREE a bit more, I see that it looks like only the buddy allocator is getting the zero poisoning? [ 61.755450] lkdtm: Performing direct entry READ_AFTER_FREE [ 61.757436] lkdtm: Value in memory before free: 12345678 [ 61.759390] lkdtm: Attempting bad read from freed memory [ 61.761649] lkdtm: Memory correctly poisoned (6b6b6b6b) [ 62.139408] lkdtm: Performing direct entry READ_BUDDY_AFTER_FREE [ 62.140766] lkdtm: Value in memory before free: 12345678 [ 62.141989] lkdtm: Attempting to read from freed memory [ 62.143225] lkdtm: Memory correctly poisoned (0) Once this series is in, we need to find a way to make a single CONFIG to be more friendly than needing to add "page_poison=on slub_debug=FP" to the command line. :) -Kees -- Kees Cook Chrome OS & Brillo Security
next prev parent reply other threads:[~2016-02-25 17:35 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-02-19 1:15 [PATCHv2] lkdtm: Add READ_AFTER_FREE test Laura Abbott 2016-02-19 1:15 ` [kernel-hardening] " Laura Abbott 2016-02-19 19:12 ` Kees Cook 2016-02-19 19:12 ` [kernel-hardening] " Kees Cook 2016-02-19 22:11 ` Laura Abbott 2016-02-19 22:11 ` [kernel-hardening] " Laura Abbott 2016-02-19 22:19 ` Kees Cook 2016-02-19 22:19 ` [kernel-hardening] " Kees Cook 2016-02-19 23:07 ` Laura Abbott 2016-02-19 23:07 ` [kernel-hardening] " Laura Abbott 2016-02-22 19:27 ` Kees Cook 2016-02-22 19:27 ` [kernel-hardening] " Kees Cook 2016-02-22 22:06 ` Laura Abbott 2016-02-22 22:06 ` [kernel-hardening] " Laura Abbott 2016-02-23 21:25 ` Kees Cook 2016-02-23 21:25 ` [kernel-hardening] " Kees Cook 2016-02-23 22:37 ` Kees Cook 2016-02-23 22:37 ` [kernel-hardening] " Kees Cook 2016-02-24 18:59 ` Laura Abbott 2016-02-24 18:59 ` [kernel-hardening] " Laura Abbott 2016-02-24 17:22 ` Kees Cook 2016-02-24 17:22 ` [kernel-hardening] " Kees Cook 2016-02-24 19:40 ` Laura Abbott 2016-02-24 19:40 ` [kernel-hardening] " Laura Abbott 2016-02-24 21:48 ` Kees Cook 2016-02-24 21:48 ` [kernel-hardening] " Kees Cook 2016-02-24 23:37 ` Kees Cook 2016-02-24 23:37 ` [kernel-hardening] " Kees Cook 2016-02-25 1:28 ` Laura Abbott 2016-02-25 1:28 ` [kernel-hardening] " Laura Abbott 2016-02-25 17:35 ` Kees Cook [this message] 2016-02-25 17:35 ` Kees Cook 2016-02-25 23:15 ` Laura Abbott 2016-02-25 23:15 ` [kernel-hardening] " Laura Abbott 2016-02-26 16:03 ` Kees Cook 2016-02-26 16:03 ` [kernel-hardening] " Kees Cook 2016-02-26 22:19 ` Laura Abbott 2016-02-26 22:19 ` [kernel-hardening] " Laura Abbott 2016-02-26 22:33 ` Kees Cook 2016-02-26 22:33 ` [kernel-hardening] " Kees Cook 2016-03-01 1:37 ` Laura Abbott 2016-03-01 1:37 ` [kernel-hardening] " 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='CAGXu5jLWqyhspaeoMs+UBu34340OfmKB8EpWRab5=c1uHwKRqw@mail.gmail.com' \ --to=keescook@chromium.org \ --cc=arnd@arndb.de \ --cc=gregkh@linuxfoundation.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=labbott@fedoraproject.org \ --cc=labbott@redhat.com \ --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: linkBe 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.