Re: [PATCH 16/17] prmem: pratomic-long
From: Kees Cook <hidden>
Date: 2018-11-01 03:28:42
Also in:
linux-arch, linux-integrity, lkml
On Wed, Oct 31, 2018 at 2:10 AM, Peter Zijlstra [off-list ref] wrote:
On Tue, Oct 30, 2018 at 04:28:16PM +0000, Will Deacon wrote:quoted
On Tue, Oct 30, 2018 at 04:58:41PM +0100, Peter Zijlstra wrote:quoted
Like mentioned elsewhere; if you do write_enable() + write_disable() thingies, it all becomes: write_enable(); atomic_foo(&bar); write_disable(); No magic gunk infested duplication at all. Of course, ideally you'd then teach objtool about this (or a GCC plugin I suppose) to ensure any enable reached a disable.Isn't the issue here that we don't want to change the page tables for the mapping of &bar, but instead want to create a temporary writable alias at a random virtual address? So you'd want: wbar = write_enable(&bar); atomic_foo(wbar); write_disable(wbar); which is probably better expressed as a map/unmap API. I suspect this would also be the only way to do things for cmpxchg() loops, where you want to create the mapping outside of the loop to minimise your time in the critical section.Ah, so I was thikning that the altnerative mm would have stuff in the same location, just RW instead of RO.
I was hoping for the same location too. That allows use to use a gcc plugin to mark, say, function pointer tables, as read-only, and annotate their rare updates with write_rare() without any recalculation. -Kees -- Kees Cook