Date: Thu, 2 Mar 2017 11:48:39 -0800 From: Kees Cook <keescook@...omium.org> To: Andy Lutomirski <luto@...capital.net> Cc: Mark Rutland <mark.rutland@....com>, Hoeun Ryu <hoeun.ryu@...il.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Andy Lutomirski <luto@...nel.org>, PaX Team <pageexec@...email.hu>, Emese Revfy <re.emese@...il.com>, Russell King <linux@...linux.org.uk>, "x86@...nel.org" <x86@...nel.org> Subject: Re: [RFC][PATCH 1/8] Introduce rare_write() infrastructure On Thu, Mar 2, 2017 at 8:33 AM, Andy Lutomirski <luto@...capital.net> wrote: > On Thu, Mar 2, 2017 at 3:19 AM, Mark Rutland <mark.rutland@....com> wrote: >> On Wed, Mar 01, 2017 at 01:00:05PM -0800, Andy Lutomirski wrote: >>> On Wed, Mar 1, 2017 at 12:13 PM, Kees Cook <keescook@...omium.org> wrote: >>> > On Wed, Mar 1, 2017 at 2:43 AM, Mark Rutland <mark.rutland@....com> wrote: >>> Now a generic implementation could work by allocating a percpu >>> mm_struct that contains a single giant VMA. __arch_rare_write_begin() >>> switches to that mm. __arch_rare_write pokes some PTEs into the mm >>> and calls copy_to_user(). __arch_rare_write_end() switches back to >>> the original mm. An x86 implementation could just fiddle with CR0.WP. >> >> I'd expected that we'd know where the write_rarely data was up-front, so >> we could set up the mapping statically, and just map it in at map/begin, >> but otherwise this sounds like what I had in mind. >> > > Duh. That works too and would be considerably simpler :) It may be slightly complicated by needing to track the module .rodata areas, but ultimately, yeah, it seems like that could work. -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.