Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1317034 > unrolled thread
| Started by | Laura Abbott <labbott@fedoraproject.org> |
|---|---|
| First post | 2016-01-25 18:00 +0100 |
| Last post | 2016-01-26 10:10 +0100 |
| Articles | 4 — 4 participants |
Back to article view | Back to linux.kernel
[RFC][PATCH 0/3] Sanitization of buddy pages Laura Abbott <labbott@fedoraproject.org> - 2016-01-25 18:00 +0100
Re: [RFC][PATCH 0/3] Sanitization of buddy pages Sasha Levin <sasha.levin@oracle.com> - 2016-01-26 07:10 +0100
Re: [RFC][PATCH 0/3] Sanitization of buddy pages Laura Abbott <labbott@redhat.com> - 2016-01-26 21:40 +0100
Re: [kernel-hardening] [RFC][PATCH 0/3] Sanitization of buddy pages Mathias Krause <minipli@googlemail.com> - 2016-01-26 10:10 +0100
| From | Laura Abbott <labbott@fedoraproject.org> |
|---|---|
| Date | 2016-01-25 18:00 +0100 |
| Subject | [RFC][PATCH 0/3] Sanitization of buddy pages |
| Message-ID | <qUSEG-6QD-11@gated-at.bofh.it> |
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 -- 2.5.0
[toc] | [next] | [standalone]
| From | Sasha Levin <sasha.levin@oracle.com> |
|---|---|
| Date | 2016-01-26 07:10 +0100 |
| Message-ID | <qV4Zb-7Fd-5@gated-at.bofh.it> |
| In reply to | #1317034 |
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? Thanks, Sasha
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2016-01-26 21:40 +0100 |
| Message-ID | <qViz8-10v-3@gated-at.bofh.it> |
| In reply to | #1317549 |
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
[toc] | [prev] | [next] | [standalone]
| From | Mathias Krause <minipli@googlemail.com> |
|---|---|
| Date | 2016-01-26 10:10 +0100 |
| Subject | Re: [kernel-hardening] [RFC][PATCH 0/3] Sanitization of buddy pages |
| Message-ID | <qV7No-1W2-11@gated-at.bofh.it> |
| In reply to | #1317034 |
On 25 January 2016 at 17:55, Laura Abbott <labbott@fedoraproject.org> 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 Thanks for the credits but I don't deserve them. I've contributed the slab based sanitization only. The page based one shipped in PaX and grsecurity is from the PaX Team. > > 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 > > -- > 2.5.0 > Regards, Mathias
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web