05 Sep, 2018

3 commits

  • Introduce CONFIG_STACKLEAK_RUNTIME_DISABLE option, which provides
    'stack_erasing' sysctl. It can be used in runtime to control kernel
    stack erasing for kernels built with CONFIG_GCC_PLUGIN_STACKLEAK.

    Suggested-by: Ingo Molnar
    Signed-off-by: Alexander Popov
    Tested-by: Laura Abbott
    Signed-off-by: Kees Cook

    Alexander Popov
     
  • Introduce CONFIG_STACKLEAK_METRICS providing STACKLEAK information about
    tasks via the /proc file system. In particular, /proc//stack_depth
    shows the maximum kernel stack consumption for the current and previous
    syscalls. Although this information is not precise, it can be useful for
    estimating the STACKLEAK performance impact for your workloads.

    Suggested-by: Ingo Molnar
    Signed-off-by: Alexander Popov
    Tested-by: Laura Abbott
    Signed-off-by: Kees Cook

    Alexander Popov
     
  • The STACKLEAK feature (initially developed by PaX Team) has the following
    benefits:

    1. Reduces the information that can be revealed through kernel stack leak
    bugs. The idea of erasing the thread stack at the end of syscalls is
    similar to CONFIG_PAGE_POISONING and memzero_explicit() in kernel
    crypto, which all comply with FDP_RIP.2 (Full Residual Information
    Protection) of the Common Criteria standard.

    2. Blocks some uninitialized stack variable attacks (e.g. CVE-2017-17712,
    CVE-2010-2963). That kind of bugs should be killed by improving C
    compilers in future, which might take a long time.

    This commit introduces the code filling the used part of the kernel
    stack with a poison value before returning to userspace. Full
    STACKLEAK feature also contains the gcc plugin which comes in a
    separate commit.

    The STACKLEAK feature is ported from grsecurity/PaX. More information at:
    https://grsecurity.net/
    https://pax.grsecurity.net/

    This code is modified from Brad Spengler/PaX Team's code in the last
    public patch of grsecurity/PaX based on our understanding of the code.
    Changes or omissions from the original code are ours and don't reflect
    the original grsecurity/PaX code.

    Performance impact:

    Hardware: Intel Core i7-4770, 16 GB RAM

    Test #1: building the Linux kernel on a single core
    0.91% slowdown

    Test #2: hackbench -s 4096 -l 2000 -g 15 -f 25 -P
    4.2% slowdown

    So the STACKLEAK description in Kconfig includes: "The tradeoff is the
    performance impact: on a single CPU system kernel compilation sees a 1%
    slowdown, other systems and workloads may vary and you are advised to
    test this feature on your expected workload before deploying it".

    Signed-off-by: Alexander Popov
    Acked-by: Thomas Gleixner
    Reviewed-by: Dave Hansen
    Acked-by: Ingo Molnar
    Signed-off-by: Kees Cook

    Alexander Popov