[v9,0/6] Optionally randomize kernel stack offset each syscall

Message

Kees Cook March 31, 2021, 8:54 p.m. UTC

Hi Will (and Mark and Catalin),

Can you take this via the arm64 tree for v5.13 please? Thomas has added
his Reviewed-by, so it only leaves arm64's. :)


v9:
- comment position nit (tglx)
- Added tglx's Reviewed-by
v8: https://lore.kernel.org/lkml/[e-mail]/
v7: https://lore.kernel.org/lkml/[e-mail]/
v6: https://lore.kernel.org/lkml/[e-mail]/
v5: https://lore.kernel.org/lkml/[e-mail]/
v4: https://lore.kernel.org/lkml/[e-mail]/
v3: https://lore.kernel.org/lkml/[e-mail]/
v2: https://lore.kernel.org/lkml/[e-mail]/
rfc: https://lore.kernel.org/kernel-hardening/[e-mail]/

This is a continuation and refactoring of Elena's earlier effort to add
kernel stack base offset randomization. In the time since the earlier
discussions, two attacks[1][2] were made public that depended on stack
determinism, so we're no longer in the position of "this is a good idea
but we have no examples of attacks". :)

Earlier discussions also devolved into debates on entropy sources, which
is mostly a red herring, given the already low entropy available due
to stack size. Regardless, entropy can be changed/improved separately
from this series as needed.

Earlier discussions also got stuck debating how much syscall overhead
was too much, but this is also a red herring since the feature itself
needs to be selectable at boot with no cost for those that don't want it:
this is solved here with static branches.

So, here is the latest improved version, made as arch-agnostic as
possible, with usage added for x86 and arm64. It also includes some small
static branch clean ups, and addresses some surprise performance issues
due to the stack canary[3].

Thanks!

-Kees

[1] https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html
[2] https://repositorio-aberto.up.pt/bitstream/10216/125357/2/374717.pdf
[3] https://lore.kernel.org/lkml/202003281520.A9BFF461@keescook/


Kees Cook (6):
  jump_label: Provide CONFIG-driven build state defaults
  init_on_alloc: Optimize static branches
  stack: Optionally randomize kernel stack offset each syscall
  x86/entry: Enable random_kstack_offset support
  arm64: entry: Enable random_kstack_offset support
  lkdtm: Add REPORT_STACK for checking stack offsets

 .../admin-guide/kernel-parameters.txt         | 11 ++++
 Makefile                                      |  4 ++
 arch/Kconfig                                  | 23 ++++++++
 arch/arm64/Kconfig                            |  1 +
 arch/arm64/kernel/Makefile                    |  5 ++
 arch/arm64/kernel/syscall.c                   | 16 ++++++
 arch/x86/Kconfig                              |  1 +
 arch/x86/entry/common.c                       |  3 ++
 arch/x86/include/asm/entry-common.h           | 16 ++++++
 drivers/misc/lkdtm/bugs.c                     | 17 ++++++
 drivers/misc/lkdtm/core.c                     |  1 +
 drivers/misc/lkdtm/lkdtm.h                    |  1 +
 include/linux/jump_label.h                    | 19 +++++++
 include/linux/mm.h                            | 10 ++--
 include/linux/randomize_kstack.h              | 54 +++++++++++++++++++
 init/main.c                                   | 23 ++++++++
 mm/page_alloc.c                               |  4 +-
 mm/slab.h                                     |  6 ++-
 18 files changed, 207 insertions(+), 8 deletions(-)
 create mode 100644 include/linux/randomize_kstack.h

Comments

Will Deacon April 1, 2021, 8:37 a.m. UTC | #1

Hi Kees,

On Wed, Mar 31, 2021 at 01:54:52PM -0700, Kees Cook wrote:
> Hi Will (and Mark and Catalin),
> 
> Can you take this via the arm64 tree for v5.13 please? Thomas has added
> his Reviewed-by, so it only leaves arm64's. :)

Sorry, these got mixed up in my inbox so I just replied to v7 and v8 and
then noticed v9. Argh!

However, I think the comments still apply: namely that the dummy "=m" looks
dangerous to me and I think you're accessing pcpu variables with preemption
enabled for the arm64 part:

https://lore.kernel.org/r/20210401083034.GA8554@willie-the-truck
https://lore.kernel.org/r/20210401083430.GB8554@willie-the-truck

Will

Thomas Gleixner April 1, 2021, 1:33 p.m. UTC | #2

On Thu, Apr 01 2021 at 09:37, Will Deacon wrote:
> On Wed, Mar 31, 2021 at 01:54:52PM -0700, Kees Cook wrote:
>> Hi Will (and Mark and Catalin),
>> 
>> Can you take this via the arm64 tree for v5.13 please? Thomas has added
>> his Reviewed-by, so it only leaves arm64's. :)
>
> Sorry, these got mixed up in my inbox so I just replied to v7 and v8 and
> then noticed v9. Argh!
>
> However, I think the comments still apply: namely that the dummy "=m" looks
> dangerous to me

> https://lore.kernel.org/r/20210401083034.GA8554@willie-the-truck

Hrmpf, didn't think about that.

> and I think you're accessing pcpu variables with preemption enabled
> for the arm64 part:

That's my fault. On x86 this is invoked right after coming up into C
code and _before_ enabling interrupts, which I why I suggested not to
use the wrapped one. raw_cpu_read() should be fine everywhere.

Thanks,

        tglx