[PATCH 10/17] prmem: documentation
Peter Zijlstra
peterz at infradead.org
Wed Oct 31 10:02:37 UTC 2018
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.
More information about the Linux-security-module-archive
mailing list