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.

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.