Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 31 Oct 2018 13:36:48 -0700
From: Andy Lutomirski <>
To: Peter Zijlstra <>
Cc: Matthew Wilcox <>,
 Igor Stoppa <>, Tycho Andersen <>,
 Kees Cook <>, Mimi Zohar <>,
 Dave Chinner <>, James Morris <>,
 Michal Hocko <>,
 Kernel Hardening <>,
 linux-integrity <>,
 LSM List <>,
 Igor Stoppa <>,
 Dave Hansen <>,
 Jonathan Corbet <>, Laura Abbott <>,
 Randy Dunlap <>,
 Mike Rapoport <>,
 "open list:DOCUMENTATION" <>,
 LKML <>, Thomas Gleixner <>
Subject: Re: [PATCH 10/17] prmem: documentation

> On Oct 31, 2018, at 3:02 AM, Peter Zijlstra <> wrote:
>> On Tue, Oct 30, 2018 at 09:41:13PM -0700, Andy Lutomirski wrote:
>> To clarify some of this thread, I think that the fact that rare_write
>> uses an mm_struct and alias mappings under the hood should be
>> completely invisible to users of the API.  No one should ever be
>> handed a writable pointer to rare_write memory (except perhaps during
>> bootup or when initializing a large complex data structure that will
>> be rare_write but isn't yet, e.g. the policy db).
> Being able to use pointers would make it far easier to do atomics and
> other things though.

This stuff is called *rare* write for a reason. Do we really want to allow atomics beyond just store-release?  Taking a big lock and then writing in the right order should cover everything, no?

>> For example, there could easily be architectures where having a
>> writable alias is problematic.
> Mostly we'd just have to be careful of cache aliases, alignment should
> be able to sort that I think.
>> If you have multiple pools and one mm_struct per pool, you'll need a
>> way to find the mm_struct from a given allocation.
> Or keep track of it externally. For example by context. If you modify
> page-tables you pick the page-table pool, if you modify selinux state,
> you pick the selinux pool.
>> Regardless of how the mm_structs are set up, changing rare_write
>> memory to normal memory or vice versa will require a global TLB flush
>> (all ASIDs and global pages) on all CPUs, so having extra mm_structs
>> doesn't seem to buy much.
> The way I understand it, the point is that if you stick page-tables and
> selinux state in different pools, a stray write in one will never affect
> the other.

Hmm. That’s not totally crazy, but the API would need to be carefully designed. And some argument would have to be made as to why it’s better to use a different address space as opposed to checking in software along the lines of the uaccess checking.

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.