Thread (140 messages) 140 messages, 21 authors, 2018-12-04

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help