From: ben.hutchings@codethink.co.uk (Ben Hutchings)
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] [PATCH 4.4-cip 0/5] Faster page poisoning for security
Date: Fri, 09 Dec 2016 00:15:03 +0000 [thread overview]
Message-ID: <1481242503.1860.139.camel@codethink.co.uk> (raw)
This is a backport of changes in 4.6 to add new config options to page
poisoning. Page poisoning was originally intended a debug feature for
finding use-after-free bugs in the kernel, but it can also be a security
feature, mitigating the security impact of such bugs. Unfortunately, it
normally has a significant performance cost. The new options
(CONFIG_PAGE_POISONING_NO_SANITY and CONFIG_PAGE_POISONING_ZERO) can be
enabled to reduce the performance cost, though they also reduce the
likelihood of detecting when such a bug has been triggered.
Enable CONFIG_PAGE_POISONING plus the new options can make some such
bugs harder to exploit, at a small performance cost (you'll need to
measure it yourself).
For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?
Ben.
Joonsoo Kim (3):
mm/slab: activate debug_pagealloc in SLAB when it is actually enabled
mm/slab: use more appropriate condition check for debug_pagealloc
mm/slab: clean up DEBUG_PAGEALLOC processing code
Laura Abbott (2):
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 | 23 ++++++--
include/linux/poison.h | 4 ++
kernel/power/hibernate.c | 17 ++++++
mm/Kconfig.debug | 39 ++++++++++++-
mm/Makefile | 2 +-
mm/page_alloc.c | 13 ++++-
mm/page_ext.c | 10 +++-
mm/{debug-pagealloc.c => page_poison.c} | 67 +++++++++++++++++-----
mm/slab.c | 98 +++++++++++++++++----------------
10 files changed, 208 insertions(+), 70 deletions(-)
rename mm/{debug-pagealloc.c => page_poison.c} (64%)
--
2.10.2
--
Ben Hutchings
Software Developer, Codethink Ltd.
next reply other threads:[~2016-12-09 0:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-09 0:15 Ben Hutchings [this message]
2016-12-09 0:15 ` [cip-dev] [PATCH 4.4-cip 1/5] mm/slab: activate debug_pagealloc in SLAB when it is actually enabled Ben Hutchings
2016-12-09 0:16 ` [cip-dev] [PATCH 4.4-cip 2/5] mm/slab: use more appropriate condition check for debug_pagealloc Ben Hutchings
2016-12-09 0:16 ` [cip-dev] [PATCH 4.4-cip 3/5] mm/slab: clean up DEBUG_PAGEALLOC processing code Ben Hutchings
2016-12-09 0:16 ` [cip-dev] [PATCH 4.4-cip 4/5] mm/page_poison.c: enable PAGE_POISONING as a separate option Ben Hutchings
2016-12-09 0:16 ` [cip-dev] [PATCH 4.4-cip 5/5] mm/page_poisoning.c: allow for zero poisoning Ben Hutchings
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=1481242503.1860.139.camel@codethink.co.uk \
--to=ben.hutchings@codethink.co.uk \
--cc=cip-dev@lists.cip-project.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox