* [PATCH v2 0/3] x86/asm: More pinning
@ 2019-02-27 20:01 Kees Cook
2019-02-27 20:01 ` [PATCH v2 1/3] x86/asm: Pin sensitive CR0 bits Kees Cook
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Kees Cook @ 2019-02-27 20:01 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kees Cook, Peter Zijlstra, Solar Designer, Greg KH, Jann Horn,
Sean Christopherson, Dominik Brodowski, linux-kernel,
Kernel Hardening
This adds CR0 pinning (for WP), and cleans up the CR4 pin to avoid
taking an exception from WARN before fixing up the desired pin.
Additionally adds lkdtm test (which depends on the CR4 patch, otherwise
I'd send it via Greg's tree).
v2:
- include brown-paper-bag fix to lkdtm test in v1
- clean up comments
Thanks!
-Kees
Kees Cook (3):
x86/asm: Pin sensitive CR0 bits
x86/asm: Avoid taking an exception before cr4 restore
lkdtm: Check for SMEP clearing protections
arch/x86/include/asm/special_insns.h | 37 ++++++++++++++---
drivers/misc/lkdtm/bugs.c | 61 ++++++++++++++++++++++++++++
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h | 1 +
4 files changed, 95 insertions(+), 5 deletions(-)
--
2.17.1
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2 1/3] x86/asm: Pin sensitive CR0 bits
2019-02-27 20:01 [PATCH v2 0/3] x86/asm: More pinning Kees Cook
@ 2019-02-27 20:01 ` Kees Cook
2019-03-06 9:55 ` [tip:x86/asm] " tip-bot for Kees Cook
2019-03-06 13:31 ` tip-bot for Kees Cook
2019-02-27 20:01 ` [PATCH v2 2/3] x86/asm: Avoid taking an exception before cr4 restore Kees Cook
2019-02-27 20:01 ` [PATCH v2 3/3] lkdtm: Check for SMEP clearing protections Kees Cook
2 siblings, 2 replies; 11+ messages in thread
From: Kees Cook @ 2019-02-27 20:01 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kees Cook, Peter Zijlstra, Solar Designer, Greg KH, Jann Horn,
Sean Christopherson, Dominik Brodowski, linux-kernel,
Kernel Hardening
With sensitive CR4 bits pinned now, it's possible that the WP bit for CR0
might become a target as well. Following the same reasoning for the CR4
pinning, this pins CR0's WP bit (but this can be done with a static value).
As before, to convince the compiler to not optimize away the check for the
WP bit after the set, this marks "val" as an output from the asm() block.
This protects against just jumping into the function past where the masking
happens; we must check that the mask was applied after we do the set). Due
to how this function can be built by the compiler (especially due to the
removal of frame pointers), jumping into the middle of the function
frequently doesn't require stack manipulation to construct a stack frame
(there may only a retq without pops, which is sufficient for use with
exploits like timer overwrites).
Additionally, this avoids WARN()ing before resetting the bit, just to
minimize any race conditions with leaving the bit unset.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
arch/x86/include/asm/special_insns.h | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
index fabda1400137..1f01dc3f6c64 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -25,7 +25,28 @@ static inline unsigned long native_read_cr0(void)
static inline void native_write_cr0(unsigned long val)
{
- asm volatile("mov %0,%%cr0": : "r" (val), "m" (__force_order));
+ bool warn = false;
+
+again:
+ val |= X86_CR0_WP;
+ /*
+ * In order to have the compiler not optimize away the check
+ * after the cr4 write, mark "val" as being also an output ("+r")
+ * by this asm() block so it will perform an explicit check, as
+ * if it were "volatile".
+ */
+ asm volatile("mov %0,%%cr0" : "+r" (val) : "m" (__force_order) : );
+ /*
+ * If the MOV above was used directly as a ROP gadget we can
+ * notice the lack of pinned bits in "val" and start the function
+ * from the beginning to gain the WP bit for sure. And do it
+ * without first taking the exception for a WARN().
+ */
+ if ((val & X86_CR0_WP) != X86_CR0_WP) {
+ warn = true;
+ goto again;
+ }
+ WARN_ONCE(warn, "Attempt to unpin X86_CR0_WP, cr0 bypass attack?!\n");
}
static inline unsigned long native_read_cr2(void)
--
2.17.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v2 2/3] x86/asm: Avoid taking an exception before cr4 restore
2019-02-27 20:01 [PATCH v2 0/3] x86/asm: More pinning Kees Cook
2019-02-27 20:01 ` [PATCH v2 1/3] x86/asm: Pin sensitive CR0 bits Kees Cook
@ 2019-02-27 20:01 ` Kees Cook
2019-03-06 9:55 ` [tip:x86/asm] " tip-bot for Kees Cook
2019-03-06 13:31 ` tip-bot for Kees Cook
2019-02-27 20:01 ` [PATCH v2 3/3] lkdtm: Check for SMEP clearing protections Kees Cook
2 siblings, 2 replies; 11+ messages in thread
From: Kees Cook @ 2019-02-27 20:01 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kees Cook, Peter Zijlstra, Solar Designer, Greg KH, Jann Horn,
Sean Christopherson, Dominik Brodowski, linux-kernel,
Kernel Hardening
Instead of taking a full WARN() exception before restoring a potentially
missed CR4 bit, this retains the missing bit for later reporting. This
matches the logic done for the CR0 pinning. Additionally updates the
comments to note the required use of "volatile".
Suggested-by: Solar Designer <solar@openwall.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
arch/x86/include/asm/special_insns.h | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
index 1f01dc3f6c64..6020cb1de66e 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -97,18 +97,24 @@ extern volatile unsigned long cr4_pin;
static inline void native_write_cr4(unsigned long val)
{
+ unsigned long warn = 0;
+
again:
val |= cr4_pin;
asm volatile("mov %0,%%cr4": : "r" (val), "m" (__force_order));
/*
* If the MOV above was used directly as a ROP gadget we can
* notice the lack of pinned bits in "val" and start the function
- * from the beginning to gain the cr4_pin bits for sure.
+ * from the beginning to gain the cr4_pin bits for sure. Note
+ * that "val" must be volatile to keep the compiler from
+ * optimizing away this check.
*/
- if (WARN_ONCE((val & cr4_pin) != cr4_pin,
- "Attempt to unpin cr4 bits: %lx, cr4 bypass attack?!",
- ~val & cr4_pin))
+ if ((val & cr4_pin) != cr4_pin) {
+ warn = ~val & cr4_pin;
goto again;
+ }
+ WARN_ONCE(warn, "Attempt to unpin cr4 bits: %lx; bypass attack?!\n",
+ warn);
}
#ifdef CONFIG_X86_64
--
2.17.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v2 3/3] lkdtm: Check for SMEP clearing protections
2019-02-27 20:01 [PATCH v2 0/3] x86/asm: More pinning Kees Cook
2019-02-27 20:01 ` [PATCH v2 1/3] x86/asm: Pin sensitive CR0 bits Kees Cook
2019-02-27 20:01 ` [PATCH v2 2/3] x86/asm: Avoid taking an exception before cr4 restore Kees Cook
@ 2019-02-27 20:01 ` Kees Cook
2019-03-06 9:56 ` [tip:x86/asm] " tip-bot for Kees Cook
2019-03-06 13:32 ` tip-bot for Kees Cook
2 siblings, 2 replies; 11+ messages in thread
From: Kees Cook @ 2019-02-27 20:01 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kees Cook, Peter Zijlstra, Solar Designer, Greg KH, Jann Horn,
Sean Christopherson, Dominik Brodowski, linux-kernel,
Kernel Hardening
This adds an x86-specific test for pinned cr4 bits. A successful test
will validate pinning and check the ROP-style call-middle-of-function
defense, if needed. For example, in the case of native_write_cr4()
looking like this:
ffffffff8171bce0 <native_write_cr4>:
ffffffff8171bce0: 48 8b 35 79 46 f2 00 mov 0xf24679(%rip),%rsi
ffffffff8171bce7: 48 09 f7 or %rsi,%rdi
ffffffff8171bcea: 0f 22 e7 mov %rdi,%cr4
...
ffffffff8171bd5a: c3 retq
The UNSET_SMEP test will jump to ffffffff8171bcea (the mov to cr4)
instead of ffffffff8171bce0 (native_write_cr4() entry) to simulate a
direct-call bypass attempt.
Expected successful results:
# echo UNSET_SMEP > /sys/kernel/debug/provoke-crash/DIRECT
# dmesg
[ 79.594433] lkdtm: Performing direct entry UNSET_SMEP
[ 79.596459] lkdtm: trying to clear SMEP normally
[ 79.598406] lkdtm: ok: SMEP did not get cleared
[ 79.599981] lkdtm: trying to clear SMEP with call gadget
[ 79.601810] ------------[ cut here ]------------
[ 79.603421] Attempt to unpin cr4 bits: 100000; bypass attack?!
...
[ 79.650170] ---[ end trace 2452ca0f6126242e ]---
[ 79.650937] lkdtm: ok: SMEP removal was reverted
Signed-off-by: Kees Cook <keescook@chromium.org>
---
drivers/misc/lkdtm/bugs.c | 61 ++++++++++++++++++++++++++++++++++++++
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h | 1 +
3 files changed, 63 insertions(+)
diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c
index 7eebbdfbcacd..6176384b4f85 100644
--- a/drivers/misc/lkdtm/bugs.c
+++ b/drivers/misc/lkdtm/bugs.c
@@ -255,3 +255,64 @@ void lkdtm_STACK_GUARD_PAGE_TRAILING(void)
pr_err("FAIL: accessed page after stack!\n");
}
+
+void lkdtm_UNSET_SMEP(void)
+{
+#ifdef CONFIG_X86_64
+#define MOV_CR4_DEPTH 64
+ void (*direct_write_cr4)(unsigned long val);
+ unsigned char *insn;
+ unsigned long cr4;
+ int i;
+
+ cr4 = native_read_cr4();
+
+ if ((cr4 & X86_CR4_SMEP) != X86_CR4_SMEP) {
+ pr_err("FAIL: SMEP not in use\n");
+ return;
+ }
+ cr4 &= ~(X86_CR4_SMEP);
+
+ pr_info("trying to clear SMEP normally\n");
+ native_write_cr4(cr4);
+ if (cr4 == native_read_cr4()) {
+ pr_err("FAIL: pinning SMEP failed!\n");
+ cr4 |= X86_CR4_SMEP;
+ pr_info("restoring SMEP\n");
+ native_write_cr4(cr4);
+ return;
+ }
+ pr_info("ok: SMEP did not get cleared\n");
+
+ /*
+ * To test the post-write pinning verification we need to call
+ * directly into the the middle of native_write_cr4() where the
+ * cr4 write happens, skipping the pinning. This searches for
+ * the cr4 writing instruction.
+ */
+ insn = (unsigned char *)native_write_cr4;
+ for (i = 0; i < MOV_CR4_DEPTH; i++) {
+ /* mov %rdi, %cr4 */
+ if (insn[i] == 0x0f && insn[i+1] == 0x22 && insn[i+2] == 0xe7)
+ break;
+ }
+ if (i >= MOV_CR4_DEPTH) {
+ pr_info("ok: cannot locate cr4 writing call gadget\n");
+ return;
+ }
+ direct_write_cr4 = (void *)(insn + i);
+
+ pr_info("trying to clear SMEP with call gadget\n");
+ direct_write_cr4(cr4);
+ if (native_read_cr4() & X86_CR4_SMEP) {
+ pr_info("ok: SMEP removal was reverted\n");
+ } else {
+ pr_err("FAIL: cleared SMEP not detected!\n");
+ cr4 |= X86_CR4_SMEP;
+ pr_info("restoring SMEP\n");
+ native_write_cr4(cr4);
+ }
+#else
+ pr_err("FAIL: this test is x86_64-only\n");
+#endif
+}
diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
index 2837dc77478e..fd668776414b 100644
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@ -132,6 +132,7 @@ static const struct crashtype crashtypes[] = {
CRASHTYPE(CORRUPT_LIST_ADD),
CRASHTYPE(CORRUPT_LIST_DEL),
CRASHTYPE(CORRUPT_USER_DS),
+ CRASHTYPE(UNSET_SMEP),
CRASHTYPE(CORRUPT_STACK),
CRASHTYPE(CORRUPT_STACK_STRONG),
CRASHTYPE(STACK_GUARD_PAGE_LEADING),
diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h
index 3c6fd327e166..9c78d7e21c13 100644
--- a/drivers/misc/lkdtm/lkdtm.h
+++ b/drivers/misc/lkdtm/lkdtm.h
@@ -26,6 +26,7 @@ void lkdtm_CORRUPT_LIST_DEL(void);
void lkdtm_CORRUPT_USER_DS(void);
void lkdtm_STACK_GUARD_PAGE_LEADING(void);
void lkdtm_STACK_GUARD_PAGE_TRAILING(void);
+void lkdtm_UNSET_SMEP(void);
/* lkdtm_heap.c */
void lkdtm_OVERWRITE_ALLOCATION(void);
--
2.17.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [tip:x86/asm] x86/asm: Pin sensitive CR0 bits
2019-02-27 20:01 ` [PATCH v2 1/3] x86/asm: Pin sensitive CR0 bits Kees Cook
@ 2019-03-06 9:55 ` tip-bot for Kees Cook
2019-03-06 13:31 ` tip-bot for Kees Cook
1 sibling, 0 replies; 11+ messages in thread
From: tip-bot for Kees Cook @ 2019-03-06 9:55 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux, gregkh, jannh, hpa, tglx, sean.j.christopherson,
linux-kernel, peterz, keescook, kernel-hardening, mingo, solar
Commit-ID: d309ba034fac1a149d00cac79318973e9ba81848
Gitweb: https://git.kernel.org/tip/d309ba034fac1a149d00cac79318973e9ba81848
Author: Kees Cook <keescook@chromium.org>
AuthorDate: Wed, 27 Feb 2019 12:01:30 -0800
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 6 Mar 2019 10:49:50 +0100
x86/asm: Pin sensitive CR0 bits
With sensitive CR4 bits pinned now, it's possible that the WP bit for CR0
might become a target as well. Following the same reasoning for the CR4
pinning, this pins CR0's WP bit (but this can be done with a static value).
As before, to convince the compiler to not optimize away the check for the
WP bit after the set, this marks "val" as an output from the asm() block.
This protects against just jumping into the function past where the masking
happens; we must check that the mask was applied after we do the set). Due
to how this function can be built by the compiler (especially due to the
removal of frame pointers), jumping into the middle of the function
frequently doesn't require stack manipulation to construct a stack frame
(there may only a retq without pops, which is sufficient for use with
exploits like timer overwrites).
Additionally, this avoids WARN()ing before resetting the bit, just to
minimize any race conditions with leaving the bit unset.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Solar Designer <solar@openwall.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Jann Horn <jannh@google.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>
Link: https://lkml.kernel.org/r/20190227200132.24707-2-keescook@chromium.org
---
arch/x86/include/asm/special_insns.h | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
index fabda1400137..1f01dc3f6c64 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -25,7 +25,28 @@ static inline unsigned long native_read_cr0(void)
static inline void native_write_cr0(unsigned long val)
{
- asm volatile("mov %0,%%cr0": : "r" (val), "m" (__force_order));
+ bool warn = false;
+
+again:
+ val |= X86_CR0_WP;
+ /*
+ * In order to have the compiler not optimize away the check
+ * after the cr4 write, mark "val" as being also an output ("+r")
+ * by this asm() block so it will perform an explicit check, as
+ * if it were "volatile".
+ */
+ asm volatile("mov %0,%%cr0" : "+r" (val) : "m" (__force_order) : );
+ /*
+ * If the MOV above was used directly as a ROP gadget we can
+ * notice the lack of pinned bits in "val" and start the function
+ * from the beginning to gain the WP bit for sure. And do it
+ * without first taking the exception for a WARN().
+ */
+ if ((val & X86_CR0_WP) != X86_CR0_WP) {
+ warn = true;
+ goto again;
+ }
+ WARN_ONCE(warn, "Attempt to unpin X86_CR0_WP, cr0 bypass attack?!\n");
}
static inline unsigned long native_read_cr2(void)
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [tip:x86/asm] x86/asm: Avoid taking an exception before cr4 restore
2019-02-27 20:01 ` [PATCH v2 2/3] x86/asm: Avoid taking an exception before cr4 restore Kees Cook
@ 2019-03-06 9:55 ` tip-bot for Kees Cook
2019-03-06 13:31 ` tip-bot for Kees Cook
1 sibling, 0 replies; 11+ messages in thread
From: tip-bot for Kees Cook @ 2019-03-06 9:55 UTC (permalink / raw)
To: linux-tip-commits
Cc: solar, jannh, mingo, kernel-hardening, keescook, linux, tglx,
peterz, gregkh, sean.j.christopherson, hpa, linux-kernel
Commit-ID: 1201dc68361cdb83ba314bef565b89400a68f5a5
Gitweb: https://git.kernel.org/tip/1201dc68361cdb83ba314bef565b89400a68f5a5
Author: Kees Cook <keescook@chromium.org>
AuthorDate: Wed, 27 Feb 2019 12:01:31 -0800
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 6 Mar 2019 10:49:50 +0100
x86/asm: Avoid taking an exception before cr4 restore
Instead of taking a full WARN() exception before restoring a potentially
missed CR4 bit, this retains the missing bit for later reporting. This
matches the logic done for the CR0 pinning. Additionally updates the
comments to note the required use of "volatile".
Suggested-by: Solar Designer <solar@openwall.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Jann Horn <jannh@google.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>
Link: https://lkml.kernel.org/r/20190227200132.24707-3-keescook@chromium.org
---
arch/x86/include/asm/special_insns.h | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
index 1f01dc3f6c64..6020cb1de66e 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -97,18 +97,24 @@ extern volatile unsigned long cr4_pin;
static inline void native_write_cr4(unsigned long val)
{
+ unsigned long warn = 0;
+
again:
val |= cr4_pin;
asm volatile("mov %0,%%cr4": : "r" (val), "m" (__force_order));
/*
* If the MOV above was used directly as a ROP gadget we can
* notice the lack of pinned bits in "val" and start the function
- * from the beginning to gain the cr4_pin bits for sure.
+ * from the beginning to gain the cr4_pin bits for sure. Note
+ * that "val" must be volatile to keep the compiler from
+ * optimizing away this check.
*/
- if (WARN_ONCE((val & cr4_pin) != cr4_pin,
- "Attempt to unpin cr4 bits: %lx, cr4 bypass attack?!",
- ~val & cr4_pin))
+ if ((val & cr4_pin) != cr4_pin) {
+ warn = ~val & cr4_pin;
goto again;
+ }
+ WARN_ONCE(warn, "Attempt to unpin cr4 bits: %lx; bypass attack?!\n",
+ warn);
}
#ifdef CONFIG_X86_64
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [tip:x86/asm] lkdtm: Check for SMEP clearing protections
2019-02-27 20:01 ` [PATCH v2 3/3] lkdtm: Check for SMEP clearing protections Kees Cook
@ 2019-03-06 9:56 ` tip-bot for Kees Cook
2019-03-06 13:32 ` tip-bot for Kees Cook
1 sibling, 0 replies; 11+ messages in thread
From: tip-bot for Kees Cook @ 2019-03-06 9:56 UTC (permalink / raw)
To: linux-tip-commits
Cc: mingo, linux, gregkh, sean.j.christopherson, kernel-hardening,
solar, jannh, linux-kernel, tglx, peterz, hpa, keescook
Commit-ID: a0bf7fc24303a538396aa8d32450d05c1929b9f0
Gitweb: https://git.kernel.org/tip/a0bf7fc24303a538396aa8d32450d05c1929b9f0
Author: Kees Cook <keescook@chromium.org>
AuthorDate: Wed, 27 Feb 2019 12:01:32 -0800
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 6 Mar 2019 10:49:50 +0100
lkdtm: Check for SMEP clearing protections
This adds an x86-specific test for pinned cr4 bits. A successful test
will validate pinning and check the ROP-style call-middle-of-function
defense, if needed. For example, in the case of native_write_cr4()
looking like this:
ffffffff8171bce0 <native_write_cr4>:
ffffffff8171bce0: 48 8b 35 79 46 f2 00 mov 0xf24679(%rip),%rsi
ffffffff8171bce7: 48 09 f7 or %rsi,%rdi
ffffffff8171bcea: 0f 22 e7 mov %rdi,%cr4
...
ffffffff8171bd5a: c3 retq
The UNSET_SMEP test will jump to ffffffff8171bcea (the mov to cr4)
instead of ffffffff8171bce0 (native_write_cr4() entry) to simulate a
direct-call bypass attempt.
Expected successful results:
# echo UNSET_SMEP > /sys/kernel/debug/provoke-crash/DIRECT
# dmesg
[ 79.594433] lkdtm: Performing direct entry UNSET_SMEP
[ 79.596459] lkdtm: trying to clear SMEP normally
[ 79.598406] lkdtm: ok: SMEP did not get cleared
[ 79.599981] lkdtm: trying to clear SMEP with call gadget
[ 79.601810] ------------[ cut here ]------------
[ 79.603421] Attempt to unpin cr4 bits: 100000; bypass attack?!
...
[ 79.650170] ---[ end trace 2452ca0f6126242e ]---
[ 79.650937] lkdtm: ok: SMEP removal was reverted
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Solar Designer <solar@openwall.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Jann Horn <jannh@google.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>
Link: https://lkml.kernel.org/r/20190227200132.24707-4-keescook@chromium.org
---
drivers/misc/lkdtm/bugs.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h | 1 +
3 files changed, 63 insertions(+)
diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c
index 7eebbdfbcacd..6176384b4f85 100644
--- a/drivers/misc/lkdtm/bugs.c
+++ b/drivers/misc/lkdtm/bugs.c
@@ -255,3 +255,64 @@ void lkdtm_STACK_GUARD_PAGE_TRAILING(void)
pr_err("FAIL: accessed page after stack!\n");
}
+
+void lkdtm_UNSET_SMEP(void)
+{
+#ifdef CONFIG_X86_64
+#define MOV_CR4_DEPTH 64
+ void (*direct_write_cr4)(unsigned long val);
+ unsigned char *insn;
+ unsigned long cr4;
+ int i;
+
+ cr4 = native_read_cr4();
+
+ if ((cr4 & X86_CR4_SMEP) != X86_CR4_SMEP) {
+ pr_err("FAIL: SMEP not in use\n");
+ return;
+ }
+ cr4 &= ~(X86_CR4_SMEP);
+
+ pr_info("trying to clear SMEP normally\n");
+ native_write_cr4(cr4);
+ if (cr4 == native_read_cr4()) {
+ pr_err("FAIL: pinning SMEP failed!\n");
+ cr4 |= X86_CR4_SMEP;
+ pr_info("restoring SMEP\n");
+ native_write_cr4(cr4);
+ return;
+ }
+ pr_info("ok: SMEP did not get cleared\n");
+
+ /*
+ * To test the post-write pinning verification we need to call
+ * directly into the the middle of native_write_cr4() where the
+ * cr4 write happens, skipping the pinning. This searches for
+ * the cr4 writing instruction.
+ */
+ insn = (unsigned char *)native_write_cr4;
+ for (i = 0; i < MOV_CR4_DEPTH; i++) {
+ /* mov %rdi, %cr4 */
+ if (insn[i] == 0x0f && insn[i+1] == 0x22 && insn[i+2] == 0xe7)
+ break;
+ }
+ if (i >= MOV_CR4_DEPTH) {
+ pr_info("ok: cannot locate cr4 writing call gadget\n");
+ return;
+ }
+ direct_write_cr4 = (void *)(insn + i);
+
+ pr_info("trying to clear SMEP with call gadget\n");
+ direct_write_cr4(cr4);
+ if (native_read_cr4() & X86_CR4_SMEP) {
+ pr_info("ok: SMEP removal was reverted\n");
+ } else {
+ pr_err("FAIL: cleared SMEP not detected!\n");
+ cr4 |= X86_CR4_SMEP;
+ pr_info("restoring SMEP\n");
+ native_write_cr4(cr4);
+ }
+#else
+ pr_err("FAIL: this test is x86_64-only\n");
+#endif
+}
diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
index 2837dc77478e..fd668776414b 100644
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@ -132,6 +132,7 @@ static const struct crashtype crashtypes[] = {
CRASHTYPE(CORRUPT_LIST_ADD),
CRASHTYPE(CORRUPT_LIST_DEL),
CRASHTYPE(CORRUPT_USER_DS),
+ CRASHTYPE(UNSET_SMEP),
CRASHTYPE(CORRUPT_STACK),
CRASHTYPE(CORRUPT_STACK_STRONG),
CRASHTYPE(STACK_GUARD_PAGE_LEADING),
diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h
index 3c6fd327e166..9c78d7e21c13 100644
--- a/drivers/misc/lkdtm/lkdtm.h
+++ b/drivers/misc/lkdtm/lkdtm.h
@@ -26,6 +26,7 @@ void lkdtm_CORRUPT_LIST_DEL(void);
void lkdtm_CORRUPT_USER_DS(void);
void lkdtm_STACK_GUARD_PAGE_LEADING(void);
void lkdtm_STACK_GUARD_PAGE_TRAILING(void);
+void lkdtm_UNSET_SMEP(void);
/* lkdtm_heap.c */
void lkdtm_OVERWRITE_ALLOCATION(void);
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [tip:x86/asm] x86/asm: Avoid taking an exception before cr4 restore
2019-02-27 20:01 ` [PATCH v2 2/3] x86/asm: Avoid taking an exception before cr4 restore Kees Cook
2019-03-06 9:55 ` [tip:x86/asm] " tip-bot for Kees Cook
@ 2019-03-06 13:31 ` tip-bot for Kees Cook
1 sibling, 0 replies; 11+ messages in thread
From: tip-bot for Kees Cook @ 2019-03-06 13:31 UTC (permalink / raw)
To: linux-tip-commits
Cc: kernel-hardening, keescook, hpa, sean.j.christopherson, jannh,
solar, linux, mingo, tglx, linux-kernel, gregkh, peterz
Commit-ID: 3c8dbef26202a83207611b3d6f4d2db5e5cbbc0f
Gitweb: https://git.kernel.org/tip/3c8dbef26202a83207611b3d6f4d2db5e5cbbc0f
Author: Kees Cook <keescook@chromium.org>
AuthorDate: Wed, 27 Feb 2019 12:01:31 -0800
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 6 Mar 2019 13:25:55 +0100
x86/asm: Avoid taking an exception before cr4 restore
Instead of taking a full WARN() exception before restoring a potentially
missed CR4 bit, retain the missing bit for later reporting.
Additionally update the comments to note the required use of "volatile".
Suggested-by: Solar Designer <solar@openwall.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Jann Horn <jannh@google.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>
Link: https://lkml.kernel.org/r/20190227200132.24707-3-keescook@chromium.org
---
arch/x86/include/asm/special_insns.h | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
index fabda1400137..99607f142cad 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -76,18 +76,24 @@ extern volatile unsigned long cr4_pin;
static inline void native_write_cr4(unsigned long val)
{
+ unsigned long warn = 0;
+
again:
val |= cr4_pin;
asm volatile("mov %0,%%cr4": : "r" (val), "m" (__force_order));
/*
* If the MOV above was used directly as a ROP gadget we can
* notice the lack of pinned bits in "val" and start the function
- * from the beginning to gain the cr4_pin bits for sure.
+ * from the beginning to gain the cr4_pin bits for sure. Note
+ * that "val" must be volatile to keep the compiler from
+ * optimizing away this check.
*/
- if (WARN_ONCE((val & cr4_pin) != cr4_pin,
- "Attempt to unpin cr4 bits: %lx, cr4 bypass attack?!",
- ~val & cr4_pin))
+ if ((val & cr4_pin) != cr4_pin) {
+ warn = ~val & cr4_pin;
goto again;
+ }
+ WARN_ONCE(warn, "Attempt to unpin cr4 bits: %lx; bypass attack?!\n",
+ warn);
}
#ifdef CONFIG_X86_64
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [tip:x86/asm] x86/asm: Pin sensitive CR0 bits
2019-02-27 20:01 ` [PATCH v2 1/3] x86/asm: Pin sensitive CR0 bits Kees Cook
2019-03-06 9:55 ` [tip:x86/asm] " tip-bot for Kees Cook
@ 2019-03-06 13:31 ` tip-bot for Kees Cook
1 sibling, 0 replies; 11+ messages in thread
From: tip-bot for Kees Cook @ 2019-03-06 13:31 UTC (permalink / raw)
To: linux-tip-commits
Cc: solar, keescook, gregkh, linux, tglx, sean.j.christopherson, hpa,
mingo, peterz, linux-kernel, kernel-hardening, jannh
Commit-ID: d884bc119c4ebe7ac53b61fc0750bbc89b4d63db
Gitweb: https://git.kernel.org/tip/d884bc119c4ebe7ac53b61fc0750bbc89b4d63db
Author: Kees Cook <keescook@chromium.org>
AuthorDate: Wed, 27 Feb 2019 12:01:30 -0800
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 6 Mar 2019 13:25:55 +0100
x86/asm: Pin sensitive CR0 bits
With sensitive CR4 bits pinned now, it's possible that the WP bit for CR0
might become a target as well. Following the same reasoning for the CR4
pinning, pin CR0's WP bit (but this can be done with a static value).
As before, to convince the compiler to not optimize away the check for the
WP bit after the set, mark "val" as an output from the asm() block. This
protects against just jumping into the function past where the masking
happens; we must check that the mask was applied after we do the set). Due
to how this function can be built by the compiler (especially due to the
removal of frame pointers), jumping into the middle of the function
frequently doesn't require stack manipulation to construct a stack frame
(there may only a retq without pops, which is sufficient for use with
exploits like timer overwrites).
Additionally, this avoids WARN()ing before resetting the bit, just to
minimize any race conditions with leaving the bit unset.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Solar Designer <solar@openwall.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Jann Horn <jannh@google.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>
Link: https://lkml.kernel.org/r/20190227200132.24707-2-keescook@chromium.org
---
arch/x86/include/asm/special_insns.h | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
index 99607f142cad..7fa4fe880395 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -5,6 +5,7 @@
#ifdef __KERNEL__
+#include <asm/processor-flags.h>
#include <asm/nops.h>
/*
@@ -25,7 +26,28 @@ static inline unsigned long native_read_cr0(void)
static inline void native_write_cr0(unsigned long val)
{
- asm volatile("mov %0,%%cr0": : "r" (val), "m" (__force_order));
+ bool warn = false;
+
+again:
+ val |= X86_CR0_WP;
+ /*
+ * In order to have the compiler not optimize away the check
+ * after the cr4 write, mark "val" as being also an output ("+r")
+ * by this asm() block so it will perform an explicit check, as
+ * if it were "volatile".
+ */
+ asm volatile("mov %0,%%cr0" : "+r" (val) : "m" (__force_order) : );
+ /*
+ * If the MOV above was used directly as a ROP gadget we can
+ * notice the lack of pinned bits in "val" and start the function
+ * from the beginning to gain the WP bit for sure. And do it
+ * without first taking the exception for a WARN().
+ */
+ if ((val & X86_CR0_WP) != X86_CR0_WP) {
+ warn = true;
+ goto again;
+ }
+ WARN_ONCE(warn, "Attempt to unpin X86_CR0_WP, cr0 bypass attack?!\n");
}
static inline unsigned long native_read_cr2(void)
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [tip:x86/asm] lkdtm: Check for SMEP clearing protections
2019-02-27 20:01 ` [PATCH v2 3/3] lkdtm: Check for SMEP clearing protections Kees Cook
2019-03-06 9:56 ` [tip:x86/asm] " tip-bot for Kees Cook
@ 2019-03-06 13:32 ` tip-bot for Kees Cook
1 sibling, 0 replies; 11+ messages in thread
From: tip-bot for Kees Cook @ 2019-03-06 13:32 UTC (permalink / raw)
To: linux-tip-commits
Cc: solar, peterz, jannh, tglx, hpa, mingo, kernel-hardening,
sean.j.christopherson, linux, keescook, gregkh, linux-kernel
Commit-ID: 1e9b238bb4c1f22b5db77e9e17af0abd5578fa10
Gitweb: https://git.kernel.org/tip/1e9b238bb4c1f22b5db77e9e17af0abd5578fa10
Author: Kees Cook <keescook@chromium.org>
AuthorDate: Wed, 27 Feb 2019 12:01:32 -0800
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 6 Mar 2019 13:25:55 +0100
lkdtm: Check for SMEP clearing protections
This adds an x86-specific test for pinned cr4 bits. A successful test
will validate pinning and check the ROP-style call-middle-of-function
defense, if needed. For example, in the case of native_write_cr4()
looking like this:
ffffffff8171bce0 <native_write_cr4>:
ffffffff8171bce0: 48 8b 35 79 46 f2 00 mov 0xf24679(%rip),%rsi
ffffffff8171bce7: 48 09 f7 or %rsi,%rdi
ffffffff8171bcea: 0f 22 e7 mov %rdi,%cr4
...
ffffffff8171bd5a: c3 retq
The UNSET_SMEP test will jump to ffffffff8171bcea (the mov to cr4)
instead of ffffffff8171bce0 (native_write_cr4() entry) to simulate a
direct-call bypass attempt.
Expected successful results:
# echo UNSET_SMEP > /sys/kernel/debug/provoke-crash/DIRECT
# dmesg
[ 79.594433] lkdtm: Performing direct entry UNSET_SMEP
[ 79.596459] lkdtm: trying to clear SMEP normally
[ 79.598406] lkdtm: ok: SMEP did not get cleared
[ 79.599981] lkdtm: trying to clear SMEP with call gadget
[ 79.601810] ------------[ cut here ]------------
[ 79.603421] Attempt to unpin cr4 bits: 100000; bypass attack?!
...
[ 79.650170] ---[ end trace 2452ca0f6126242e ]---
[ 79.650937] lkdtm: ok: SMEP removal was reverted
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Solar Designer <solar@openwall.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Jann Horn <jannh@google.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>
Link: https://lkml.kernel.org/r/20190227200132.24707-4-keescook@chromium.org
---
drivers/misc/lkdtm/bugs.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h | 1 +
3 files changed, 63 insertions(+)
diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c
index 7eebbdfbcacd..6176384b4f85 100644
--- a/drivers/misc/lkdtm/bugs.c
+++ b/drivers/misc/lkdtm/bugs.c
@@ -255,3 +255,64 @@ void lkdtm_STACK_GUARD_PAGE_TRAILING(void)
pr_err("FAIL: accessed page after stack!\n");
}
+
+void lkdtm_UNSET_SMEP(void)
+{
+#ifdef CONFIG_X86_64
+#define MOV_CR4_DEPTH 64
+ void (*direct_write_cr4)(unsigned long val);
+ unsigned char *insn;
+ unsigned long cr4;
+ int i;
+
+ cr4 = native_read_cr4();
+
+ if ((cr4 & X86_CR4_SMEP) != X86_CR4_SMEP) {
+ pr_err("FAIL: SMEP not in use\n");
+ return;
+ }
+ cr4 &= ~(X86_CR4_SMEP);
+
+ pr_info("trying to clear SMEP normally\n");
+ native_write_cr4(cr4);
+ if (cr4 == native_read_cr4()) {
+ pr_err("FAIL: pinning SMEP failed!\n");
+ cr4 |= X86_CR4_SMEP;
+ pr_info("restoring SMEP\n");
+ native_write_cr4(cr4);
+ return;
+ }
+ pr_info("ok: SMEP did not get cleared\n");
+
+ /*
+ * To test the post-write pinning verification we need to call
+ * directly into the the middle of native_write_cr4() where the
+ * cr4 write happens, skipping the pinning. This searches for
+ * the cr4 writing instruction.
+ */
+ insn = (unsigned char *)native_write_cr4;
+ for (i = 0; i < MOV_CR4_DEPTH; i++) {
+ /* mov %rdi, %cr4 */
+ if (insn[i] == 0x0f && insn[i+1] == 0x22 && insn[i+2] == 0xe7)
+ break;
+ }
+ if (i >= MOV_CR4_DEPTH) {
+ pr_info("ok: cannot locate cr4 writing call gadget\n");
+ return;
+ }
+ direct_write_cr4 = (void *)(insn + i);
+
+ pr_info("trying to clear SMEP with call gadget\n");
+ direct_write_cr4(cr4);
+ if (native_read_cr4() & X86_CR4_SMEP) {
+ pr_info("ok: SMEP removal was reverted\n");
+ } else {
+ pr_err("FAIL: cleared SMEP not detected!\n");
+ cr4 |= X86_CR4_SMEP;
+ pr_info("restoring SMEP\n");
+ native_write_cr4(cr4);
+ }
+#else
+ pr_err("FAIL: this test is x86_64-only\n");
+#endif
+}
diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
index 2837dc77478e..fd668776414b 100644
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@ -132,6 +132,7 @@ static const struct crashtype crashtypes[] = {
CRASHTYPE(CORRUPT_LIST_ADD),
CRASHTYPE(CORRUPT_LIST_DEL),
CRASHTYPE(CORRUPT_USER_DS),
+ CRASHTYPE(UNSET_SMEP),
CRASHTYPE(CORRUPT_STACK),
CRASHTYPE(CORRUPT_STACK_STRONG),
CRASHTYPE(STACK_GUARD_PAGE_LEADING),
diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h
index 3c6fd327e166..9c78d7e21c13 100644
--- a/drivers/misc/lkdtm/lkdtm.h
+++ b/drivers/misc/lkdtm/lkdtm.h
@@ -26,6 +26,7 @@ void lkdtm_CORRUPT_LIST_DEL(void);
void lkdtm_CORRUPT_USER_DS(void);
void lkdtm_STACK_GUARD_PAGE_LEADING(void);
void lkdtm_STACK_GUARD_PAGE_TRAILING(void);
+void lkdtm_UNSET_SMEP(void);
/* lkdtm_heap.c */
void lkdtm_OVERWRITE_ALLOCATION(void);
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [tip:x86/asm] x86/asm: Pin sensitive CR0 bits
2019-06-18 4:55 [PATCH v3 3/3] x86/asm: Pin sensitive CR0 bits Kees Cook
@ 2019-06-22 9:58 ` tip-bot for Kees Cook
0 siblings, 0 replies; 11+ messages in thread
From: tip-bot for Kees Cook @ 2019-06-22 9:58 UTC (permalink / raw)
To: linux-tip-commits
Cc: keescook, dave.hansen, tglx, mingo, linux-kernel, hpa, peterz, torvalds
Commit-ID: 8dbec27a242cd3e2816eeb98d3237b9f57cf6232
Gitweb: https://git.kernel.org/tip/8dbec27a242cd3e2816eeb98d3237b9f57cf6232
Author: Kees Cook <keescook@chromium.org>
AuthorDate: Mon, 17 Jun 2019 21:55:03 -0700
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Sat, 22 Jun 2019 11:55:22 +0200
x86/asm: Pin sensitive CR0 bits
With sensitive CR4 bits pinned now, it's possible that the WP bit for
CR0 might become a target as well.
Following the same reasoning for the CR4 pinning, pin CR0's WP
bit. Contrary to the cpu feature dependend CR4 pinning this can be done
with a constant value.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: kernel-hardening@lists.openwall.com
Link: https://lkml.kernel.org/r/20190618045503.39105-4-keescook@chromium.org
---
arch/x86/include/asm/special_insns.h | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
index c8c8143ab27b..b2e84d113f2a 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -31,7 +31,20 @@ static inline unsigned long native_read_cr0(void)
static inline void native_write_cr0(unsigned long val)
{
- asm volatile("mov %0,%%cr0": : "r" (val), "m" (__force_order));
+ unsigned long bits_missing = 0;
+
+set_register:
+ asm volatile("mov %0,%%cr0": "+r" (val), "+m" (__force_order));
+
+ if (static_branch_likely(&cr_pinning)) {
+ if (unlikely((val & X86_CR0_WP) != X86_CR0_WP)) {
+ bits_missing = X86_CR0_WP;
+ val |= bits_missing;
+ goto set_register;
+ }
+ /* Warn after we've set the missing bits. */
+ WARN_ONCE(bits_missing, "CR0 WP bit went missing!?\n");
+ }
}
static inline unsigned long native_read_cr2(void)
^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-06-22 9:59 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-27 20:01 [PATCH v2 0/3] x86/asm: More pinning Kees Cook
2019-02-27 20:01 ` [PATCH v2 1/3] x86/asm: Pin sensitive CR0 bits Kees Cook
2019-03-06 9:55 ` [tip:x86/asm] " tip-bot for Kees Cook
2019-03-06 13:31 ` tip-bot for Kees Cook
2019-02-27 20:01 ` [PATCH v2 2/3] x86/asm: Avoid taking an exception before cr4 restore Kees Cook
2019-03-06 9:55 ` [tip:x86/asm] " tip-bot for Kees Cook
2019-03-06 13:31 ` tip-bot for Kees Cook
2019-02-27 20:01 ` [PATCH v2 3/3] lkdtm: Check for SMEP clearing protections Kees Cook
2019-03-06 9:56 ` [tip:x86/asm] " tip-bot for Kees Cook
2019-03-06 13:32 ` tip-bot for Kees Cook
2019-06-18 4:55 [PATCH v3 3/3] x86/asm: Pin sensitive CR0 bits Kees Cook
2019-06-22 9:58 ` [tip:x86/asm] " tip-bot for Kees Cook
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).