On Thu 04-05-17 15:14:10, Igor Stoppa wrote: [...] > I wonder if you are thinking about loadable modules or maybe livepatch. > My proposal, in its current form, is only about what is done when the > kernel initialization is performed. So it would not take those cases > under its umbrella. Actually it might be incompatible with livepatch, if > any of the read-only data is supposed to be updated. > > Since it's meant to improve the current level of integrity, I would > prefer to have a progressive approach and address modules/livepatch in a > later phase, if this is not seen as a show stopper. I believe that this is a fundamental question. Sealing sounds useful for after-boot usecases as well and it would change the approach considerably. Coming up with an ad-hoc solution for the boot only way seems like a wrong way to me. And as you've said SELinux which is your target already does the thing after the early boot. [...] > > Roughly it would mean that once kmem_cache_seal() is > > called on a cache it would changed page tables to used slab pages to RO > > state. This would obviously need some fiddling to make those pages not > > usable for new allocations from sealed pages. It would also mean some > > changes to kfree path but I guess this is doable. > > Ok, as it probably has already become evident, I have just started > peeking into the memory subsystem, so this is the sort of guidance I was > hoping I could receive =) - thank you > > Question: I see that some pages can be moved around. Would this apply to > the slab-based solution, or can I assume that once I have certain > physical pages sealed, they will not be altered anymore? Slab pages are not migrateable currently. Even if they start being migrateable it would be an opt-in because that requires pointers tracking to make sure they are updated properly. > >> * While I do not strictly need a new memory zone, memory zones are what > >> kmalloc understands at the moment: AFAIK, it is not possible to tell > >> kmalloc from which memory pool it should fish out the memory, other than > >> having a reference to a memory zone. > > > > As I've said already. I think that a zone is a completely wrong > > approach. How would it help anyway. It is the allocator on top of the > > page allocator which has to do clever things to support sealing. > > > Ok, as long as there is a way forward that fits my needs and has the > possibility to be merged upstream, I'm fine with it. > > I suppose zones are the first thing one meets when reading the code, so > they are probably the first target that comes to mind. > That's what happened to me. > > I will probably come back with further questions, but I can then start > putting together some prototype of what you described. > > I am fine with providing a generic solution, but I must make sure that > it works with slub. I suppose what you proposed will do it, right? I haven't researched that too deeply. In principle both SLAB and SLUB maintain slab pages in a similar way so I do not see any fundamental problems. -- Michal Hocko SUSE Labs -- 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>
