[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Dec 2018 16:03:50 -0800
From: Rick Edgecombe <rick.p.edgecombe@...el.com>
To: akpm@...ux-foundation.org,
luto@...nel.org,
will.deacon@....com,
linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
kernel-hardening@...ts.openwall.com,
naveen.n.rao@...ux.vnet.ibm.com,
anil.s.keshavamurthy@...el.com,
davem@...emloft.net,
mhiramat@...nel.org,
rostedt@...dmis.org,
mingo@...hat.com,
ast@...nel.org,
daniel@...earbox.net,
jeyu@...nel.org,
namit@...are.com,
netdev@...r.kernel.org,
ard.biesheuvel@...aro.org,
jannh@...gle.com
Cc: kristen@...ux.intel.com,
dave.hansen@...el.com,
deneen.t.dock@...el.com,
Rick Edgecombe <rick.p.edgecombe@...el.com>
Subject: [PATCH v2 0/4] Don’t leave executable TLB entries to freed pages
Sometimes when memory is freed via the module subsystem, an executable
permissioned TLB entry can remain to a freed page. If the page is re-used to
back an address that will receive data from userspace, it can result in user
data being mapped as executable in the kernel. The root of this behavior is
vfree lazily flushing the TLB, but not lazily freeing the underlying pages.
This v2 enables vfree to handle freeing memory with special permissions. So now
it can be done with no W^X window, centralizing the logic for this operation,
and also to do this with only one TLB flush on x86.
I'm not sure if the algorithm Andy Lutomirski suggested (to do the whole
teardown with one TLB flush) will work across other architectures or not, so it
is in an x86 arch breakout(arch_vunmap) in this version. The default arch_vunmap
implementation does what Nadav is proposing users of module_alloc do on tear
down so it should be unchanged in behavior, just centralized. The main
difference will be BPF teardown will now get an extra TLB flush on archs that
have set_memory_* defined from set_memory_nx in addition to set_memory_rw. On
x86, due to the more efficient arch version, it will be unchanged at one flush.
The logic enabling this behavior is plugged into kernel/module.c and bpf cross
arch pieces. So it should be enabled for all architectures for regular .ko
modules and bpf but the other module_alloc users will be unchanged for now.
I did find one small downside with this approach, and that is that there is
occasionally one extra directmap page split in modules tear down, since one of
the modules subsections is RW. The x86 arch_vunmap will set the RW directmap of
the pages not present, since it doesn't know the whole thing is not executable,
so sometimes this results in an splitting an extra large page because the paging
structure would have its first special permission. But on the plus side many TLB
flushes are reduced down to one (on x86 here, and likely others in the future).
The other usages of modules (bpf, etc) will not have RW subsections and so this
will not increase. So I am thinking its not a big downside for a few modules
compared to reducing TLB flushes, removing executable stale TLB entries and code
simplicity.
Todo:
- Merge with Nadav Amit's patchset
- Test on x86 32 bit with highmem
- Plug into ftrace and kprobes implementations in Nadav's next version of his
patchset
Changes since v1:
- New efficient algorithm on x86 for tearing down executable RO memory and
flag for this (Andy Lutomirski)
- Have no W^X violating window on tear down (Nadav Amit)
Rick Edgecombe (4):
vmalloc: New flags for safe vfree on special perms
modules: Add new special vfree flags
bpf: switch to new vmalloc vfree flags
x86/vmalloc: Add TLB efficient x86 arch_vunmap
arch/x86/include/asm/set_memory.h | 2 +
arch/x86/mm/Makefile | 3 +-
arch/x86/mm/pageattr.c | 11 +++--
arch/x86/mm/vmalloc.c | 71 ++++++++++++++++++++++++++++++
include/linux/filter.h | 26 +++++------
include/linux/vmalloc.h | 2 +
kernel/bpf/core.c | 1 -
kernel/module.c | 43 +++++-------------
mm/vmalloc.c | 73 ++++++++++++++++++++++++++++---
9 files changed, 173 insertions(+), 59 deletions(-)
create mode 100644 arch/x86/mm/vmalloc.c
--
2.17.1
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.
