On 04/05/17 17:01, Michal Hocko wrote: > On Thu 04-05-17 16:37:55, Igor Stoppa wrote: [...] >> The disadvantage is that anything can happen, undetected, while the seal >> is lifted. > > Yes and I think this makes it basically pointless ok, this goes a bit beyond what I had in mind initially, but I see your point [...] > 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); In case one doesn't want the feature, at which point would it be disabled? * not creating the slab * not sealing it * something else? > 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. ok > The main discomfort with this approach is that you have to create those > caches in advance, obviously. We could help by creating some general > purpose caches for common sizes but this sound like an overkill to me. > The caller will know which objects will need the protection so the > appropriate cache can be created on demand. But this reall depends on > potential users... Yes, I provided a more detailed answer in another branch of this thread. Right now I can answer only for what I have already looked into: SE Linux policy DB and LSM Hooks, and they do not seem very large. I do not expect a large footprint, overall, although there might be some exception. -- igor -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
