From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753359AbdEEMUf (ORCPT ); Fri, 5 May 2017 08:20:35 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:25800 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751460AbdEEMUb (ORCPT ); Fri, 5 May 2017 08:20:31 -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> <20170504140126.GJ31540@dhcp22.suse.cz> CC: , , Dave Hansen From: Igor Stoppa Message-ID: <3e798c43-1726-ee7d-add5-762c7e17cb88@huawei.com> Date: Fri, 5 May 2017 15:19:19 +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: <20170504140126.GJ31540@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.0A090202.590C6E06.005A,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 17:01, Michal Hocko wrote: > On Thu 04-05-17 16:37:55, Igor Stoppa wrote: [...] >> The disadvantage is that anything can happen, undetected, while the seal >> is lifted. > > Yes and I think this makes it basically pointless ok, this goes a bit beyond what I had in mind initially, but I see your point [...] > Just to make my proposal more clear. I suggest the following workflow > > cache = kmem_cache_create(foo, object_size, ..., SLAB_SEAL); > > obj = kmem_cache_alloc(cache, gfp_mask); > init_obj(obj) > [more allocations] > kmem_cache_seal(cache); In case one doesn't want the feature, at which point would it be disabled? * not creating the slab * not sealing it * something else? > All slab pages belonging to the cache would get write protection. All > new allocations from this cache would go to new slab pages. Later > kmem_cache_seal will write protect only those new pages. ok > The main discomfort with this approach is that you have to create those > caches in advance, obviously. We could help by creating some general > purpose caches for common sizes but this sound like an overkill to me. > The caller will know which objects will need the protection so the > appropriate cache can be created on demand. But this reall depends on > potential users... Yes, I provided a more detailed answer in another branch of this thread. Right now I can answer only for what I have already looked into: SE Linux policy DB and LSM Hooks, and they do not seem very large. I do not expect a large footprint, overall, although there might be some exception. -- igor