On Wed 10-05-17 11:57:42, Igor Stoppa wrote: > On 10/05/17 11:05, Michal Hocko wrote: [...] > > To me it seems that this being an initialization mostly thingy a simple > > allocator which manages a pool of pages (one set of sealed and one for > > allocations) > > Shouldn't also the set of pages used for keeping track of the others be > sealed? Once one is ro, also the other should not change. Heh, that really depends how much consistency and robustness you want to achieve. It is really hard to defend against targeted attacks against the allocator metadata when a code is running in the kernel. > > and which only appends new objects as they fit to unsealed > > pages would be sufficient for starter. > > Any "free" that might happen during the initialization transient, would > actually result in an untracked gap, right? yes. And once the whole page is free it would get unsealed and returned to the (page) allocator. This approach would inevitably lead to internal fragmentation but reducing that would require a pool which is shared for objects with the common life cycle which is quite hard with requirements you have (you would have to convey the allocation context to all users somehow). > What about the size of the pool of pages? I wouldn't see that as a big deal. New pages would be allocated as needed. > No predefined size, instead request a new page, when the memory > remaining from the page currently in use is not enough to fit the latest > allocation request? exactly > There are also two aspect we discussed earlier: > > - livepatch: how to deal with it? Identify the page it wants to modify > and temporarily un-protect it? Livepatch doesn't support data structures patching currently and even if it would have to understand those data structures and do something like copy&replace... > - modules: unloading and reloading modules will eventually lead to > permanently lost pages, in increasing number. Each module should free all objects that were allocated on its behalf and that should result in pages being freed as well > Loading/unloading repeatedly the same module is probably not so common, > with a major exception being USB, where almost anything can show up. > And disappear. > This seems like a major showstopper for the linear allocator you propose. I am not sure I understand. If such a module kept allocations behind it would be a memory leak no matter what. > My reasoning in pursuing the kmalloc approach was that it is already > equipped with mechanisms for dealing with these sort of cases, where > memory can be fragmented. Yeah, but kmalloc is optimized for a completely different usecase. You can reuse same pages again and again while you clearly cannot do the same once you seal a page and make it read only. Well unless you want to open time windows when the page stops being RO or use a different mapping for the allocator. But try to consider how many features of the slab allocator you are actually going to need wrt. to tweaks it would have to implement to support this new use case. Maybe duplicating general purpose caches and creating specialized explicitly is a viable path. I haven't tried it. > I also wouldn't risk introducing bugs with my homebrew allocator ... > > The initial thought was that there could be a master toggle to > seal/unseal all the memory affected. > > But you were not too excited, iirc :-D yes, If there are different users a pool (kmem_cache like) would be more natural. > Alternatively, kmalloc could be enhanced to unseal only the pages it > wants to modify. You would have to stop the world to prevent from an accidental overwrite during that time. Which makes the whole thing quite dubious IMHO. > I don't think much can be done for data that is placed together, in the > same page with something that needs to be altered. > But what is outside of that page could still enjoy the protection from > the seal. -- 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>
