From mboxrd@z Thu Jan 1 00:00:00 1970 From: labbott@redhat.com (Laura Abbott) Date: Wed, 14 Feb 2018 12:13:36 -0800 Subject: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory) In-Reply-To: References: <20180124175631.22925-1-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> <2f23544a-bd24-1e71-967b-e8d1cf5a20a3@redhat.com> Message-ID: <213effab-f0d0-cfc5-8feb-c72eed8ae0aa@redhat.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On 02/14/2018 11:28 AM, Ard Biesheuvel wrote: > On 14 February 2018 at 19:06, Laura Abbott wrote: >> On 02/13/2018 01:43 PM, Kees Cook wrote: >>> >>> On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: >>>> >>>> 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. >>> >>> >>> Errr, so that means even modules and kernel code are writable via the >>> arm64 physmap? That seems extraordinarily bad. :( >>> >>> -Kees >>> >> >> (adding linux-arm-kernel and changing the subject) >> >> Kernel code should be fine, if it isn't that is a bug that should be >> fixed. > > We take care to ensure that the linear alias of the core kernel's > .text and .rodata segments are mapped read-only. When we first moved > the kernel out of the linear region, we did not map it there at all > anymore, but that broke hibernation so we had to put something back. > >> Modules yes are not fully protected. The conclusion from past >> experience has been that we cannot safely break down larger page sizes >> at runtime like x86 does. We could theoretically >> add support for fixing up the alias if PAGE_POISONING is enabled but >> I don't know who would actually use that in production. Performance >> is very poor at that point. >> > > As long as the linear alias of the module is mapped down to pages, we > should be able to tweak the permissions. I take it that PAGE_POISONING > does more than just that? > Page poisoning does exactly that. The argument I was trying to make was that if nobody really uses page poisoning except for debugging it might not be worth it to fix up the alias. Thinking a bit more, this is a terrible argument for many reasons so yes I agree that we can just fix up the alias if PAGE_POISONING (or other features) are enabled. 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