Date: Tue, 4 Dec 2018 10:56:03 -0800 From: Andy Lutomirski <luto@...nel.org> To: Nadav Amit <nadav.amit@...il.com> Cc: Rick Edgecombe <rick.p.edgecombe@...el.com>, Andrew Morton <akpm@...ux-foundation.org>, Andrew Lutomirski <luto@...nel.org>, Will Deacon <will.deacon@....com>, Linux-MM <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, "Naveen N . Rao" <naveen.n.rao@...ux.vnet.ibm.com>, Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>, "David S. Miller" <davem@...emloft.net>, Masami Hiramatsu <mhiramat@...nel.org>, Steven Rostedt <rostedt@...dmis.org>, Ingo Molnar <mingo@...hat.com>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, jeyu@...nel.org, Network Development <netdev@...r.kernel.org>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Jann Horn <jannh@...gle.com>, Kristen Carlson Accardi <kristen@...ux.intel.com>, Dave Hansen <dave.hansen@...el.com>, "Dock, Deneen T" <deneen.t.dock@...el.com>, Peter Zijlstra <peterz@...radead.org> Subject: Re: [PATCH 1/2] vmalloc: New flag for flush before releasing pages On Mon, Dec 3, 2018 at 5:43 PM Nadav Amit <nadav.amit@...il.com> wrote: > > > On Nov 27, 2018, at 4:07 PM, Rick Edgecombe <rick.p.edgecombe@...el.com> wrote: > > > > Since vfree will lazily flush the TLB, but not lazily free the underlying pages, > > it often leaves stale TLB entries to freed pages that could get re-used. This is > > undesirable for cases where the memory being freed has special permissions such > > as executable. > > So I am trying to finish my patch-set for preventing transient W+X mappings > from taking space, by handling kprobes & ftrace that I missed (thanks again for > pointing it out). > > But all of the sudden, I don’t understand why we have the problem that this > (your) patch-set deals with at all. We already change the mappings to make > the memory writable before freeing the memory, so why can’t we make it > non-executable at the same time? Actually, why do we make the module memory, > including its data executable before freeing it??? > All the code you're looking at is IMO a very awkward and possibly incorrect of doing what's actually necessary: putting the direct map the way it wants to be. Can't we shove this entirely mess into vunmap? Have a flag (as part of vmalloc like in Rick's patch or as a flag passed to a vfree variant directly) that makes the vunmap code that frees the underlying pages also reset their permissions? Right now, we muck with set_memory_rw() and set_memory_nx(), which both have very awkward (and inconsistent with each other!) semantics when called on vmalloc memory. And they have their own flushes, which is inefficient. Maybe the right solution is for vunmap to remove the vmap area PTEs, call into a function like set_memory_rw() that resets the direct maps to their default permissions *without* flushing, and then to do a single flush for everything. Or, even better, to cause the change_page_attr code to do the flush and also to flush the vmap area all at once so that very small free operations can flush single pages instead of flushing globally.
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.