summary refs log tree commit diff
path: root/drivers/clk
diff options
context:
space:
mode:
authorKees Cook <keescook@chromium.org>2019-06-22 13:18:23 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-06-23 07:05:56 +0200
commit06b32fdb030989c45bb9dad685b794bf2395d53a (patch)
treec73030b5bb87d2923868488574fbd3bf2093046c /drivers/clk
parent1909a671dbc3606685b1daf8b22a16f65ea7edda (diff)
downloadlinux-06b32fdb030989c45bb9dad685b794bf2395d53a.tar.gz
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/clk')
0 files changed, 0 insertions, 0 deletions