From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754264AbdEDNjO (ORCPT ); Thu, 4 May 2017 09:39:14 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:25709 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753766AbdEDNjE (ORCPT ); Thu, 4 May 2017 09:39:04 -0400 Subject: Re: RFC v2: post-init-read-only protection for data allocated dynamically To: Michal Hocko References: <9200d87d-33b6-2c70-0095-e974a30639fd@huawei.com> <20170504112159.GC31540@dhcp22.suse.cz> <83d4556c-b21c-7ae5-6e83-4621a74f9fd5@huawei.com> <20170504131131.GI31540@dhcp22.suse.cz> CC: , , Dave Hansen From: Igor Stoppa Message-ID: Date: Thu, 4 May 2017 16:37:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170504131131.GI31540@dhcp22.suse.cz> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.122.225.51] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.590B2EF0.016F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f7beed872fe522443cf034c76c393dac Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/05/17 16:11, Michal Hocko wrote: > On Thu 04-05-17 15:14:10, Igor Stoppa wrote: > 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. I didn't spend too many thoughts on this so far, because the zone-based approach seemed almost doomed, so I wanted to wait for the evolution of the discussion :-) The main question here is granularity, I think. At least, as first cut, the simpler approach would be to have a master toggle: when some legitimate operation needs to happen, the seal is lifted across the entire range, then it is put back in place, once the operation has concluded. Simplicity is the main advantage. The disadvantage is that anything can happen, undetected, while the seal is lifted. OTOH the amount of code that could backfire should be fairly limited, so it doesn't seem a huge issue to me. The alternative would be to somehow know what a write will change and make only the appropriate page(s) writable. But it seems overkill to me. Especially because in some cases, with huge pages, everything would fit anyway in one page. One more option that comes to mind - but I do not know how realistic it would be - is to have multiple slabs, to be used for different purposes. Ex: one for the monolithic kernel and one for modules. It wouldn't help for livepatch, though, as it can modify both, so both would have to be unprotected. But live-patching is potentially a far less frequent event than module loading/unloading (thinking about USB gadgets, for example). [...] > 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. ok [...] > 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. good, then I could proceed with the prototype, if there are no further objections/questions and we agree that, implementation aside, there are no obvious fundamental problems preventing the merge --- thanks, igor