Re: RFC: post-init-read-only protection for data allocated dynamically

[Michal Hocko <mhocko@kernel.org>]

[You have already started new thread with the way how to introduce a new
zone and that might turn out to be useful but I think it is much more
important to understand requirements for the usecase you have in mind as
first]

On Fri 28-04-17 09:45:40, Michal Hocko wrote:
> On Fri 21-04-17 11:30:04, Igor Stoppa wrote:
> > Hello,
> > 
> > I am looking for a mechanism to protect the kernel data which is allocated
> > dynamically during system initialization and is later-on accessed only for
> > reads.
> > 
> > The functionality would be, in spirit, like the __read_only modifier, which
> > can be used to mark static data as read-only, in the post-init phase. Only,
> > it would apply to dynamically allocated data.
> > 
> > I couldn't find any such feature (did I miss it?), so I started looking at
> > what could be the best way to introduce it.
> > 
> > The static post-init write protection is achieved by placing all the data
> > into a page-aligned segment and then protecting the page from writes, using
> > the MMU, once the data is in its final state.
> > 
> > In my case, as example, I want to protect the SE Linux policy database,
> > after the set of policy has been loaded from file.
> > SE Linux uses fairly complex data structures, which are allocated
> > dynamically, depending on what rules/policy are loaded into it.
> > 
> > If I knew upfront, roughly, which sizes will be requested and how many
> > requests will happen, for each size, I could use multiple pools of objects.
> > However, I cannot assume upfront to know these parameters, because it's very
> > likely that the set of policies & rules will evolve.
> > 
> > I would also like to extend the write protection to other data structures,
> > which means I would probably end up writing another memory allocator, if I
> > started to generate on-demand object pools.
> 
> What is the expected life time of those objects? Are they ever freed? If
> yes are they freed at once or some might outlive others?
> 
> > The alternative I'm considering is that, if I were to add a new memory zone
> > (let's call it LOCKABLE), I could piggy back on the existing infrastructure
> > for memory allocation.
> 
> No, please no new memory zones! This doesn't look like a good fit
> anyway. I believe you need an allocator on top of the page allocator
> which manages kernel page tables on top of pools of pages. You really do
> not care about where the page is placed physically. I am not sure how
> much you can reuse from the SL.B object management because that highly
> depends on the life time of objects.

-- 
Michal Hocko
SUSE Labs

--
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>