[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXvddt148fncMJqpjK98uatiK-44knYFWU0-ytf8X+iog@mail.gmail.com>
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.
