From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753039AbdEEMJi (ORCPT ); Fri, 5 May 2017 08:09:38 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:25799 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751335AbdEEMJh (ORCPT ); Fri, 5 May 2017 08:09:37 -0400 Subject: Re: RFC v2: post-init-read-only protection for data allocated dynamically To: Dave Hansen , 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> <361e39e9-517a-2fc2-016c-23f9359fef0a@intel.com> CC: , From: Igor Stoppa Message-ID: Date: Fri, 5 May 2017 15:08:31 +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: <361e39e9-517a-2fc2-016c-23f9359fef0a@intel.com> 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.590C6B77.00D4,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: 6b59a0021462a4f9b0519fd6afc9be29 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/05/17 20:24, Dave Hansen wrote: > On 05/04/2017 07:01 AM, Michal Hocko wrote: >> 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); >> >> 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. > > Igor, what sizes of objects are you after here, mostly? Theoretically, anything, since I have not really looked in details into all the various subsystems, however, taking a more pragmatical approach and referring to SE Linux and LSM Hooks, which were my initial target, For SE Linux, I'm taking as example the policy db [1]: The sizes are mostly small-ish: from 4-6 bytes to 16-32, overall. There are some exceptions: the main policydb structure is way larger, but it's not supposed to be instantiated repeatedly. For LSM Hooks, the sublists in that hydra which goes under the name of struct security_hook_heads, which are of type struct security_hook_list, so a handful of bytes for the generic element [2]. > I ask because slub, at least, doesn't work at all for objects >> PAGE_SIZE. It just punts those to the page allocator. But, you > _could_ still use vmalloc() for those. I would be surprised to find many objects that are larger than PAGE_SIZE and qqualify for post-init-read-only protection, even if the page size was only 4kB. >>From that perspective, I'm more concerned about avoiding taking a lot of pages and leaving them mostly unused. [1] security/selinux/ss/policydb.h [2] include/linux/lsm_hooks.h