[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXkrFHWa0cBJ2pTaH1Y2NMPFb4n5EXEH692pgD9OoxErA@mail.gmail.com>
Date: Mon, 10 Apr 2017 13:17:04 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: PaX Team <pageexec@...email.hu>, Daniel Micay <danielmicay@...il.com>,
Andy Lutomirski <luto@...nel.org>, Mathias Krause <minipli@...glemail.com>,
Thomas Gleixner <tglx@...utronix.de>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Mark Rutland <mark.rutland@....com>,
Hoeun Ryu <hoeun.ryu@...il.com>, Emese Revfy <re.emese@...il.com>,
Russell King <linux@...linux.org.uk>, X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()
On Mon, Apr 10, 2017 at 1:13 PM, Kees Cook <keescook@...omium.org> wrote:
> On Sun, Apr 9, 2017 at 1:24 PM, PaX Team <pageexec@...email.hu> wrote:
>> On 7 Apr 2017 at 22:07, Andy Lutomirski wrote:
>>> No one has explained how CR0.WP is weaker or slower than my proposal.
>>
>> you misunderstood, Daniel was talking about your use_mm approach.
>>
>>> Here's what I'm proposing:
>>>
>>> At boot, choose a random address A.
>>
>> what is the threat that a random address defends against?
>>
>>> Create an mm_struct that has a
>>> single VMA starting at A that represents the kernel's rarely-written
>>> section. Compute O = (A - VA of rarely-written section). To do a
>>> rare write, use_mm() the mm, write to (VA + O), then unuse_mm().
>>
>> the problem is that the amount of __read_only data extends beyond vmlinux,
>> i.e., this approach won't scale. another problem is that it can't be used
>> inside use_mm and switch_mm themselves (no read-only task structs or percpu
>> pgd for you ;) and probably several other contexts.
>
> These are the limitations that concern me: what will we NOT be able to
> make read-only as a result of the use_mm() design choice? My RFC
> series included a simple case and a constify case, but I did not
> include things like making page tables read-only, etc.
If we make page tables read-only, we may need to have multiple levels
of rareness. Page table writes aren't all that rare, and I can
imagine distros configuring the kernel so that static structs full of
function pointers are read-only (IMO that should be the default or
even mandatory), but page tables may be a different story.
That being said, CR3-twiddling to write to page tables could actually
work. Hmm.
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.
