08 Jan, 2021

1 commit

  • The kernel currently uses kmem_cache to allocate shadow call stacks,
    which means an overflows may not be immediately detected and can
    potentially result in another task's shadow stack to be overwritten.

    This change switches SCS to use virtually mapped shadow stacks for
    tasks, which increases shadow stack size to a full page and provides
    more robust overflow detection, similarly to VMAP_STACK.

    Bug: 169781940
    Change-Id: I92c8f5706c11e4bf45b071e4f302a65502faa1e1
    (cherry picked from commit a2abe7cbd8fe2db5ff386c968e2273d9dc6c468d)
    Signed-off-by: Sami Tolvanen
    Acked-by: Will Deacon
    Link: https://lore.kernel.org/r/20201130233442.2562064-2-samitolvanen@google.com
    Signed-off-by: Will Deacon

    Sami Tolvanen
     

08 Aug, 2020

1 commit

  • Currently the kernel stack is being accounted per-zone. There is no need
    to do that. In addition due to being per-zone, memcg has to keep a
    separate MEMCG_KERNEL_STACK_KB. Make the stat per-node and deprecate
    MEMCG_KERNEL_STACK_KB as memcg_stat_item is an extension of
    node_stat_item. In addition localize the kernel stack stats updates to
    account_kernel_stack().

    Signed-off-by: Shakeel Butt
    Signed-off-by: Andrew Morton
    Reviewed-by: Roman Gushchin
    Cc: Johannes Weiner
    Cc: Michal Hocko
    Link: http://lkml.kernel.org/r/20200630161539.1759185-1-shakeelb@google.com
    Signed-off-by: Linus Torvalds

    Shakeel Butt
     

04 Jun, 2020

1 commit


19 May, 2020

4 commits

  • asm/scs.h is no longer needed by the core code, so remove a redundant
    header inclusion and update the stale Kconfig text.

    Tested-by: Sami Tolvanen
    Reviewed-by: Mark Rutland
    Signed-off-by: Will Deacon

    Will Deacon
     
  • There is nothing architecture-specific about scs_overflow_check() as
    it's just a trivial wrapper around scs_corrupted().

    For parity with task_stack_end_corrupted(), rename scs_corrupted() to
    task_scs_end_corrupted() and call it from schedule_debug() when
    CONFIG_SCHED_STACK_END_CHECK_is enabled, which better reflects its
    purpose as a debug feature to catch inadvertent overflow of the SCS.
    Finally, remove the unused scs_overflow_check() function entirely.

    This has absolutely no impact on architectures that do not support SCS
    (currently arm64 only).

    Tested-by: Sami Tolvanen
    Reviewed-by: Mark Rutland
    Signed-off-by: Will Deacon

    Will Deacon
     
  • There's no need to perform the shadow stack page accounting independently
    of the lifetime of the underlying allocation, so call the accounting code
    from the {alloc,free}() functions and simplify the code in the process.

    Tested-by: Sami Tolvanen
    Reviewed-by: Mark Rutland
    Signed-off-by: Will Deacon

    Will Deacon
     
  • Storing the SCS information in thread_info as a {base,offset} pair
    introduces an additional load instruction on the ret-to-user path,
    since the SCS stack pointer in x18 has to be converted back to an offset
    by subtracting the base.

    Replace the offset with the absolute SCS stack pointer value instead
    and avoid the redundant load.

    Tested-by: Sami Tolvanen
    Reviewed-by: Mark Rutland
    Signed-off-by: Will Deacon

    Will Deacon
     

15 May, 2020

3 commits

  • Implements CONFIG_DEBUG_STACK_USAGE for shadow stacks. When enabled,
    also prints out the highest shadow stack usage per process.

    Signed-off-by: Sami Tolvanen
    Reviewed-by: Kees Cook
    Acked-by: Will Deacon
    [will: rewrote most of scs_check_usage()]
    Signed-off-by: Will Deacon

    Sami Tolvanen
     
  • This change adds accounting for the memory allocated for shadow stacks.

    Signed-off-by: Sami Tolvanen
    Reviewed-by: Kees Cook
    Acked-by: Will Deacon
    Signed-off-by: Will Deacon

    Sami Tolvanen
     
  • This change adds generic support for Clang's Shadow Call Stack,
    which uses a shadow stack to protect return addresses from being
    overwritten by an attacker. Details are available here:

    https://clang.llvm.org/docs/ShadowCallStack.html

    Note that security guarantees in the kernel differ from the ones
    documented for user space. The kernel must store addresses of
    shadow stacks in memory, which means an attacker capable reading
    and writing arbitrary memory may be able to locate them and hijack
    control flow by modifying the stacks.

    Signed-off-by: Sami Tolvanen
    Reviewed-by: Kees Cook
    Reviewed-by: Miguel Ojeda
    [will: Numerous cosmetic changes]
    Signed-off-by: Will Deacon

    Sami Tolvanen