Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Mar 2017 11:48:39 -0800
From: Kees Cook <>
To: Andy Lutomirski <>
Cc: Mark Rutland <>, Hoeun Ryu <>, 
	"" <>, Andy Lutomirski <>, 
	PaX Team <>, Emese Revfy <>, 
	Russell King <>, "" <>
Subject: Re: [RFC][PATCH 1/8] Introduce rare_write() infrastructure

On Thu, Mar 2, 2017 at 8:33 AM, Andy Lutomirski <> wrote:
> On Thu, Mar 2, 2017 at 3:19 AM, Mark Rutland <> 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 <> wrote:
>>> > On Wed, Mar 1, 2017 at 2:43 AM, Mark Rutland <> 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 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.