LKML Archive on lore.kernel.org help / color / mirror / Atom feed
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: [PATCH 8/8] Documentation for Pmalloc Date: Tue, 13 Mar 2018 23:45:54 +0200 [thread overview] Message-ID: <20180313214554.28521-9-igor.stoppa@huawei.com> (raw) In-Reply-To: <20180313214554.28521-1-igor.stoppa@huawei.com> Detailed documentation about the protectable memory allocator. Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com> --- Documentation/core-api/index.rst | 1 + Documentation/core-api/pmalloc.rst | 111 +++++++++++++++++++++++++++++++++++++ 2 files changed, 112 insertions(+) create mode 100644 Documentation/core-api/pmalloc.rst diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index c670a8031786..8f5de42d6571 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -25,6 +25,7 @@ Core utilities genalloc errseq printk-formats + pmalloc Interfaces for kernel debugging =============================== diff --git a/Documentation/core-api/pmalloc.rst b/Documentation/core-api/pmalloc.rst new file mode 100644 index 000000000000..10e01187d049 --- /dev/null +++ b/Documentation/core-api/pmalloc.rst @@ -0,0 +1,111 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _pmalloc: + +Protectable memory allocator +============================ + +Purpose +------- + +The pmalloc library is meant to provide read-only status to data that, +for some reason, could neither be declared as constant, nor could it take +advantage of the qualifier __ro_after_init, but is write-once and +read-only in spirit. +It protects data from both accidental and malicious overwrites. + +Example: A policy that is loaded from userspace. + + +Concept +------- + +pmalloc builds on top of :ref:`genalloc <genalloc>`, using the same +concept of memory pools. + +The value added by pmalloc is that now the memory contained in a pool can +become read-only, for the rest of the life of the pool. + +Different kernel drivers and threads can use different pools, for finer +control of what becomes read_only and when. +And for improved lockless concurrency. + + +Caveats +------- + +- To facilitate the conversion of existing code to pmalloc pools, several + helper functions are provided, mirroring their k/vmalloc counterparts. + In particular, pfree(), which is mostly meant for error paths, when one + or more previous allocations must be rolled back. + +- Memory freed while a pool is not yet protected will be reused. + +- Once a pool is protected, it's not possible to allocate any more memory + from it. + +- Memory "freed" from a protected pool indicates that such memory is not + in use anymore by the requester; however, it will not become available + for further use, until the pool is destroyed. + +- pmalloc does not provide locking support with respect to allocating vs + protecting an individual pool, for performance reasons. + It is recommended not to share the same pool between unrelated functions. + Should sharing be a necessity, the user of the shared pool is expected + to implement locking for that pool. + +- pmalloc uses genalloc to optimize the use of the space it allocates + through vmalloc. Some more TLB entries will be used, however less than + in the case of using vmalloc directly. The exact number depends on the + size of each allocation request and possible slack. + +- Considering that not much data is supposed to be dynamically allocated + and then marked as read-only, it shouldn't be an issue that the address + range for pmalloc is limited, on 32-bit systems. + +- Regarding SMP systems, the allocations are expected to happen mostly + during an initial transient, after which there should be no more need to + perform cross-processor synchronizations of page tables. + + +Use +--- + +The typical sequence, when using pmalloc, is: + +#. create a pool + + :c:func:`pmalloc_create_pool` + +#. [optional] pre-allocate some memory in the pool + + :c:func:`pmalloc_prealloc` + +#. issue one or more allocation requests to the pool with locking as needed + + :c:func:`pmalloc` + + :c:func:`pzalloc` + +#. initialize the memory obtained with desired values + +#. [optional] iterate over points 3 & 4 as needed + +#. write-protect the pool + + :c::func:`pmalloc_protect_pool` + +#. use in read-only mode the handles obtained through the allocations + +#. [optional] release all the memory allocated + + :c:func:`pfree` + +#. [optional, but depends on point 8] destroy the pool + :c:func:`pmalloc_destroy_pool` + +API +--- + +.. kernel-doc:: include/linux/pmalloc.h +.. kernel-doc:: mm/pmalloc.c -- 2.14.1
next prev parent reply other threads:[~2018-03-13 21:45 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-13 21:45 [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data Igor Stoppa 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 ` Igor Stoppa [this message] 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-9-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: linkBe 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).