From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754354AbdESKxM (ORCPT ); Fri, 19 May 2017 06:53:12 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:26913 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751560AbdESKxK (ORCPT ); Fri, 19 May 2017 06:53:10 -0400 Subject: Re: RFC v2: post-init-read-only protection for data allocated dynamically To: Dave Hansen , Michal Hocko , Laura Abbott References: <9200d87d-33b6-2c70-0095-e974a30639fd@huawei.com> <0b55343e-4305-a9f1-2b17-51c3c734aea6@huawei.com> <20170510080542.GF31466@dhcp22.suse.cz> <885311a2-5b9f-4402-0a71-5a3be7870aa0@huawei.com> <20170510114319.GK31466@dhcp22.suse.cz> <1a8cc1f4-0b72-34ea-43ad-5ece22a8d5cf@huawei.com> CC: , , "kernel-hardening@lists.openwall.com" From: Igor Stoppa Message-ID: Date: Fri, 19 May 2017 13:51:33 +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: 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.0A020204.591ECE7C.000C,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 Hello, On 10/05/17 18:45, Dave Hansen wrote: > On 05/10/2017 08:19 AM, Igor Stoppa wrote: >> So I'd like to play a little what-if scenario: >> what if I was to support exclusively virtual memory and convert to it >> everything that might need sealing? > > Because of the issues related to fracturing large pages, you might have > had to go this route eventually anyway. Changing the kernel linear map > isn't nice. > > FWIW, you could test this scheme by just converting all the users to > vmalloc() and seeing what breaks. They'd all end up rounding up all > their allocations to PAGE_SIZE, but that'd be fine for testing. Apologies for the long hiatus, it took me some time to figure out a solution that could somehow address all the comments I got till this point. It's here [1], I preferred to start one new thread, since the proposal has in practice changed significantly, even if in spirit it's still the same. It should also take care of the potential waste of space you mentioned wrt the round up to PAGE_SIZE. > Could you point out 5 or 10 places in the kernel that you want to convert? Right now I can only repeat what I said initially: - the linked list used to implement LSM hooks - SE linux structures used to implement the policy DB, it should be about 5 data types Next week, I'll address the 2 cases I listed, then I'll look for more, but I think it should not be difficult to find customers for this. BTW, I forgot to mention that I tested the code against both SLAB and SLUB and it seems to work fine. So far I've used QEMU x86-64 as test environment. -- igor [1] https://marc.info/?l=linux-mm&m=149519044015956&w=2