From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753112AbdEEKnp (ORCPT ); Fri, 5 May 2017 06:43:45 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:25797 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752556AbdEEKno (ORCPT ); Fri, 5 May 2017 06:43:44 -0400 Subject: Re: RFC v2: post-init-read-only protection for data allocated dynamically To: Laura Abbott , Michal Hocko References: <9200d87d-33b6-2c70-0095-e974a30639fd@huawei.com> CC: , , "kernel-hardening@lists.openwall.com" From: Igor Stoppa Message-ID: <0b55343e-4305-a9f1-2b17-51c3c734aea6@huawei.com> Date: Fri, 5 May 2017 13:42:27 +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="utf-8" 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.0A020205.590C574B.00E0,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 19:49, Laura Abbott wrote: > [adding kernel-hardening since I think there would be interest] thank you, I overlooked this > BPF takes the approach of calling set_memory_ro to mark regions as > read only. I'm certainly over simplifying but it sounds like this > is mostly a mechanism to have this happen mostly automatically. > Can you provide any more details about tradeoffs of the two approaches? I am not sure I understand the question ... For what I can understand, the bpf is marking as read only something that spans across various pages, which is fine. The payload to be protected is already organized in such pages. But in the case I have in mind, I have various, heterogeneous chunks of data, coming from various subsystems, not necessarily page aligned. And, even if they were page aligned, most likely they would be far smaller than a page, even a 4k page. The first problem I see, is how to compact them into pages, ensuring that no rwdata manages to infiltrate the range. The actual mechanism for marking pages as read only is not relevant at this point, if I understand your question correctly, since set_memory_ro is walking the pages it receives as parameter. > arm and arm64 have the added complexity of using larger > page sizes on the linear map so dynamic mapping/unmapping generally > doesn't work. Do you mean that a page could be 16MB and therefore it would not be possible to get a smaller chunk? > arm64 supports DEBUG_PAGEALLOC by mapping with only > pages but this is generally only wanted as a debug mechanism. > I don't know if you've given this any thought at all. Since the beginning I have thought about this feature as an opt-in feature. I am aware that it can have drawbacks, but I think it would be valuable as debugging tool even where it's not feasible to keep it always-on. OTOH on certain systems it can be sufficiently appealing to be kept on, even if it eats up some more memory. If this doesn't answer your question, could you please detail it more? --- thanks, igor