Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1635728

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

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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