From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225PclMtp0vOC8Fzt/iX0he1CQf5qdH2vEhA97vkmXmsf4icPZIOxl5hZ6EITC8ZswAsxFnv ARC-Seal: i=1; a=rsa-sha256; t=1518538198; cv=none; d=google.com; s=arc-20160816; b=l0//gl7msKpBJ/yw9vXEE3zLRVwh9rx0cE8ERk0pk/ISwyZTd6sGnEn3b8eOvZiGLs +rFTpwfKi3iCzG96+J0JVrnOwYHE+yz2a5j09tIfEJF//Gx4QMXGoQHFbigpIULN5RzV q1doR5yvplX3aQbb30BhoqLCNDYzd6S8ohC3rzDPe2a7iyFM1E3QIBw6nJEnfgde0kYb /tr7Noac0z25pOTPNGkdjZBcRNssQw1MvR/KpSdzaVEY7cmiParXAkJelNxYvlOrRFMn BMR4Qz63a5YJ62Rh/klLroe8MpK8BQY0WhEYZoqT1f9gcpF99f6lKi7VXjylHkfrbWfm py9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :delivered-to:list-id:list-subscribe:list-unsubscribe:list-help :list-post:precedence:mailing-list:arc-authentication-results; bh=zWmmnH/pXWbb+Ryii0d2IoQHFjuBmnfzEpsHL90b0Y0=; b=XaTxn2vzFLDWU7mCJeIyZwIkL2fJIQAU565fKLWnNxdhdb0ldZmXOFKcbuKjZ4xQi0 eNQD18s74i4zkOzrJCnfgwEyWpM7V6+uHNE3YY/HMDl65AoPF8UdOOgveOTIm/A2aKLw y2yWJ2+iUlMvZ2Ior1FRXXLFtGo9znwVP9BnUg04mBPy3Fz48h8hafE1Vk1FXGumPc2E 55UkmyyPgpya4rQnsVLnfXnTYUO3Kpeuin9nMXxUeQOPG3dLK29q5oTUg3B7vQ9w0S7P RhBbqozqMxKBrkBsB9KCWrCMLJEms02YeUyPoZvH38Zb/RxvVlMXo+aspo3qH0BADZKk iKkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11748-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11748-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11748-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11748-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: Subject: Re: [kernel-hardening] [PATCH 4/6] Protectable Memory To: Jann Horn , Kees Cook Cc: Igor Stoppa , Boris Lukashev , Christopher Lameter , Matthew Wilcox , Jerome Glisse , Michal Hocko , Christoph Hellwig , linux-security-module , Linux-MM , kernel list , Kernel Hardening References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> <8818bfd4-dd9f-f279-0432-69b59531bd41@huawei.com> <17e5b515-84c8-dca2-1695-cdf819834ea2@huawei.com> <414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com> From: Laura Abbott Message-ID: Date: Tue, 13 Feb 2018 08:09:35 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590497635371449856?= X-GMAIL-MSGID: =?utf-8?q?1592302709833690434?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 02/12/2018 07:39 PM, Jann Horn wrote: > On Tue, Feb 13, 2018 at 2:25 AM, Kees Cook wrote: >> On Mon, Feb 12, 2018 at 4:40 PM, Laura Abbott wrote: >>> On 02/12/2018 03:27 PM, Kees Cook wrote: >>>> >>>> On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa >>>> wrote: >>>>> >>>>> On 04/02/18 00:29, Boris Lukashev wrote: >>>>>> >>>>>> On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa >>>>>> wrote: >>>>> >>>>> >>>>> [...] >>>>> >>>>>>> What you are suggesting, if I have understood it correctly, is that, >>>>>>> when the pool is protected, the addresses already given out, will >>>>>>> become >>>>>>> traps that get resolved through a lookup table that is built based on >>>>>>> the content of each allocation. >>>>>>> >>>>>>> That seems to generate a lot of overhead, not to mention the fact that >>>>>>> it might not play very well with the MMU. >>>>>> >>>>>> >>>>>> That is effectively what i'm suggesting - as a form of protection for >>>>>> consumers against direct reads of data which may have been corrupted >>>>>> by some irrelevant means. In the context of pmalloc, it would probably >>>>>> be a separate type of ro+verified pool >>>>> >>>>> ok, that seems more like an extension though. >>>>> >>>>> ATM I am having problems gaining traction to get even the basic merged >>>>> :-) >>>>> >>>>> I would consider this as a possibility for future work, unless it is >>>>> said that it's necessary for pmalloc to be accepted ... >>>> >>>> >>>> I would agree: let's get basic functionality in first. Both >>>> verification and the physmap part can be done separately, IMO. >>> >>> >>> Skipping over physmap leaves a pretty big area of exposure that could >>> be difficult to solve later. I appreciate this might block basic >>> functionality but I don't think we should just gloss over it without >>> at least some idea of what we would do. >> >> What's our exposure on physmap for other regions? e.g. things that are >> executable, or made read-only later (like __ro_after_init)? > > I just checked on a system with a 4.9 kernel, and there seems to be no > physical memory that is mapped as writable in the init PGD and > executable elsewhere. > > Ah, I think I missed something. At least on X86, set_memory_ro, > set_memory_rw, set_memory_nx and set_memory_x all use > change_page_attr_clear/change_page_attr_set, which use > change_page_attr_set_clr, which calls __change_page_attr_set_clr() > with a second parameter "checkalias" that is set to 1 unless the bit > being changed is the NX bit, and that parameter causes the invocation > of cpa_process_alias(), which will, for mapped ranges, also change the > attributes of physmap ranges. set_memory_ro() and so on are also used > by the module loading code. > > But in the ARM64 code, I don't see anything similar. Does anyone with > a better understanding of ARM64 want to check whether I missed > something? Or maybe, with a recent kernel, check whether executable > module pages show up with a second writable mapping in the > "kernel_page_tables" file in debugfs? > No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger page sizes which can't be broken down at runtime. CONFIG_PAGE_POISONING does use 4K pages which could be adjusted at runtime. So yes, you are right we would have physmap exposure on arm64 as well. To the original question, it does sound like we are actually okay with the physmap. Thanks, Laura From mboxrd@z Thu Jan 1 00:00:00 1970 From: labbott@redhat.com (Laura Abbott) Date: Tue, 13 Feb 2018 08:09:35 -0800 Subject: [kernel-hardening] [PATCH 4/6] Protectable Memory In-Reply-To: References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> <8818bfd4-dd9f-f279-0432-69b59531bd41@huawei.com> <17e5b515-84c8-dca2-1695-cdf819834ea2@huawei.com> <414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On 02/12/2018 07:39 PM, Jann Horn wrote: > On Tue, Feb 13, 2018 at 2:25 AM, Kees Cook wrote: >> On Mon, Feb 12, 2018 at 4:40 PM, Laura Abbott wrote: >>> On 02/12/2018 03:27 PM, Kees Cook wrote: >>>> >>>> On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa >>>> wrote: >>>>> >>>>> On 04/02/18 00:29, Boris Lukashev wrote: >>>>>> >>>>>> On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa >>>>>> wrote: >>>>> >>>>> >>>>> [...] >>>>> >>>>>>> What you are suggesting, if I have understood it correctly, is that, >>>>>>> when the pool is protected, the addresses already given out, will >>>>>>> become >>>>>>> traps that get resolved through a lookup table that is built based on >>>>>>> the content of each allocation. >>>>>>> >>>>>>> That seems to generate a lot of overhead, not to mention the fact that >>>>>>> it might not play very well with the MMU. >>>>>> >>>>>> >>>>>> That is effectively what i'm suggesting - as a form of protection for >>>>>> consumers against direct reads of data which may have been corrupted >>>>>> by some irrelevant means. In the context of pmalloc, it would probably >>>>>> be a separate type of ro+verified pool >>>>> >>>>> ok, that seems more like an extension though. >>>>> >>>>> ATM I am having problems gaining traction to get even the basic merged >>>>> :-) >>>>> >>>>> I would consider this as a possibility for future work, unless it is >>>>> said that it's necessary for pmalloc to be accepted ... >>>> >>>> >>>> I would agree: let's get basic functionality in first. Both >>>> verification and the physmap part can be done separately, IMO. >>> >>> >>> Skipping over physmap leaves a pretty big area of exposure that could >>> be difficult to solve later. I appreciate this might block basic >>> functionality but I don't think we should just gloss over it without >>> at least some idea of what we would do. >> >> What's our exposure on physmap for other regions? e.g. things that are >> executable, or made read-only later (like __ro_after_init)? > > I just checked on a system with a 4.9 kernel, and there seems to be no > physical memory that is mapped as writable in the init PGD and > executable elsewhere. > > Ah, I think I missed something. At least on X86, set_memory_ro, > set_memory_rw, set_memory_nx and set_memory_x all use > change_page_attr_clear/change_page_attr_set, which use > change_page_attr_set_clr, which calls __change_page_attr_set_clr() > with a second parameter "checkalias" that is set to 1 unless the bit > being changed is the NX bit, and that parameter causes the invocation > of cpa_process_alias(), which will, for mapped ranges, also change the > attributes of physmap ranges. set_memory_ro() and so on are also used > by the module loading code. > > But in the ARM64 code, I don't see anything similar. Does anyone with > a better understanding of ARM64 want to check whether I missed > something? Or maybe, with a recent kernel, check whether executable > module pages show up with a second writable mapping in the > "kernel_page_tables" file in debugfs? > No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger page sizes which can't be broken down at runtime. CONFIG_PAGE_POISONING does use 4K pages which could be adjusted at runtime. So yes, you are right we would have physmap exposure on arm64 as well. To the original question, it does sound like we are actually okay with the physmap. Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f199.google.com (mail-ot0-f199.google.com [74.125.82.199]) by kanga.kvack.org (Postfix) with ESMTP id BC5A86B0003 for ; Tue, 13 Feb 2018 11:09:44 -0500 (EST) Received: by mail-ot0-f199.google.com with SMTP id q35so11214764otg.14 for ; Tue, 13 Feb 2018 08:09:44 -0800 (PST) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id i8sor4368808oia.240.2018.02.13.08.09.38 for (Google Transport Security); Tue, 13 Feb 2018 08:09:40 -0800 (PST) Subject: Re: [kernel-hardening] [PATCH 4/6] Protectable Memory References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> <8818bfd4-dd9f-f279-0432-69b59531bd41@huawei.com> <17e5b515-84c8-dca2-1695-cdf819834ea2@huawei.com> <414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com> From: Laura Abbott Message-ID: Date: Tue, 13 Feb 2018 08:09:35 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Jann Horn , Kees Cook Cc: Igor Stoppa , Boris Lukashev , Christopher Lameter , Matthew Wilcox , Jerome Glisse , Michal Hocko , Christoph Hellwig , linux-security-module , Linux-MM , kernel list , Kernel Hardening On 02/12/2018 07:39 PM, Jann Horn wrote: > On Tue, Feb 13, 2018 at 2:25 AM, Kees Cook wrote: >> On Mon, Feb 12, 2018 at 4:40 PM, Laura Abbott wrote: >>> On 02/12/2018 03:27 PM, Kees Cook wrote: >>>> >>>> On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa >>>> wrote: >>>>> >>>>> On 04/02/18 00:29, Boris Lukashev wrote: >>>>>> >>>>>> On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa >>>>>> wrote: >>>>> >>>>> >>>>> [...] >>>>> >>>>>>> What you are suggesting, if I have understood it correctly, is that, >>>>>>> when the pool is protected, the addresses already given out, will >>>>>>> become >>>>>>> traps that get resolved through a lookup table that is built based on >>>>>>> the content of each allocation. >>>>>>> >>>>>>> That seems to generate a lot of overhead, not to mention the fact that >>>>>>> it might not play very well with the MMU. >>>>>> >>>>>> >>>>>> That is effectively what i'm suggesting - as a form of protection for >>>>>> consumers against direct reads of data which may have been corrupted >>>>>> by some irrelevant means. In the context of pmalloc, it would probably >>>>>> be a separate type of ro+verified pool >>>>> >>>>> ok, that seems more like an extension though. >>>>> >>>>> ATM I am having problems gaining traction to get even the basic merged >>>>> :-) >>>>> >>>>> I would consider this as a possibility for future work, unless it is >>>>> said that it's necessary for pmalloc to be accepted ... >>>> >>>> >>>> I would agree: let's get basic functionality in first. Both >>>> verification and the physmap part can be done separately, IMO. >>> >>> >>> Skipping over physmap leaves a pretty big area of exposure that could >>> be difficult to solve later. I appreciate this might block basic >>> functionality but I don't think we should just gloss over it without >>> at least some idea of what we would do. >> >> What's our exposure on physmap for other regions? e.g. things that are >> executable, or made read-only later (like __ro_after_init)? > > I just checked on a system with a 4.9 kernel, and there seems to be no > physical memory that is mapped as writable in the init PGD and > executable elsewhere. > > Ah, I think I missed something. At least on X86, set_memory_ro, > set_memory_rw, set_memory_nx and set_memory_x all use > change_page_attr_clear/change_page_attr_set, which use > change_page_attr_set_clr, which calls __change_page_attr_set_clr() > with a second parameter "checkalias" that is set to 1 unless the bit > being changed is the NX bit, and that parameter causes the invocation > of cpa_process_alias(), which will, for mapped ranges, also change the > attributes of physmap ranges. set_memory_ro() and so on are also used > by the module loading code. > > But in the ARM64 code, I don't see anything similar. Does anyone with > a better understanding of ARM64 want to check whether I missed > something? Or maybe, with a recent kernel, check whether executable > module pages show up with a second writable mapping in the > "kernel_page_tables" file in debugfs? > No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger page sizes which can't be broken down at runtime. CONFIG_PAGE_POISONING does use 4K pages which could be adjusted at runtime. So yes, you are right we would have physmap exposure on arm64 as well. To the original question, it does sound like we are actually okay with the physmap. Thanks, Laura -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org