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

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

[Igor Stoppa]

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.

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.

Such zone would be carved out from the NORMAL one and would consist of 
contiguous memory pages.

Memory from this zone could be requested through some additional flag, 
for example GFP_LOCKABLE, through vmalloc/kmalloc and friends.

The zone could, for example, default to GFP_KERNEL, if for some reason 
the HW doesn't support the feature.

How does the idea look like? Any better suggestion?

I want to create a reference implementation, but I am not sure what 
would be the correct way to extend the current set of flags:

Looking at gfp.h and mmzone.h, it seems that the 4 lower bits are 
reserved for DMA, DMA32, HIGHMEM and MOVABLE:

#define __GFP_DMA	((__force gfp_t)___GFP_DMA)
#define __GFP_HIGHMEM	((__force gfp_t)___GFP_HIGHMEM)
#define __GFP_DMA32	((__force gfp_t)___GFP_DMA32)
#define __GFP_MOVABLE	((__force gfp_t)___GFP_MOVABLE)
[...]


There's a note:

/* If the above are modified, __GFP_BITS_SHIFT may need updating */


Should I add the LOCKABLE zone as 5th bit?

#define __GFP_LOCKABLE	((__force gfp_t)___GFP_LOCKABLE)

In general it seems that the existing bits have been used in some very 
clever way, but there are none to spare, at least on 32-bit systems 
(this is also related to GFP_BITS_SHIFT):

  *       bit       result
  *       =================
  *       0x0    => NORMAL
  *       0x1    => DMA or NORMAL
  *       0x2    => HIGHMEM or NORMAL
  *       0x3    => BAD (DMA+HIGHMEM)
  *       0x4    => DMA32 or DMA or NORMAL
  *       0x5    => BAD (DMA+DMA32)
  *       0x6    => BAD (HIGHMEM+DMA32)
  *       0x7    => BAD (HIGHMEM+DMA32+DMA)
  *       0x8    => NORMAL (MOVABLE+0)
  *       0x9    => DMA or NORMAL (MOVABLE+DMA)
  *       0xa    => MOVABLE (Movable is valid only if HIGHMEM is set too)
  *       0xb    => BAD (MOVABLE+HIGHMEM+DMA)
  *       0xc    => DMA32 (MOVABLE+DMA32)
  *       0xd    => BAD (MOVABLE+DMA32+DMA)
  *       0xe    => BAD (MOVABLE+DMA32+HIGHMEM)
  *       0xf    => BAD (MOVABLE+DMA32+HIGHMEM+DMA)

Initially I was thinking to use one of the bit patterns defined as BAD,
but it looks like they are actually bitmasks, so I should have one bit 
field reserved for the specific zone I want to introduce.

Does it need to be contiguous to the existing ones?
Or should it be for example in 0x10 ?

  *       0x10   => LOCKABLE or NORMAL
          [all other combinations follow]

---
thanks, igor

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

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

[Michal Hocko]

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>

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

[Michal Hocko]

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

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

[Igor Stoppa]

On 02/05/17 19:47, Michal Hocko wrote:
> [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]

Ok, I'm sorry this was not clear, I'll detail it more.

---
thanks, igor

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