Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1635728
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: RFC v2: post-init-read-only protection for data allocated dynamically |
| Date | 2017-05-04 15:20 +0200 |
| Message-ID | <tDoPM-3W2-19@gated-at.bofh.it> (permalink) |
| References | <tD1gw-5a8-45@gated-at.bofh.it> <tDn7j-2Ke-1@gated-at.bofh.it> <tDnTI-3io-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
RFC v2: post-init-read-only protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-03 14:10 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-04 10:20 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Dave Hansen <dave.hansen@intel.com> - 2017-05-04 16:40 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-05 11:00 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Michal Hocko <mhocko@kernel.org> - 2017-05-04 13:30 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-04 14:20 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Michal Hocko <mhocko@kernel.org> - 2017-05-04 15:20 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-04 15:40 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Michal Hocko <mhocko@kernel.org> - 2017-05-04 16:10 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Dave Hansen <dave.hansen@intel.com> - 2017-05-04 19:30 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-05 14:10 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-05 14:30 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Michal Hocko <mhocko@kernel.org> - 2017-05-10 09:50 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Laura Abbott <labbott@redhat.com> - 2017-05-04 19:00 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-05 12:50 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Laura Abbott <labbott@redhat.com> - 2017-05-08 17:30 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-09 11:50 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Michal Hocko <mhocko@kernel.org> - 2017-05-10 10:10 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-10 11:00 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Michal Hocko <mhocko@kernel.org> - 2017-05-10 13:50 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-10 17:30 +0200
Re: RFC v2: post-init-read-only protection for data allocated dynamically Dave Hansen <dave.hansen@intel.com> - 2017-05-10 17:50 +0200
csiph-web