From: Igor Stoppa <igor.stoppa@huawei.com>
To: david@fromorbit.com, willy@infradead.org,
rppt@linux.vnet.ibm.com, keescook@chromium.org,
mhocko@kernel.org
Cc: labbott@redhat.com, linux-security-module@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com,
Igor Stoppa <igor.stoppa@huawei.com>
Subject: [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data
Date: Tue, 13 Mar 2018 23:45:46 +0200 [thread overview]
Message-ID: <20180313214554.28521-1-igor.stoppa@huawei.com> (raw)
This patch-set introduces the possibility of protecting memory that has
been allocated dynamically.
The memory is managed in pools: when a memory pool is turned into R/O,
all the memory that is part of it, will become R/O.
A R/O pool can be destroyed, to recover its memory, but it cannot be
turned back into R/W mode.
This is intentional. This feature is meant for data that doesn't need
further modifications after initialization.
However the data might need to be released, for example as part of module
unloading.
To do this, the memory must first be freed, then the pool can be destroyed.
An example is provided, in the form of self-testing.
Changes since v18:
[http://www.openwall.com/lists/kernel-hardening/2018/02/28/21]
* Code refactoring in pmalloc & genalloc:
- simplify the logic for handling pools before and after sysf init
- reduced section holding mutex on pmalloc list, when adding a pool
- reduced the steps in finding length of an existing allocation
- split various functions into smaller ones
* clarified in the comments the need for pfree()
* Various fixes to the documentation:
- remove kerneldoc duplicates
- added cross-reference lables
- miscellaneous typos
* improved error notifications: use WARNs with specific messages
* added missing tests for possible error conditions
Discussion topics that are unclear if they are closed and would need
comment from those who initiated them, if my answers are accepted or not:
* @Kees Cook proposed to have first self testing for genalloc, to
validate the following patch, adding tracing of allocations
My answer was that such tests would also need patching, therefore they
could not certify that the functionality is corect both before and
after the genalloc bitmap modification.
* @Kees Cook proposed to turn the self testing into modules.
My answer was that the functionality is intentionally tested very early
in the boot phase, to prevent unexplainable errors, should the feature
really fail.
* @Matthew Wilcox proposed to use a different mechanism for th genalloc
bitmap: 2 bitmaps, one for occupation and one for start.
And possibly use an rbtree for the starts.
My answer was that this solution is less optimized, because it scatters
the data of one allocation across multiple words/pages, plus is not
a transaction anymore. And the particular distribution of sizes of
allocation is likely to eat up much more memory than the bitmap.
Igor Stoppa (8):
genalloc: track beginning of allocations
Add label to genalloc.rst for cross reference
genalloc: selftest
struct page: add field for vm_struct
Protectable Memory
Pmalloc selftest
lkdtm: crash on overwriting protected pmalloc var
Documentation for Pmalloc
Documentation/core-api/genalloc.rst | 2 +
Documentation/core-api/index.rst | 1 +
Documentation/core-api/pmalloc.rst | 111 ++++++
drivers/misc/lkdtm.h | 1 +
drivers/misc/lkdtm_core.c | 3 +
drivers/misc/lkdtm_perms.c | 28 ++
include/linux/genalloc.h | 116 +++---
include/linux/mm_types.h | 1 +
include/linux/pmalloc.h | 163 ++++++++
include/linux/test_genalloc.h | 26 ++
include/linux/test_pmalloc.h | 24 ++
include/linux/vmalloc.h | 1 +
init/main.c | 4 +
lib/Kconfig | 15 +
lib/Makefile | 1 +
lib/genalloc.c | 765 ++++++++++++++++++++++++++----------
lib/test_genalloc.c | 410 +++++++++++++++++++
mm/Kconfig | 17 +
mm/Makefile | 2 +
mm/pmalloc.c | 643 ++++++++++++++++++++++++++++++
mm/test_pmalloc.c | 238 +++++++++++
mm/usercopy.c | 33 ++
mm/vmalloc.c | 2 +
23 files changed, 2352 insertions(+), 255 deletions(-)
create mode 100644 Documentation/core-api/pmalloc.rst
create mode 100644 include/linux/pmalloc.h
create mode 100644 include/linux/test_genalloc.h
create mode 100644 include/linux/test_pmalloc.h
create mode 100644 lib/test_genalloc.c
create mode 100644 mm/pmalloc.c
create mode 100644 mm/test_pmalloc.c
--
2.14.1
next reply other threads:[~2018-03-13 21:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-13 21:45 Igor Stoppa [this message]
2018-03-13 21:45 ` [PATCH 1/8] genalloc: track beginning of allocations Igor Stoppa
2018-03-13 21:45 ` [PATCH 2/8] Add label to genalloc.rst for cross reference Igor Stoppa
2018-03-13 21:45 ` [PATCH 3/8] genalloc: selftest Igor Stoppa
2018-03-13 21:45 ` [PATCH 4/8] struct page: add field for vm_struct Igor Stoppa
2018-03-13 22:00 ` Matthew Wilcox
2018-03-14 17:43 ` J Freyensee
2018-03-15 9:38 ` Igor Stoppa
2018-03-15 18:51 ` J Freyensee
2018-03-13 21:45 ` [PATCH 5/8] Protectable Memory Igor Stoppa
2018-03-14 12:15 ` Matthew Wilcox
2018-03-14 13:02 ` Igor Stoppa
2018-03-14 17:40 ` J Freyensee
2018-03-13 21:45 ` [PATCH 6/8] Pmalloc selftest Igor Stoppa
2018-03-14 12:25 ` Matthew Wilcox
2018-03-25 1:32 ` Igor Stoppa
2018-03-13 21:45 ` [PATCH 7/8] lkdtm: crash on overwriting protected pmalloc var Igor Stoppa
2018-03-13 21:45 ` [PATCH 8/8] Documentation for Pmalloc Igor Stoppa
2018-03-14 11:21 ` [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data Igor Stoppa
2018-03-14 11:56 ` Matthew Wilcox
2018-03-14 12:55 ` Igor Stoppa
2018-03-14 13:04 ` Matthew Wilcox
2018-03-14 16:11 ` Igor Stoppa
2018-03-14 17:33 ` Matthew Wilcox
2018-03-15 13:43 ` Igor Stoppa
2018-03-19 18:04 ` Igor Stoppa
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=20180313214554.28521-1-igor.stoppa@huawei.com \
--to=igor.stoppa@huawei.com \
--cc=david@fromorbit.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=rppt@linux.vnet.ibm.com \
--cc=willy@infradead.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