[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+RRiZtYfO-4Peh=FAHmUS4FThKHp-djoFgY80rebKTxQ@mail.gmail.com>
Date: Wed, 14 Feb 2018 11:29:21 -0800
From: Kees Cook <keescook@...omium.org>
To: Laura Abbott <labbott@...hat.com>
Cc: 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 Wed, Feb 14, 2018 at 11:06 AM, 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. Modules yes are not fully protected. The conclusion from past
I think that's a pretty serious problem: we can't have aliases with
mismatched permissions; this degrades a deterministic protection
(read-only) to a probabilistic protection (knowing where the alias of
a target is mapped). Having an attack be "needs some info leaks"
instead of "need execution control to change perms" is a much lower
bar, IMO.
> 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.
Why does using finer granularity on the physmap degrade performance? I
assume TLB pressure, but what is heavily using that area? (I must not
be understanding what physmap actually gets used for -- I thought it
was just a convenience to have a 1:1 virt/phys map for some lookups?)
-Kees
--
Kees Cook
Pixel Security
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.
