* [PATCH v6 20/24] x86/ftrace: Use vmalloc special flag
From: nadav.amit @ 2019-04-26 23:22 UTC (permalink / raw)
To: Peter Zijlstra, Borislav Petkov, Andy Lutomirski, Ingo Molnar
Cc: linux-kernel, x86, hpa, Thomas Gleixner, Nadav Amit, Dave Hansen,
linux_dti, linux-integrity, linux-security-module, akpm,
kernel-hardening, linux-mm, will.deacon, ard.biesheuvel, kristen,
deneen.t.dock, Rick Edgecombe
In-Reply-To: <20190426232303.28381-1-nadav.amit@gmail.com>
From: Rick Edgecombe <rick.p.edgecombe@intel.com>
Use new flag VM_FLUSH_RESET_PERMS for handling freeing of special
permissioned memory in vmalloc and remove places where memory was set NX
and RW before freeing which is no longer needed.
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---
arch/x86/kernel/ftrace.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 53ba1aa3a01f..0caf8122d680 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -678,12 +678,8 @@ static inline void *alloc_tramp(unsigned long size)
{
return module_alloc(size);
}
-static inline void tramp_free(void *tramp, int size)
+static inline void tramp_free(void *tramp)
{
- int npages = PAGE_ALIGN(size) >> PAGE_SHIFT;
-
- set_memory_nx((unsigned long)tramp, npages);
- set_memory_rw((unsigned long)tramp, npages);
module_memfree(tramp);
}
#else
@@ -692,7 +688,7 @@ static inline void *alloc_tramp(unsigned long size)
{
return NULL;
}
-static inline void tramp_free(void *tramp, int size) { }
+static inline void tramp_free(void *tramp) { }
#endif
/* Defined as markers to the end of the ftrace default trampolines */
@@ -808,6 +804,8 @@ create_trampoline(struct ftrace_ops *ops, unsigned int *tramp_size)
/* ALLOC_TRAMP flags lets us know we created it */
ops->flags |= FTRACE_OPS_FL_ALLOC_TRAMP;
+ set_vm_flush_reset_perms(trampoline);
+
/*
* Module allocation needs to be completed by making the page
* executable. The page is still writable, which is a security hazard,
@@ -816,7 +814,7 @@ create_trampoline(struct ftrace_ops *ops, unsigned int *tramp_size)
set_memory_x((unsigned long)trampoline, npages);
return (unsigned long)trampoline;
fail:
- tramp_free(trampoline, *tramp_size);
+ tramp_free(trampoline);
return 0;
}
@@ -947,7 +945,7 @@ void arch_ftrace_trampoline_free(struct ftrace_ops *ops)
if (!ops || !(ops->flags & FTRACE_OPS_FL_ALLOC_TRAMP))
return;
- tramp_free((void *)ops->trampoline, ops->trampoline_size);
+ tramp_free((void *)ops->trampoline);
ops->trampoline = 0;
}
--
2.17.1
^ permalink raw reply related
* [PATCH v6 22/24] x86/alternative: Comment about module removal races
From: nadav.amit @ 2019-04-26 23:23 UTC (permalink / raw)
To: Peter Zijlstra, Borislav Petkov, Andy Lutomirski, Ingo Molnar
Cc: linux-kernel, x86, hpa, Thomas Gleixner, Nadav Amit, Dave Hansen,
linux_dti, linux-integrity, linux-security-module, akpm,
kernel-hardening, linux-mm, will.deacon, ard.biesheuvel, kristen,
deneen.t.dock, Rick Edgecombe, Nadav Amit, Masami Hiramatsu
In-Reply-To: <20190426232303.28381-1-nadav.amit@gmail.com>
From: Nadav Amit <namit@vmware.com>
Add a comment to clarify that users of text_poke() must ensure that
no races with module removal take place.
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---
arch/x86/kernel/alternative.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 18f959975ea0..7b9b49dfc05a 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -810,6 +810,11 @@ static void *__text_poke(void *addr, const void *opcode, size_t len)
* It means the size must be writable atomically and the address must be aligned
* in a way that permits an atomic write. It also makes sure we fit on a single
* page.
+ *
+ * Note that the caller must ensure that if the modified code is part of a
+ * module, the module would not be removed during poking. This can be achieved
+ * by registering a module notifier, and ordering module removal and patching
+ * trough a mutex.
*/
void *text_poke(void *addr, const void *opcode, size_t len)
{
--
2.17.1
^ permalink raw reply related
* [PATCH v6 23/24] mm/tlb: Provide default nmi_uaccess_okay()
From: nadav.amit @ 2019-04-26 23:23 UTC (permalink / raw)
To: Peter Zijlstra, Borislav Petkov, Andy Lutomirski, Ingo Molnar
Cc: linux-kernel, x86, hpa, Thomas Gleixner, Nadav Amit, Dave Hansen,
linux_dti, linux-integrity, linux-security-module, akpm,
kernel-hardening, linux-mm, will.deacon, ard.biesheuvel, kristen,
deneen.t.dock, Rick Edgecombe, Nadav Amit
In-Reply-To: <20190426232303.28381-1-nadav.amit@gmail.com>
From: Nadav Amit <namit@vmware.com>
x86 has an nmi_uaccess_okay(), but other architectures do not.
Arch-independent code might need to know whether access to user
addresses is ok in an NMI context or in other code whose execution
context is unknown. Specifically, this function is needed for
bpf_probe_write_user().
Add a default implementation of nmi_uaccess_okay() for architectures
that do not have such a function.
Signed-off-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---
arch/x86/include/asm/tlbflush.h | 2 ++
include/asm-generic/tlb.h | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 90926e8dd1f8..dee375831962 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -274,6 +274,8 @@ static inline bool nmi_uaccess_okay(void)
return true;
}
+#define nmi_uaccess_okay nmi_uaccess_okay
+
/* Initialize cr4 shadow for this CPU. */
static inline void cr4_init_shadow(void)
{
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index b9edc7608d90..480e5b2a5748 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -21,6 +21,15 @@
#include <asm/tlbflush.h>
#include <asm/cacheflush.h>
+/*
+ * Blindly accessing user memory from NMI context can be dangerous
+ * if we're in the middle of switching the current user task or switching
+ * the loaded mm.
+ */
+#ifndef nmi_uaccess_okay
+# define nmi_uaccess_okay() true
+#endif
+
#ifdef CONFIG_MMU
/*
--
2.17.1
^ permalink raw reply related
* [PATCH v6 24/24] bpf: Fail bpf_probe_write_user() while mm is switched
From: nadav.amit @ 2019-04-26 23:23 UTC (permalink / raw)
To: Peter Zijlstra, Borislav Petkov, Andy Lutomirski, Ingo Molnar
Cc: linux-kernel, x86, hpa, Thomas Gleixner, Nadav Amit, Dave Hansen,
linux_dti, linux-integrity, linux-security-module, akpm,
kernel-hardening, linux-mm, will.deacon, ard.biesheuvel, kristen,
deneen.t.dock, Rick Edgecombe, Nadav Amit, Daniel Borkmann,
Alexei Starovoitov
In-Reply-To: <20190426232303.28381-1-nadav.amit@gmail.com>
From: Nadav Amit <namit@vmware.com>
When using a temporary mm, bpf_probe_write_user() should not be able to
write to user memory, since user memory addresses may be used to map
kernel memory. Detect these cases and fail bpf_probe_write_user() in
such cases.
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Reported-by: Jann Horn <jannh@google.com>
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---
kernel/trace/bpf_trace.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index d64c00afceb5..94b0e37d90ef 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -14,6 +14,8 @@
#include <linux/syscalls.h>
#include <linux/error-injection.h>
+#include <asm/tlb.h>
+
#include "trace_probe.h"
#include "trace.h"
@@ -163,6 +165,10 @@ BPF_CALL_3(bpf_probe_write_user, void *, unsafe_ptr, const void *, src,
* access_ok() should prevent writing to non-user memory, but in
* some situations (nommu, temporary switch, etc) access_ok() does
* not provide enough validation, hence the check on KERNEL_DS.
+ *
+ * nmi_uaccess_okay() ensures the probe is not run in an interim
+ * state, when the task or mm are switched. This is specifically
+ * required to prevent the use of temporary mm.
*/
if (unlikely(in_interrupt() ||
@@ -170,6 +176,8 @@ BPF_CALL_3(bpf_probe_write_user, void *, unsafe_ptr, const void *, src,
return -EPERM;
if (unlikely(uaccess_kernel()))
return -EPERM;
+ if (unlikely(!nmi_uaccess_okay()))
+ return -EPERM;
if (!access_ok(unsafe_ptr, size))
return -EPERM;
--
2.17.1
^ permalink raw reply related
* [PATCH v6 21/24] x86/kprobes: Use vmalloc special flag
From: nadav.amit @ 2019-04-26 23:23 UTC (permalink / raw)
To: Peter Zijlstra, Borislav Petkov, Andy Lutomirski, Ingo Molnar
Cc: linux-kernel, x86, hpa, Thomas Gleixner, Nadav Amit, Dave Hansen,
linux_dti, linux-integrity, linux-security-module, akpm,
kernel-hardening, linux-mm, will.deacon, ard.biesheuvel, kristen,
deneen.t.dock, Rick Edgecombe, Masami Hiramatsu
In-Reply-To: <20190426232303.28381-1-nadav.amit@gmail.com>
From: Rick Edgecombe <rick.p.edgecombe@intel.com>
Use new flag VM_FLUSH_RESET_PERMS for handling freeing of special
permissioned memory in vmalloc and remove places where memory was set NX
and RW before freeing which is no longer needed.
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---
arch/x86/kernel/kprobes/core.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 1591852d3ac4..136695e4434a 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -434,6 +434,7 @@ void *alloc_insn_page(void)
if (!page)
return NULL;
+ set_vm_flush_reset_perms(page);
/*
* First make the page read-only, and only then make it executable to
* prevent it from being W+X in between.
@@ -452,12 +453,6 @@ void *alloc_insn_page(void)
/* Recover page to RW mode before releasing it */
void free_insn_page(void *page)
{
- /*
- * First make the page non-executable, and only then make it writable to
- * prevent it from being W+X in between.
- */
- set_memory_nx((unsigned long)page, 1);
- set_memory_rw((unsigned long)page, 1);
module_memfree(page);
}
--
2.17.1
^ permalink raw reply related
* [PATCH v6 19/24] bpf: Use vmalloc special flag
From: nadav.amit @ 2019-04-26 23:22 UTC (permalink / raw)
To: Peter Zijlstra, Borislav Petkov, Andy Lutomirski, Ingo Molnar
Cc: linux-kernel, x86, hpa, Thomas Gleixner, Nadav Amit, Dave Hansen,
linux_dti, linux-integrity, linux-security-module, akpm,
kernel-hardening, linux-mm, will.deacon, ard.biesheuvel, kristen,
deneen.t.dock, Rick Edgecombe, Daniel Borkmann,
Alexei Starovoitov
In-Reply-To: <20190426232303.28381-1-nadav.amit@gmail.com>
From: Rick Edgecombe <rick.p.edgecombe@intel.com>
Use new flag VM_FLUSH_RESET_PERMS for handling freeing of special
permissioned memory in vmalloc and remove places where memory was set RW
before freeing which is no longer needed. Don't track if the memory is RO
anymore because it is now tracked in vmalloc.
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---
include/linux/filter.h | 17 +++--------------
kernel/bpf/core.c | 1 -
2 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 14ec3bdad9a9..7d3abde3f183 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -20,6 +20,7 @@
#include <linux/set_memory.h>
#include <linux/kallsyms.h>
#include <linux/if_vlan.h>
+#include <linux/vmalloc.h>
#include <net/sch_generic.h>
@@ -503,7 +504,6 @@ struct bpf_prog {
u16 pages; /* Number of allocated pages */
u16 jited:1, /* Is our filter JIT'ed? */
jit_requested:1,/* archs need to JIT the prog */
- undo_set_mem:1, /* Passed set_memory_ro() checkpoint */
gpl_compatible:1, /* Is filter GPL compatible? */
cb_access:1, /* Is control block accessed? */
dst_needed:1, /* Do we need dst entry? */
@@ -733,27 +733,17 @@ bpf_ctx_narrow_access_ok(u32 off, u32 size, u32 size_default)
static inline void bpf_prog_lock_ro(struct bpf_prog *fp)
{
- fp->undo_set_mem = 1;
+ set_vm_flush_reset_perms(fp);
set_memory_ro((unsigned long)fp, fp->pages);
}
-static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
-{
- if (fp->undo_set_mem)
- set_memory_rw((unsigned long)fp, fp->pages);
-}
-
static inline void bpf_jit_binary_lock_ro(struct bpf_binary_header *hdr)
{
+ set_vm_flush_reset_perms(hdr);
set_memory_ro((unsigned long)hdr, hdr->pages);
set_memory_x((unsigned long)hdr, hdr->pages);
}
-static inline void bpf_jit_binary_unlock_ro(struct bpf_binary_header *hdr)
-{
- set_memory_rw((unsigned long)hdr, hdr->pages);
-}
-
static inline struct bpf_binary_header *
bpf_jit_binary_hdr(const struct bpf_prog *fp)
{
@@ -789,7 +779,6 @@ void __bpf_prog_free(struct bpf_prog *fp);
static inline void bpf_prog_unlock_free(struct bpf_prog *fp)
{
- bpf_prog_unlock_ro(fp);
__bpf_prog_free(fp);
}
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index ff09d32a8a1b..c605397c79f0 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -848,7 +848,6 @@ void __weak bpf_jit_free(struct bpf_prog *fp)
if (fp->jited) {
struct bpf_binary_header *hdr = bpf_jit_binary_hdr(fp);
- bpf_jit_binary_unlock_ro(hdr);
bpf_jit_binary_free(hdr);
WARN_ON_ONCE(!bpf_prog_kallsyms_verify_off(fp));
--
2.17.1
^ permalink raw reply related
* [PATCH v6 03/24] x86/mm: Introduce temporary mm structs
From: nadav.amit @ 2019-04-26 23:22 UTC (permalink / raw)
To: Peter Zijlstra, Borislav Petkov, Andy Lutomirski, Ingo Molnar
Cc: linux-kernel, x86, hpa, Thomas Gleixner, Nadav Amit, Dave Hansen,
linux_dti, linux-integrity, linux-security-module, akpm,
kernel-hardening, linux-mm, will.deacon, ard.biesheuvel, kristen,
deneen.t.dock, Rick Edgecombe, Kees Cook, Dave Hansen, Nadav Amit
In-Reply-To: <20190426232303.28381-1-nadav.amit@gmail.com>
From: Andy Lutomirski <luto@kernel.org>
Using a dedicated page-table for temporary PTEs prevents other cores
from using - even speculatively - these PTEs, thereby providing two
benefits:
(1) Security hardening: an attacker that gains kernel memory writing
abilities cannot easily overwrite sensitive data.
(2) Avoiding TLB shootdowns: the PTEs do not need to be flushed in
remote page-tables.
To do so a temporary mm_struct can be used. Mappings which are private
for this mm can be set in the userspace part of the address-space.
During the whole time in which the temporary mm is loaded, interrupts
must be disabled.
The first use-case for temporary mm struct, which will follow, is for
poking the kernel text.
[ Commit message was written by Nadav Amit ]
Cc: Kees Cook <keescook@chromium.org>
Cc: Dave Hansen <dave.hansen@intel.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---
arch/x86/include/asm/mmu_context.h | 33 ++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
index 19d18fae6ec6..24dc3b810970 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -356,4 +356,37 @@ static inline unsigned long __get_current_cr3_fast(void)
return cr3;
}
+typedef struct {
+ struct mm_struct *mm;
+} temp_mm_state_t;
+
+/*
+ * Using a temporary mm allows to set temporary mappings that are not accessible
+ * by other CPUs. Such mappings are needed to perform sensitive memory writes
+ * that override the kernel memory protections (e.g., W^X), without exposing the
+ * temporary page-table mappings that are required for these write operations to
+ * other CPUs. Using a temporary mm also allows to avoid TLB shootdowns when the
+ * mapping is torn down.
+ *
+ * Context: The temporary mm needs to be used exclusively by a single core. To
+ * harden security IRQs must be disabled while the temporary mm is
+ * loaded, thereby preventing interrupt handler bugs from overriding
+ * the kernel memory protection.
+ */
+static inline temp_mm_state_t use_temporary_mm(struct mm_struct *mm)
+{
+ temp_mm_state_t temp_state;
+
+ lockdep_assert_irqs_disabled();
+ temp_state.mm = this_cpu_read(cpu_tlbstate.loaded_mm);
+ switch_mm_irqs_off(NULL, mm, current);
+ return temp_state;
+}
+
+static inline void unuse_temporary_mm(temp_mm_state_t prev_state)
+{
+ lockdep_assert_irqs_disabled();
+ switch_mm_irqs_off(NULL, prev_state.mm, current);
+}
+
#endif /* _ASM_X86_MMU_CONTEXT_H */
--
2.17.1
^ permalink raw reply related
* [PATCH v6 00/24] x86: text_poke() fixes and executable lockdowns
From: nadav.amit @ 2019-04-26 23:22 UTC (permalink / raw)
To: Peter Zijlstra, Borislav Petkov, Andy Lutomirski, Ingo Molnar
Cc: linux-kernel, x86, hpa, Thomas Gleixner, Nadav Amit, Dave Hansen,
linux_dti, linux-integrity, linux-security-module, akpm,
kernel-hardening, linux-mm, will.deacon, ard.biesheuvel, kristen,
deneen.t.dock, Rick Edgecombe, Nadav Amit
From: Nadav Amit <namit@vmware.com>
*
* This version fixes failed boots on 32-bit that were reported by 0day.
* Patch 5 is added to initialize uprobes during fork initialization.
* Patch 7 (which was 6 in the previous version) is updated - the code is
* moved to common mm-init code with no further changes.
*
This patchset improves several overlapping issues around stale TLB
entries and W^X violations. It is combined from "x86/alternative:
text_poke() enhancements v7" [1] and "Don't leave executable TLB entries
to freed pages v2" [2] patchsets that were conflicting.
The related issues that this fixes:
1. Fixmap PTEs that are used for patching are available for access from
other cores and might be exploited. They are not even flushed from
the TLB in remote cores, so the risk is even higher. Address this
issue by introducing a temporary mm that is only used during
patching. Unfortunately, due to init ordering, fixmap is still used
during boot-time patching. Future patches can eliminate the need for
it.
2. Missing lockdep assertion to ensure text_mutex is taken. It is
actually not always taken, so fix the instances that were found not
to take the lock (although they should be safe even without taking
the lock).
3. Module_alloc returning memory that is RWX until a module is finished
loading.
4. 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.
Changes v5 to v6:
- Move poking_mm initialization to common x86 mm init [0day]
- Initialize uprobes during fork initialization [0day]
Changes v4 to v5:
- Change temporary state variable name [Borislav]
- Commit log and comment fixes [Borislav]
Changes v3 to v4:
- Remove the size parameter from tramp_free() [Steven]
- Remove caching of hw_breakpoint_active() [Sean]
- Prevent the use of bpf_probe_write_user() while using temporary mm [Jann]
- Fix build issues on other archs
Changes v2 to v3:
- Fix commit messages and comments [Boris]
- Rename VM_HAS_SPECIAL_PERMS [Boris]
- Remove unnecessary local variables [Boris]
- Rename set_alias_*() functions [Boris, Andy]
- Save/restore DR registers when using temporary mm
- Move line deletion from patch 10 to patch 17
Changes v1 to v2:
- Adding "Reviewed-by tag" [Masami]
- Comment instead of code to warn against module removal while
patching [Masami]
- Avoiding open-coded TLB flush [Andy]
- Remove "This patch" [Borislav Petkov]
- Not set global bit during text poking [Andy, hpa]
- Add Ack from [Pavel Machek]
- Split patch 16 "Plug in new special vfree flag" into 4 patches (16-19)
to make it easier to review. There were no code changes.
The changes from "Don't leave executable TLB entries to freed pages
v2" to v1:
- Add support for case of hibernate trying to save an unmapped page
on the directmap. (Ard Biesheuvel)
- No week arch breakout for vfree-ing special memory (Andy Lutomirski)
- Avoid changing deferred free code by moving modules init free to work
queue (Andy Lutomirski)
- Plug in new flag for kprobes and ftrace
- More arch generic names for set_pages functions (Ard Biesheuvel)
- Fix for TLB not always flushing the directmap (Nadav Amit)
Changes from "x86/alternative: text_poke() enhancements v7" to v1
- Fix build failure on CONFIG_RANDOMIZE_BASE=n (Rick)
- Remove text_poke usage from ftrace (Nadav)
[1] https://lkml.org/lkml/2018/12/5/200
[2] https://lkml.org/lkml/2018/12/11/1571
Andy Lutomirski (1):
x86/mm: Introduce temporary mm structs
Nadav Amit (16):
Fix "x86/alternatives: Lockdep-enforce text_mutex in text_poke*()"
x86/jump_label: Use text_poke_early() during early init
x86/mm: Save debug registers when loading a temporary mm
uprobes: Initialize uprobes earlier
fork: Provide a function for copying init_mm
x86/alternative: Initialize temporary mm for patching
x86/alternative: Use temporary mm for text poking
x86/kgdb: Avoid redundant comparison of patched code
x86/ftrace: Set trampoline pages as executable
x86/kprobes: Set instruction page as executable
x86/module: Avoid breaking W^X while loading modules
x86/jump-label: Remove support for custom poker
x86/alternative: Remove the return value of text_poke_*()
x86/alternative: Comment about module removal races
mm/tlb: Provide default nmi_uaccess_okay()
bpf: Fail bpf_probe_write_user() while mm is switched
Rick Edgecombe (7):
x86/mm/cpa: Add set_direct_map_ functions
mm: Make hibernate handle unmapped pages
vmalloc: Add flag for free of special permsissions
modules: Use vmalloc special flag
bpf: Use vmalloc special flag
x86/ftrace: Use vmalloc special flag
x86/kprobes: Use vmalloc special flag
arch/Kconfig | 4 +
arch/x86/Kconfig | 1 +
arch/x86/include/asm/fixmap.h | 2 -
arch/x86/include/asm/mmu_context.h | 56 ++++++++
arch/x86/include/asm/pgtable.h | 3 +
arch/x86/include/asm/set_memory.h | 3 +
arch/x86/include/asm/text-patching.h | 7 +-
arch/x86/include/asm/tlbflush.h | 2 +
arch/x86/kernel/alternative.c | 201 ++++++++++++++++++++-------
arch/x86/kernel/ftrace.c | 22 +--
arch/x86/kernel/jump_label.c | 21 ++-
arch/x86/kernel/kgdb.c | 25 +---
arch/x86/kernel/kprobes/core.c | 19 ++-
arch/x86/kernel/module.c | 2 +-
arch/x86/mm/init.c | 37 +++++
arch/x86/mm/pageattr.c | 16 ++-
arch/x86/xen/mmu_pv.c | 2 -
include/asm-generic/tlb.h | 9 ++
include/linux/filter.h | 18 +--
include/linux/mm.h | 18 +--
include/linux/sched/task.h | 1 +
include/linux/set_memory.h | 11 ++
include/linux/uprobes.h | 5 +
include/linux/vmalloc.h | 15 ++
init/main.c | 3 +
kernel/bpf/core.c | 1 -
kernel/events/uprobes.c | 8 +-
kernel/fork.c | 25 +++-
kernel/module.c | 82 ++++++-----
kernel/power/snapshot.c | 5 +-
kernel/trace/bpf_trace.c | 8 ++
mm/page_alloc.c | 7 +-
mm/vmalloc.c | 113 ++++++++++++---
33 files changed, 552 insertions(+), 200 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH AUTOSEL 5.0 52/79] KEYS: trusted: fix -Wvarags warning
From: Sasha Levin @ 2019-04-27 1:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: ndesaulniers@google.com, Jarkko Sakkinen, James Morris,
Sasha Levin, keyrings, linux-integrity, linux-security-module
In-Reply-To: <20190427013838.6596-1-sashal@kernel.org>
From: "ndesaulniers@google.com" <ndesaulniers@google.com>
[ Upstream commit be24b37e22c20cbaa891971616784dd0f35211e8 ]
Fixes the warning reported by Clang:
security/keys/trusted.c:146:17: warning: passing an object that
undergoes default
argument promotion to 'va_start' has undefined behavior [-Wvarargs]
va_start(argp, h3);
^
security/keys/trusted.c:126:37: note: parameter of type 'unsigned
char' is declared here
unsigned char *h2, unsigned char h3, ...)
^
Specifically, it seems that both the C90 (4.8.1.1) and C11 (7.16.1.4)
standards explicitly call this out as undefined behavior:
The parameter parmN is the identifier of the rightmost parameter in
the variable parameter list in the function definition (the one just
before the ...). If the parameter parmN is declared with ... or with a
type that is not compatible with the type that results after
application of the default argument promotions, the behavior is
undefined.
Link: https://github.com/ClangBuiltLinux/linux/issues/41
Link: https://www.eskimo.com/~scs/cclass/int/sx11c.html
Suggested-by: David Laight <David.Laight@aculab.com>
Suggested-by: Denis Kenzior <denkenz@gmail.com>
Suggested-by: James Bottomley <jejb@linux.vnet.ibm.com>
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: James Morris <james.morris@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/keys/trusted.h | 2 +-
security/keys/trusted.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/keys/trusted.h b/include/keys/trusted.h
index adbcb6817826..0071298b9b28 100644
--- a/include/keys/trusted.h
+++ b/include/keys/trusted.h
@@ -38,7 +38,7 @@ enum {
int TSS_authhmac(unsigned char *digest, const unsigned char *key,
unsigned int keylen, unsigned char *h1,
- unsigned char *h2, unsigned char h3, ...);
+ unsigned char *h2, unsigned int h3, ...);
int TSS_checkhmac1(unsigned char *buffer,
const uint32_t command,
const unsigned char *ononce,
diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index 4d98f4f87236..94d2b28c7c22 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -123,7 +123,7 @@ out:
*/
int TSS_authhmac(unsigned char *digest, const unsigned char *key,
unsigned int keylen, unsigned char *h1,
- unsigned char *h2, unsigned char h3, ...)
+ unsigned char *h2, unsigned int h3, ...)
{
unsigned char paramdigest[SHA1_DIGEST_SIZE];
struct sdesc *sdesc;
@@ -139,7 +139,7 @@ int TSS_authhmac(unsigned char *digest, const unsigned char *key,
return PTR_ERR(sdesc);
}
- c = h3;
+ c = !!h3;
ret = crypto_shash_init(&sdesc->shash);
if (ret < 0)
goto out;
--
2.19.1
^ permalink raw reply related
* Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
From: Andy Lutomirski @ 2019-04-26 21:26 UTC (permalink / raw)
To: Ingo Molnar
Cc: Mike Rapoport, LKML, Alexandre Chartre, Andy Lutomirski,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Ingo Molnar,
James Bottomley, Jonathan Adams, Kees Cook, Paul Turner,
Peter Zijlstra, Thomas Gleixner, Linux-MM, LSM List, X86 ML,
Linus Torvalds, Peter Zijlstra, Andrew Morton
In-Reply-To: <20190426095802.GA35515@gmail.com>
> On Apr 26, 2019, at 2:58 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Ingo Molnar <mingo@kernel.org> wrote:
>
>> I really don't like it where this is going. In a couple of years I
>> really want to be able to think of PTI as a bad dream that is mostly
>> over fortunately.
>>
>> I have the feeling that compiler level protection that avoids
>> corrupting the stack in the first place is going to be lower overhead,
>> and would work in a much broader range of environments. Do we have
>> analysis of what the compiler would have to do to prevent most ROP
>> attacks, and what the runtime cost of that is?
>>
>> I mean, C# and Java programs aren't able to corrupt the stack as long
>> as the language runtime is corect. Has to be possible, right?
>
> So if such security feature is offered then I'm afraid distros would be
> strongly inclined to enable it - saying 'yes' to a kernel feature that
> can keep your product off CVE advisories is a strong force.
>
> To phrase the argument in a bit more controversial form:
>
> If the price of Linux using an insecure C runtime is to slow down
> system calls with immense PTI-alike runtime costs, then wouldn't it be
> the right technical decision to write the kernel in a language runtime
> that doesn't allow stack overflows and such?
>
> I.e. if having Linux in C ends up being slower than having it in Java,
> then what's the performance argument in favor of using C to begin with?
> ;-)
>
> And no, I'm not arguing for Java or C#, but I am arguing for a saner
> version of C.
>
>
IMO three are three credible choices:
1. C with fairly strong CFI protection. Grsecurity has his (supposedly
— there’s a distinct lack of source code available), and clang is
gradually working on it.
2. A safe language for parts of the kernel, e.g. drivers and maybe
eventually filesystems. Rust is probably the only credible candidate.
Actually creating a decent Rust wrapper around the core kernel
facilities would be quite a bit of work. Things like sysfs would be
interesting in Rust, since AFAIK few or even no drivers actually get
the locking fully correct. This means that naive users of the API
cannot port directly to safe Rust, because all the races won't compile
:)
3. A sandbox for parts of the kernel, e.g. drivers. The obvious
candidates are eBPF and WASM.
#2 will give very good performance. #3 gives potentially stronger
protection against a sandboxed component corrupting the kernel
overall, but it gives much weaker protection against a sandboxed
component corrupting itself.
In an ideal world, we could do #2 *and* #3. Drivers could, for
example, be written in a language like Rust, compiled to WASM, and run
in the kernel.
^ permalink raw reply
* Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
From: Andy Lutomirski @ 2019-04-26 19:22 UTC (permalink / raw)
To: James Bottomley
Cc: Dave Hansen, Mike Rapoport, linux-kernel, Alexandre Chartre,
Andy Lutomirski, Borislav Petkov, Dave Hansen, H. Peter Anvin,
Ingo Molnar, Jonathan Adams, Kees Cook, Paul Turner,
Peter Zijlstra, Thomas Gleixner, linux-mm, linux-security-module,
x86
In-Reply-To: <1556304567.2833.62.camel@HansenPartnership.com>
> On Apr 26, 2019, at 11:49 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote:
>
> On Fri, 2019-04-26 at 10:40 -0700, Andy Lutomirski wrote:
>>> On Apr 26, 2019, at 8:19 AM, James Bottomley <James.Bottomley@hanse
>>> npartnership.com> wrote:
>>>
>>> On Fri, 2019-04-26 at 08:07 -0700, Andy Lutomirski wrote:
>>>>> On Apr 26, 2019, at 7:57 AM, James Bottomley
>>>>> <James.Bottomley@hansenpartnership.com> wrote:
>>>>>
>>>>>>> On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote:
>>>>>>> On 4/25/19 2:45 PM, Mike Rapoport wrote:
>>>>>>> After the isolated system call finishes, the mappings
>>>>>>> created during its execution are cleared.
>>>>>>
>>>>>> Yikes. I guess that stops someone from calling write() a
>>>>>> bunch of times on every filesystem using every block device
>>>>>> driver and all the DM code to get a lot of code/data faulted
>>>>>> in. But, it also means not even long-running processes will
>>>>>> ever have a chance of behaving anything close to normally.
>>>>>>
>>>>>> Is this something you think can be rectified or is there
>>>>>> something fundamental that would keep SCI page tables from
>>>>>> being cached across different invocations of the same
>>>>>> syscall?
>>>>>
>>>>> There is some work being done to look at pre-populating the
>>>>> isolated address space with the expected execution footprint of
>>>>> the system call, yes. It lessens the ROP gadget protection
>>>>> slightly because you might find a gadget in the pre-populated
>>>>> code, but it solves a lot of the overhead problem.
>>>>
>>>> I’m not even remotely a ROP expert, but: what stops a ROP payload
>>>> from using all the “fault-in” gadgets that exist — any function
>>>> that can return on an error without doing to much will fault in
>>>> the whole page containing the function.
>>>
>>> The address space pre-population is still per syscall, so you don't
>>> get access to the code footprint of a different syscall. So the
>>> isolated address space is created anew for every system call, it's
>>> just pre-populated with that system call's expected footprint.
>>
>> That’s not what I mean. Suppose I want to use a ROP gadget in
>> vmalloc(), but vmalloc isn’t in the page tables. Then first push
>> vmalloc itself into the stack. As long as RDI contains a sufficiently
>> ridiculous value, it should just return without doing anything. And
>> it can return right back into the ROP gadget, which is now available.
>
> Yes, it's not perfect, but stack space for a smashing attack is at a
> premium and now you need two stack frames for every gadget you chain
> instead of one so we've halved your ability to chain gadgets.
>
>>>> To improve this, we would want some thing that would try to check
>>>> whether the caller is actually supposed to call the callee, which
>>>> is more or less the hard part of CFI. So can’t we just do CFI
>>>> and call it a day?
>>>
>>> By CFI you mean control flow integrity? In theory I believe so,
>>> yes, but in practice doesn't it require a lot of semantic object
>>> information which is easy to get from higher level languages like
>>> java but a bit more difficult for plain C.
>>
>> Yes. As I understand it, grsecurity instruments gcc to create some
>> kind of hash of all function signatures. Then any indirect call can
>> effectively verify that it’s calling a function of the right type.
>> And every return verified a cookie.
>>
>> On CET CPUs, RET gets checked directly, and I don’t see the benefit
>> of SCI.
>
> Presumably you know something I don't but I thought CET CPUs had been
> planned for release for ages, but not actually released yet?
I don’t know any secrets about this, but I don’t think it’s released. Last I checked, it didn’t even have a final public spec.
>
>>>> On top of that, a robust, maintainable implementation of this
>>>> thing seems very complicated — for example, what happens if
>>>> vfree() gets called?
>>>
>>> Address space Local vs global object tracking is another thing on
>>> our list. What we'd probably do is verify the global object was
>>> allowed to be freed and then hand it off safely to the main kernel
>>> address space.
>>
>> This seems exceedingly complicated.
>
> It's a research project: we're exploring what's possible so we can
> choose the techniques that give the best security improvement for the
> additional overhead.
>
:)
^ permalink raw reply
* Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
From: James Bottomley @ 2019-04-26 18:49 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Dave Hansen, Mike Rapoport, linux-kernel, Alexandre Chartre,
Andy Lutomirski, Borislav Petkov, Dave Hansen, H. Peter Anvin,
Ingo Molnar, Jonathan Adams, Kees Cook, Paul Turner,
Peter Zijlstra, Thomas Gleixner, linux-mm, linux-security-module,
x86
In-Reply-To: <8E695557-1CD2-431A-99CC-49A4E8247BAE@amacapital.net>
On Fri, 2019-04-26 at 10:40 -0700, Andy Lutomirski wrote:
> > On Apr 26, 2019, at 8:19 AM, James Bottomley <James.Bottomley@hanse
> > npartnership.com> wrote:
> >
> > On Fri, 2019-04-26 at 08:07 -0700, Andy Lutomirski wrote:
> > > > On Apr 26, 2019, at 7:57 AM, James Bottomley
> > > > <James.Bottomley@hansenpartnership.com> wrote:
> > > >
> > > > > > On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote:
> > > > > > On 4/25/19 2:45 PM, Mike Rapoport wrote:
> > > > > > After the isolated system call finishes, the mappings
> > > > > > created during its execution are cleared.
> > > > >
> > > > > Yikes. I guess that stops someone from calling write() a
> > > > > bunch of times on every filesystem using every block device
> > > > > driver and all the DM code to get a lot of code/data faulted
> > > > > in. But, it also means not even long-running processes will
> > > > > ever have a chance of behaving anything close to normally.
> > > > >
> > > > > Is this something you think can be rectified or is there
> > > > > something fundamental that would keep SCI page tables from
> > > > > being cached across different invocations of the same
> > > > > syscall?
> > > >
> > > > There is some work being done to look at pre-populating the
> > > > isolated address space with the expected execution footprint of
> > > > the system call, yes. It lessens the ROP gadget protection
> > > > slightly because you might find a gadget in the pre-populated
> > > > code, but it solves a lot of the overhead problem.
> > >
> > > I’m not even remotely a ROP expert, but: what stops a ROP payload
> > > from using all the “fault-in” gadgets that exist — any function
> > > that can return on an error without doing to much will fault in
> > > the whole page containing the function.
> >
> > The address space pre-population is still per syscall, so you don't
> > get access to the code footprint of a different syscall. So the
> > isolated address space is created anew for every system call, it's
> > just pre-populated with that system call's expected footprint.
>
> That’s not what I mean. Suppose I want to use a ROP gadget in
> vmalloc(), but vmalloc isn’t in the page tables. Then first push
> vmalloc itself into the stack. As long as RDI contains a sufficiently
> ridiculous value, it should just return without doing anything. And
> it can return right back into the ROP gadget, which is now available.
Yes, it's not perfect, but stack space for a smashing attack is at a
premium and now you need two stack frames for every gadget you chain
instead of one so we've halved your ability to chain gadgets.
> > > To improve this, we would want some thing that would try to check
> > > whether the caller is actually supposed to call the callee, which
> > > is more or less the hard part of CFI. So can’t we just do CFI
> > > and call it a day?
> >
> > By CFI you mean control flow integrity? In theory I believe so,
> > yes, but in practice doesn't it require a lot of semantic object
> > information which is easy to get from higher level languages like
> > java but a bit more difficult for plain C.
>
> Yes. As I understand it, grsecurity instruments gcc to create some
> kind of hash of all function signatures. Then any indirect call can
> effectively verify that it’s calling a function of the right type.
> And every return verified a cookie.
>
> On CET CPUs, RET gets checked directly, and I don’t see the benefit
> of SCI.
Presumably you know something I don't but I thought CET CPUs had been
planned for release for ages, but not actually released yet?
> > > On top of that, a robust, maintainable implementation of this
> > > thing seems very complicated — for example, what happens if
> > > vfree() gets called?
> >
> > Address space Local vs global object tracking is another thing on
> > our list. What we'd probably do is verify the global object was
> > allowed to be freed and then hand it off safely to the main kernel
> > address space.
>
> This seems exceedingly complicated.
It's a research project: we're exploring what's possible so we can
choose the techniques that give the best security improvement for the
additional overhead.
James
^ permalink raw reply
* Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
From: Andy Lutomirski @ 2019-04-26 17:40 UTC (permalink / raw)
To: James Bottomley
Cc: Dave Hansen, Mike Rapoport, linux-kernel, Alexandre Chartre,
Andy Lutomirski, Borislav Petkov, Dave Hansen, H. Peter Anvin,
Ingo Molnar, Jonathan Adams, Kees Cook, Paul Turner,
Peter Zijlstra, Thomas Gleixner, linux-mm, linux-security-module,
x86
In-Reply-To: <1556291961.2833.42.camel@HansenPartnership.com>
> On Apr 26, 2019, at 8:19 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote:
>
> On Fri, 2019-04-26 at 08:07 -0700, Andy Lutomirski wrote:
>>> On Apr 26, 2019, at 7:57 AM, James Bottomley <James.Bottomley@hanse
>>> npartnership.com> wrote:
>>>
>>>>> On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote:
>>>>> On 4/25/19 2:45 PM, Mike Rapoport wrote:
>>>>> After the isolated system call finishes, the mappings created
>>>>> during its execution are cleared.
>>>>
>>>> Yikes. I guess that stops someone from calling write() a bunch
>>>> of times on every filesystem using every block device driver and
>>>> all the DM code to get a lot of code/data faulted in. But, it
>>>> also means not even long-running processes will ever have a
>>>> chance of behaving anything close to normally.
>>>>
>>>> Is this something you think can be rectified or is there
>>>> something fundamental that would keep SCI page tables from being
>>>> cached across different invocations of the same syscall?
>>>
>>> There is some work being done to look at pre-populating the
>>> isolated address space with the expected execution footprint of the
>>> system call, yes. It lessens the ROP gadget protection slightly
>>> because you might find a gadget in the pre-populated code, but it
>>> solves a lot of the overhead problem.
>>
>> I’m not even remotely a ROP expert, but: what stops a ROP payload
>> from using all the “fault-in” gadgets that exist — any function that
>> can return on an error without doing to much will fault in the whole
>> page containing the function.
>
> The address space pre-population is still per syscall, so you don't get
> access to the code footprint of a different syscall. So the isolated
> address space is created anew for every system call, it's just pre-
> populated with that system call's expected footprint.
That’s not what I mean. Suppose I want to use a ROP gadget in vmalloc(), but vmalloc isn’t in the page tables. Then first push vmalloc itself into the stack. As long as RDI contains a sufficiently ridiculous value, it should just return without doing anything. And it can return right back into the ROP gadget, which is now available.
>
>> To improve this, we would want some thing that would try to check
>> whether the caller is actually supposed to call the callee, which is
>> more or less the hard part of CFI. So can’t we just do CFI and call
>> it a day?
>
> By CFI you mean control flow integrity? In theory I believe so, yes,
> but in practice doesn't it require a lot of semantic object information
> which is easy to get from higher level languages like java but a bit
> more difficult for plain C.
Yes. As I understand it, grsecurity instruments gcc to create some kind of hash of all function signatures. Then any indirect call can effectively verify that it’s calling a function of the right type. And every return verified a cookie.
On CET CPUs, RET gets checked directly, and I don’t see the benefit of SCI.
>
>> On top of that, a robust, maintainable implementation of this thing
>> seems very complicated — for example, what happens if vfree() gets
>> called?
>
> Address space Local vs global object tracking is another thing on our
> list. What we'd probably do is verify the global object was allowed to
> be freed and then hand it off safely to the main kernel address space.
>
>
This seems exceedingly complicated.
^ permalink raw reply
* Re: [PATCH v5 14/23] x86/mm/cpa: Add set_direct_map_ functions
From: Nadav Amit @ 2019-04-26 16:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Peter Zijlstra, Borislav Petkov, Andy Lutomirski, Ingo Molnar,
lkml, the arch/x86 maintainers, H. Peter Anvin, Thomas Gleixner,
Dave Hansen, Damian Tometzki, linux-integrity, LSM List,
Andrew Morton, Kernel Hardening, Linux-MM, Will Deacon,
Ard Biesheuvel, kristen@linux.intel.com, deneen.t.dock@intel.com,
Rick Edgecombe
In-Reply-To: <CAADWXX8yZJ9Z4yfqG9wQcb2r+0O7VCk2uQLcOU1=-BOnYhjnow@mail.gmail.com>
> On Apr 26, 2019, at 9:40 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> Nadav,
>
> I get
>
> dmarc=fail (p=QUARANTINE sp=NONE dis=QUARANTINE) header.from=vmware.com
>
> for these emails, because they lack the vmware DKIM signature.
>
> It clearly did go through some vmware mail servers, but apparently not
> the *right* external vmware SMTP gateway.
>
> Please check with vmware MIS what the right SMTP setup for git-send-email is.
Err.. Sorry for that. For the time being I’ll use gmail instead.
^ permalink raw reply
* Re: [PATCH v5 14/23] x86/mm/cpa: Add set_direct_map_ functions
From: Linus Torvalds @ 2019-04-26 16:40 UTC (permalink / raw)
To: Nadav Amit
Cc: Peter Zijlstra, Borislav Petkov, Andy Lutomirski, Ingo Molnar,
lkml, the arch/x86 maintainers, H. Peter Anvin, Thomas Gleixner,
Nadav Amit, Dave Hansen, linux_dti, linux-integrity, LSM List,
Andrew Morton, kernel-hardening, Linux-MM, Will Deacon,
Ard Biesheuvel, kristen, deneen.t.dock, Rick Edgecombe
In-Reply-To: <20190426001143.4983-15-namit@vmware.com>
Nadav,
I get
dmarc=fail (p=QUARANTINE sp=NONE dis=QUARANTINE) header.from=vmware.com
for these emails, because they lack the vmware DKIM signature.
It clearly did go through some vmware mail servers, but apparently not
the *right* external vmware SMTP gateway.
Please check with vmware MIS what the right SMTP setup for git-send-email is.
Linus
On Fri, Apr 26, 2019 at 12:32 AM Nadav Amit <namit@vmware.com> wrote:
>
> From: Rick Edgecombe <rick.p.edgecombe@intel.com>
>
> Add two new functions set_direct_map_default_noflush() and
> set_direct_map_invalid_noflush() for setting the direct map alias for the
> page to its default valid permissions and to an invalid state that cannot
> be cached in a TLB, respectively. These functions do not flush the TLB.
...
^ permalink raw reply
* Re: [PATCH 1/3] mm: security: introduce the init_allocations=1 boot option
From: Alexander Potapenko @ 2019-04-26 15:48 UTC (permalink / raw)
To: Christopher Lameter
Cc: Andrew Morton, Dmitriy Vyukov, Kees Cook, Laura Abbott,
Linux Memory Management List, linux-security-module,
Kernel Hardening
In-Reply-To: <0100016a5a3f6121-e7ed483e-bc29-4d75-bd0a-8e3b973529f5-000000@email.amazonses.com>
On Fri, Apr 26, 2019 at 5:24 PM Christopher Lameter <cl@linux.com> wrote:
>
> Hmmmm.... Maybe its better to zero on free? That way you dont need to
> initialize the allocations. You could even check if someone mucked with
> the object during allocation.
As mentioned somewhere in the neighboring threads, Kees requested the
options to initialize on both allocation and free, because we'll need
this functionality for memory tagging someday.
> This is a replication of some of the
> inherent debugging facilities in the allocator though.
I'm curious, how often do people use SL[AU]B poisoning and redzones these days?
Guess those should be superseded by KASAN already?
I agree it makes sense to reuse the existing debugging code, but on
the other hand we probably want to keep the initialization fast enough
to be used in production.
>
Re: poison_fn, it wasn't a good idea, so I'll be dropping it.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: [PATCH 1/3] mm: security: introduce the init_allocations=1 boot option
From: Christopher Lameter @ 2019-04-26 15:24 UTC (permalink / raw)
To: Alexander Potapenko
Cc: akpm, dvyukov, keescook, labbott, linux-mm, linux-security-module,
kernel-hardening
In-Reply-To: <alpine.DEB.2.21.1904260911570.8340@nuc-kabylake>
Hmmmm.... Maybe its better to zero on free? That way you dont need to
initialize the allocations. You could even check if someone mucked with
the object during allocation. This is a replication of some of the
inherent debugging facilities in the allocator though.
^ permalink raw reply
* Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
From: James Bottomley @ 2019-04-26 15:19 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Dave Hansen, Mike Rapoport, linux-kernel, Alexandre Chartre,
Andy Lutomirski, Borislav Petkov, Dave Hansen, H. Peter Anvin,
Ingo Molnar, Jonathan Adams, Kees Cook, Paul Turner,
Peter Zijlstra, Thomas Gleixner, linux-mm, linux-security-module,
x86
In-Reply-To: <54090243-E4C7-4C66-8025-AFE0DF5DF337@amacapital.net>
On Fri, 2019-04-26 at 08:07 -0700, Andy Lutomirski wrote:
> > On Apr 26, 2019, at 7:57 AM, James Bottomley <James.Bottomley@hanse
> > npartnership.com> wrote:
> >
> > > On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote:
> > > > On 4/25/19 2:45 PM, Mike Rapoport wrote:
> > > > After the isolated system call finishes, the mappings created
> > > > during its execution are cleared.
> > >
> > > Yikes. I guess that stops someone from calling write() a bunch
> > > of times on every filesystem using every block device driver and
> > > all the DM code to get a lot of code/data faulted in. But, it
> > > also means not even long-running processes will ever have a
> > > chance of behaving anything close to normally.
> > >
> > > Is this something you think can be rectified or is there
> > > something fundamental that would keep SCI page tables from being
> > > cached across different invocations of the same syscall?
> >
> > There is some work being done to look at pre-populating the
> > isolated address space with the expected execution footprint of the
> > system call, yes. It lessens the ROP gadget protection slightly
> > because you might find a gadget in the pre-populated code, but it
> > solves a lot of the overhead problem.
> >
>
> I’m not even remotely a ROP expert, but: what stops a ROP payload
> from using all the “fault-in” gadgets that exist — any function that
> can return on an error without doing to much will fault in the whole
> page containing the function.
The address space pre-population is still per syscall, so you don't get
access to the code footprint of a different syscall. So the isolated
address space is created anew for every system call, it's just pre-
populated with that system call's expected footprint.
> To improve this, we would want some thing that would try to check
> whether the caller is actually supposed to call the callee, which is
> more or less the hard part of CFI. So can’t we just do CFI and call
> it a day?
By CFI you mean control flow integrity? In theory I believe so, yes,
but in practice doesn't it require a lot of semantic object information
which is easy to get from higher level languages like java but a bit
more difficult for plain C.
> On top of that, a robust, maintainable implementation of this thing
> seems very complicated — for example, what happens if vfree() gets
> called?
Address space Local vs global object tracking is another thing on our
list. What we'd probably do is verify the global object was allowed to
be freed and then hand it off safely to the main kernel address space.
James
^ permalink raw reply
* Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
From: Andy Lutomirski @ 2019-04-26 15:07 UTC (permalink / raw)
To: James Bottomley
Cc: Dave Hansen, Mike Rapoport, linux-kernel, Alexandre Chartre,
Andy Lutomirski, Borislav Petkov, Dave Hansen, H. Peter Anvin,
Ingo Molnar, Jonathan Adams, Kees Cook, Paul Turner,
Peter Zijlstra, Thomas Gleixner, linux-mm, linux-security-module,
x86
In-Reply-To: <1556290658.2833.28.camel@HansenPartnership.com>
> On Apr 26, 2019, at 7:57 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote:
>
>> On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote:
>>> On 4/25/19 2:45 PM, Mike Rapoport wrote:
>>> After the isolated system call finishes, the mappings created
>>> during its execution are cleared.
>>
>> Yikes. I guess that stops someone from calling write() a bunch of
>> times on every filesystem using every block device driver and all the
>> DM code to get a lot of code/data faulted in. But, it also means not
>> even long-running processes will ever have a chance of behaving
>> anything close to normally.
>>
>> Is this something you think can be rectified or is there something
>> fundamental that would keep SCI page tables from being cached across
>> different invocations of the same syscall?
>
> There is some work being done to look at pre-populating the isolated
> address space with the expected execution footprint of the system call,
> yes. It lessens the ROP gadget protection slightly because you might
> find a gadget in the pre-populated code, but it solves a lot of the
> overhead problem.
>
I’m not even remotely a ROP expert, but: what stops a ROP payload from using all the “fault-in” gadgets that exist — any function that can return on an error without doing to much will fault in the whole page containing the function.
To improve this, we would want some thing that would try to check whether the caller is actually supposed to call the callee, which is more or less the hard part of CFI. So can’t we just do CFI and call it a day?
On top of that, a robust, maintainable implementation of this thing seems very complicated — for example, what happens if vfree() gets called?
^ permalink raw reply
* Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
From: James Bottomley @ 2019-04-26 14:57 UTC (permalink / raw)
To: Dave Hansen, Mike Rapoport, linux-kernel
Cc: Alexandre Chartre, Andy Lutomirski, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Ingo Molnar, Jonathan Adams, Kees Cook,
Paul Turner, Peter Zijlstra, Thomas Gleixner, linux-mm,
linux-security-module, x86
In-Reply-To: <627d9321-466f-c4ed-c658-6b8567648dc6@intel.com>
On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote:
> On 4/25/19 2:45 PM, Mike Rapoport wrote:
> > After the isolated system call finishes, the mappings created
> > during its execution are cleared.
>
> Yikes. I guess that stops someone from calling write() a bunch of
> times on every filesystem using every block device driver and all the
> DM code to get a lot of code/data faulted in. But, it also means not
> even long-running processes will ever have a chance of behaving
> anything close to normally.
>
> Is this something you think can be rectified or is there something
> fundamental that would keep SCI page tables from being cached across
> different invocations of the same syscall?
There is some work being done to look at pre-populating the isolated
address space with the expected execution footprint of the system call,
yes. It lessens the ROP gadget protection slightly because you might
find a gadget in the pre-populated code, but it solves a lot of the
overhead problem.
James
^ permalink raw reply
* Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
From: Dave Hansen @ 2019-04-26 14:46 UTC (permalink / raw)
To: Mike Rapoport, linux-kernel
Cc: Alexandre Chartre, Andy Lutomirski, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Ingo Molnar, James Bottomley, Jonathan Adams,
Kees Cook, Paul Turner, Peter Zijlstra, Thomas Gleixner, linux-mm,
linux-security-module, x86
In-Reply-To: <1556228754-12996-3-git-send-email-rppt@linux.ibm.com>
On 4/25/19 2:45 PM, Mike Rapoport wrote:
> After the isolated system call finishes, the mappings created during its
> execution are cleared.
Yikes. I guess that stops someone from calling write() a bunch of times
on every filesystem using every block device driver and all the DM code
to get a lot of code/data faulted in. But, it also means not even
long-running processes will ever have a chance of behaving anything
close to normally.
Is this something you think can be rectified or is there something
fundamental that would keep SCI page tables from being cached across
different invocations of the same syscall?
^ permalink raw reply
* Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
From: James Bottomley @ 2019-04-26 14:44 UTC (permalink / raw)
To: Ingo Molnar, Mike Rapoport
Cc: linux-kernel, Alexandre Chartre, Andy Lutomirski, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Ingo Molnar, Jonathan Adams,
Kees Cook, Paul Turner, Peter Zijlstra, Thomas Gleixner, linux-mm,
linux-security-module, x86, Linus Torvalds, Peter Zijlstra,
Andrew Morton
In-Reply-To: <20190426083144.GA126896@gmail.com>
On Fri, 2019-04-26 at 10:31 +0200, Ingo Molnar wrote:
> * Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> > When enabled, the system call isolation (SCI) would allow execution
> > of the system calls with reduced page tables. These page tables are
> > almost identical to the user page tables in PTI. The only addition
> > is the code page containing system call entry function that will
> > continue exectution after the context switch.
> >
> > Unlike PTI page tables, there is no sharing at higher levels and
> > all the hierarchy for SCI page tables is cloned.
> >
> > The SCI page tables are created when a system call that requires
> > isolation is executed for the first time.
> >
> > Whenever a system call should be executed in the isolated
> > environment, the context is switched to the SCI page tables. Any
> > further access to the kernel memory will generate a page fault. The
> > page fault handler can verify that the access is safe and grant it
> > or kill the task otherwise.
> >
> > The initial SCI implementation allows access to any kernel data,
> > but it limits access to the code in the following way:
> > * calls and jumps to known code symbols without offset are allowed
> > * calls and jumps into a known symbol with offset are allowed only
> > if that symbol was already accessed and the offset is in the next
> > page
> > * all other code access are blocked
> >
> > After the isolated system call finishes, the mappings created
> > during its execution are cleared.
> >
> > The entire SCI page table is lazily freed at task exit() time.
>
> So this basically uses a similar mechanism to the horrendous PTI CR3
> switching overhead whenever a syscall seeks "protection", which
> overhead is only somewhat mitigated by PCID.
>
> This might work on PTI-encumbered CPUs.
>
> While AMD CPUs don't need PTI, nor do they have PCID.
>
> So this feature is hurting the CPU maker who didn't mess up, and is
> hurting future CPUs that don't need PTI ..
>
> I really don't like it where this is going. In a couple of years I
> really want to be able to think of PTI as a bad dream that is mostly
> over fortunately.
Perhaps ROP gadgets were a bad first example. The research object of
the current patch set is really to investigate eliminating sandboxing
for containers. As you know, current sandboxes like gVisor and Nabla
try to reduce the exposure to horizontal exploits (ability of an
untrusted tenant to exploit the shared kernel to attack another tenant)
by running significant chunks of kernel emulation code in userspace to
reduce exposure of the tenant to code in the shared kernel. The price
paid for this is pretty horrendous in performance terms, but the
benefit is multi-tenant safety.
The question we were looking into is if we used per-tenant in-kernel
address space isolation to improve the security of kernel system calls
such that either the exploit becomes detectable or its consequences
bounce back only on the tenant trying the exploit, we could eliminate
the emulation for that system call and instead pass it through to the
kernel, thus thinning out the sandbox layer without losing the security
benefits.
We are looking at other aspects as well, like can we simply run chunks
of the kernel in the user's address space as the sanbox emulation
currently does, or can we hide a tenant's data objects such that
they're not easily accessible from an exploited kernel.
James
^ permalink raw reply
* Re: [RFC PATCH 0/7] x86: introduce system calls addess space isolation
From: Dave Hansen @ 2019-04-26 14:41 UTC (permalink / raw)
To: Mike Rapoport, linux-kernel
Cc: Alexandre Chartre, Andy Lutomirski, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Ingo Molnar, James Bottomley, Jonathan Adams,
Kees Cook, Paul Turner, Peter Zijlstra, Thomas Gleixner, linux-mm,
linux-security-module, x86
In-Reply-To: <1556228754-12996-1-git-send-email-rppt@linux.ibm.com>
On 4/25/19 2:45 PM, Mike Rapoport wrote:
> The idea behind the prevention is that if we fault in pages in the
> execution path, we can compare target address against the kernel symbol
> table. So if we're in a function, we allow local jumps (and simply falling
> of the end of a page) but if we're jumping to a new function it must be to
> an external label in the symbol table. Since ROP attacks are all about
> jumping to gadget code which is effectively in the middle of real
> functions, the jumps they induce are to code that doesn't have an external
> symbol, so it should mostly detect when they happen.
This turns the problem from: "attackers can leverage any data/code that
the kernel has mapped (anything)" to "attackers can leverage any
code/data that the current syscall has faulted in".
That seems like a pretty restrictive change.
> At this time we are not suggesting any API that will enable the system
> calls isolation. Because of the overhead required for this, it should only
> be activated for processes or containers we know should be untrusted. We
> still have no actual numbers, but surely forcing page faults during system
> call execution will not come for free.
What's the minimum number of faults that have to occur to handle the
simplest dummy fault?
^ permalink raw reply
* Re: [PATCH 1/3] mm: security: introduce the init_allocations=1 boot option
From: Christopher Lameter @ 2019-04-26 14:14 UTC (permalink / raw)
To: Alexander Potapenko
Cc: akpm, dvyukov, keescook, labbott, linux-mm, linux-security-module,
kernel-hardening
In-Reply-To: <20190418154208.131118-2-glider@google.com>
On Thu, 18 Apr 2019, Alexander Potapenko wrote:
> This option adds the possibility to initialize newly allocated pages and
> heap objects with zeroes. This is needed to prevent possible information
> leaks and make the control-flow bugs that depend on uninitialized values
> more deterministic.
>
> Initialization is done at allocation time at the places where checks for
> __GFP_ZERO are performed. We don't initialize slab caches with
> constructors to preserve their semantics. To reduce runtime costs of
> checking cachep->ctor we replace a call to memset with a call to
> cachep->poison_fn, which is only executed if the memory block needs to
> be initialized.
Just check for a ctor and then zero or use whatever pattern ? Why add a
new function?
^ permalink raw reply
* Re: [PATCH 0/3] RFC: add init_allocations=1 boot option
From: Alexander Potapenko @ 2019-04-26 12:39 UTC (permalink / raw)
To: Kees Cook
Cc: Andrew Morton, Christoph Lameter, Dmitry Vyukov, Laura Abbott,
Linux-MM, linux-security-module, Kernel Hardening
In-Reply-To: <CAGXu5j+tJJbyoZ=nSpSeiihD=NHwFJ6G9Ku5c21G5nQfEiKPwQ@mail.gmail.com>
On Tue, Apr 23, 2019 at 8:49 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Thu, Apr 18, 2019 at 8:42 AM Alexander Potapenko <glider@google.com> wrote:
> >
> > Following the recent discussions here's another take at initializing
> > pages and heap objects with zeroes. This is needed to prevent possible
> > information leaks and make the control-flow bugs that depend on
> > uninitialized values more deterministic.
> >
> > The patchset introduces a new boot option, init_allocations, which
> > makes page allocator and SL[AOU]B initialize newly allocated memory.
> > init_allocations=0 doesn't (hopefully) add any overhead to the
> > allocation fast path (no noticeable slowdown on hackbench).
>
> I continue to prefer to have a way to both at-allocation
> initialization _and_ poison-on-free, so let's not redirect this to
> doing it only at free time.
There's a problem with poison-on-free.
By default SLUB stores the freelist pointer (not sure if it's the only
piece of data) in the memory chunk itself, so newly allocated memory
is dirty despite it has been zeroed out previously.
We could probably zero out the bits used by the allocator when
allocating the memory chunk, but it sounds hacky (yet saves us 8 bytes
on every allocation)
A cleaner solution would be to unconditionally relocate the free
pointer by short-circuiting
https://elixir.bootlin.com/linux/latest/source/mm/slub.c#L3531
Surprisingly, this doesn't work, because now the sizes of slub caches
are a bit off, and create_unique_id() in slub.c returns clashing sysfs
names.
> We're going to need both hooks when doing
> Memory Tagging, so let's just get it in place now. The security
> benefits on tagging, IMO, easily justify a 1-2% performance hit. And
> likely we'll see this improve with new hardware.
>
> > With only the the first of the proposed patches the slowdown numbers are:
> > - 1.1% (stdev 0.2%) sys time slowdown building Linux kernel
> > - 3.1% (stdev 0.3%) sys time slowdown on af_inet_loopback benchmark
> > - 9.4% (stdev 0.5%) sys time slowdown on hackbench
> >
> > The second patch introduces a GFP flag that allows to disable
> > initialization for certain allocations. The third page is an example of
> > applying it to af_unix.c, which helps hackbench greatly.
> >
> > Slowdown numbers for the whole patchset are:
> > - 1.8% (stdev 0.8%) on kernel build
> > - 6.5% (stdev 0.2%) on af_inet_loopback
>
> Any idea why thes two went _up_?
>
> > - 0.12% (stdev 0.6%) on hackbench
>
> Well that's quite an improvement. :)
>
> --
> Kees Cook
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox