Date: Wed, 14 Feb 2018 12:13:36 -0800 From: Laura Abbott <labbott@...hat.com> To: Ard Biesheuvel <ard.biesheuvel@...aro.org> Cc: Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>, Igor Stoppa <igor.stoppa@...wei.com>, Boris Lukashev <blukashev@...pervictus.com>, Christopher Lameter <cl@...ux.com>, Matthew Wilcox <willy@...radead.org>, Jerome Glisse <jglisse@...hat.com>, Michal Hocko <mhocko@...nel.org>, Christoph Hellwig <hch@...radead.org>, linux-security-module <linux-security-module@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>, kernel list <linux-kernel@...r.kernel.org>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org> Subject: Re: arm64 physmap (was Re: [PATCH 4/6] Protectable Memory) On 02/14/2018 11:28 AM, Ard Biesheuvel wrote: > On 14 February 2018 at 19:06, Laura Abbott <labbott@...hat.com> wrote: >> On 02/13/2018 01:43 PM, Kees Cook wrote: >>> >>> On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott <labbott@...hat.com> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.