From: Igor Stoppa <igor.stoppa@huawei.com>
To: Dave Hansen <dave.hansen@intel.com>, Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: RFC v2: post-init-read-only protection for data allocated dynamically
Date: Fri, 5 May 2017 15:08:31 +0300 [thread overview]
Message-ID: <bfc487a0-0e3e-efb5-8790-bbe052a62362@huawei.com> (raw)
In-Reply-To: <361e39e9-517a-2fc2-016c-23f9359fef0a@intel.com>
On 04/05/17 20:24, Dave Hansen wrote:
> On 05/04/2017 07:01 AM, Michal Hocko wrote:
>> Just to make my proposal more clear. I suggest the following workflow
>>
>> cache = kmem_cache_create(foo, object_size, ..., SLAB_SEAL);
>>
>> obj = kmem_cache_alloc(cache, gfp_mask);
>> init_obj(obj)
>> [more allocations]
>> kmem_cache_seal(cache);
>>
>> All slab pages belonging to the cache would get write protection. All
>> new allocations from this cache would go to new slab pages. Later
>> kmem_cache_seal will write protect only those new pages.
>
> Igor, what sizes of objects are you after here, mostly?
Theoretically, anything, since I have not really looked in details into
all the various subsystems, however, taking a more pragmatical approach
and referring to SE Linux and LSM Hooks, which were my initial target,
For SE Linux, I'm taking as example the policy db [1]:
The sizes are mostly small-ish: from 4-6 bytes to 16-32, overall.
There are some exceptions: the main policydb structure is way larger,
but it's not supposed to be instantiated repeatedly.
For LSM Hooks, the sublists in that hydra which goes under the name of
struct security_hook_heads, which are of type struct security_hook_list,
so a handful of bytes for the generic element [2].
> I ask because slub, at least, doesn't work at all for objects
>> PAGE_SIZE. It just punts those to the page allocator. But, you
> _could_ still use vmalloc() for those.
I would be surprised to find many objects that are larger than PAGE_SIZE
and qqualify for post-init-read-only protection, even if the page size
was only 4kB.
>From that perspective, I'm more concerned about avoiding taking a lot of
pages and leaving them mostly unused.
[1] security/selinux/ss/policydb.h
[2] include/linux/lsm_hooks.h
--
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:[~2017-05-05 12:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 12:06 Igor Stoppa
[not found] ` <70a9d4db-f374-de45-413b-65b74c59edcb@intel.com>
2017-05-04 8:17 ` Igor Stoppa
2017-05-04 14:30 ` Dave Hansen
2017-05-05 8:53 ` Igor Stoppa
2017-05-04 11:21 ` Michal Hocko
2017-05-04 12:14 ` Igor Stoppa
2017-05-04 13:11 ` Michal Hocko
2017-05-04 13:37 ` Igor Stoppa
2017-05-04 14:01 ` Michal Hocko
2017-05-04 17:24 ` Dave Hansen
2017-05-05 12:08 ` Igor Stoppa [this message]
2017-05-05 12:19 ` Igor Stoppa
2017-05-10 7:45 ` Michal Hocko
2017-05-04 16:49 ` Laura Abbott
2017-05-05 10:42 ` Igor Stoppa
2017-05-08 15:25 ` Laura Abbott
2017-05-09 9:38 ` Igor Stoppa
2017-05-10 8:05 ` Michal Hocko
2017-05-10 8:57 ` Igor Stoppa
2017-05-10 11:43 ` Michal Hocko
2017-05-10 15:19 ` Igor Stoppa
2017-05-10 15:45 ` Dave Hansen
2017-05-19 10:51 ` 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=bfc487a0-0e3e-efb5-8790-bbe052a62362@huawei.com \
--to=igor.stoppa@huawei.com \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.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