From: Laura Abbott <labbott@redhat.com>
To: Sasha Levin <sasha.levin@oracle.com>,
Laura Abbott <labbott@fedoraproject.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com,
Kees Cook <keescook@chromium.org>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>
Subject: Re: [RFC][PATCH 0/3] Sanitization of buddy pages
Date: Tue, 26 Jan 2016 12:34:21 -0800 [thread overview]
Message-ID: <56A7D84D.7020101@redhat.com> (raw)
In-Reply-To: <56A70C9D.8060102@oracle.com>
On 01/25/2016 10:05 PM, Sasha Levin wrote:
> On 01/25/2016 11:55 AM, Laura Abbott wrote:
>> Hi,
>>
>> This is an implementation of page poisoning/sanitization for all arches. It
>> takes advantage of the existing implementation for
>> !ARCH_SUPPORTS_DEBUG_PAGEALLOC arches. This is a different approach than what
>> the Grsecurity patches were taking but should provide equivalent functionality.
>>
>> For those who aren't familiar with this, the goal of sanitization is to reduce
>> the severity of use after free and uninitialized data bugs. Memory is cleared
>> on free so any sensitive data is no longer available. Discussion of
>> sanitization was brough up in a thread about CVEs
>> (lkml.kernel.org/g/<20160119112812.GA10818@mwanda>)
>>
>> I eventually expect Kconfig names will want to be changed and or moved if this
>> is going to be used for security but that can happen later.
>>
>> Credit to Mathias Krause for the version in grsecurity
>>
>> Laura Abbott (3):
>> mm/debug-pagealloc.c: Split out page poisoning from debug page_alloc
>> mm/page_poison.c: Enable PAGE_POISONING as a separate option
>> mm/page_poisoning.c: Allow for zero poisoning
>>
>> Documentation/kernel-parameters.txt | 5 ++
>> include/linux/mm.h | 13 +++
>> include/linux/poison.h | 4 +
>> mm/Kconfig.debug | 35 +++++++-
>> mm/Makefile | 5 +-
>> mm/debug-pagealloc.c | 127 +----------------------------
>> mm/page_alloc.c | 10 ++-
>> mm/page_poison.c | 158 ++++++++++++++++++++++++++++++++++++
>> 8 files changed, 228 insertions(+), 129 deletions(-)
>> create mode 100644 mm/page_poison.c
>>
>
> Should poisoning of this kind be using kasan rather than "old fashioned"
> poisoning?
>
>
The two aren't mutually exclusive. kasan is serving a different purpose even
though it has sanitize in the name. kasan is designed to detect errors, the
purpose of this series is to make sure the memory is really cleared out.
This series also doesn't have the memory overhead of kasan.
> Thanks,
> Sasha
>
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>
next prev parent reply other threads:[~2016-01-26 20:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 16:55 [RFC][PATCH 0/3] Sanitization of buddy pages Laura Abbott
2016-01-25 16:55 ` [RFC][PATCH 1/3] mm/debug-pagealloc.c: Split out page poisoning from debug page_alloc Laura Abbott
2016-01-26 6:26 ` Jianyu Zhan
2016-01-26 20:25 ` Laura Abbott
2016-01-25 16:55 ` [RFC][PATCH 2/3] mm/page_poison.c: Enable PAGE_POISONING as a separate option Laura Abbott
2016-01-26 6:39 ` Jianyu Zhan
2016-01-26 20:27 ` Laura Abbott
2016-01-25 16:55 ` [RFC][PATCH 3/3] mm/page_poisoning.c: Allow for zero poisoning Laura Abbott
2016-01-25 20:16 ` [kernel-hardening] " Dave Hansen
2016-01-25 22:05 ` Kees Cook
2016-01-26 1:33 ` Laura Abbott
2016-01-26 6:05 ` [RFC][PATCH 0/3] Sanitization of buddy pages Sasha Levin
2016-01-26 20:34 ` Laura Abbott [this message]
2016-01-26 9:08 ` [kernel-hardening] " Mathias Krause
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=56A7D84D.7020101@redhat.com \
--to=labbott@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=labbott@fedoraproject.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=ryabinin.a.a@gmail.com \
--cc=sasha.levin@oracle.com \
--cc=vbabka@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).