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 11:02:37 +0100
From: Peter Zijlstra <>
To: Andy Lutomirski <>
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 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.

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.