Documentation/mm/vmalloced-kernel-stacks.rst

Source file repositories/reference/linux-study-clean/Documentation/mm/vmalloced-kernel-stacks.rst

File Facts

System
Linux kernel
Corpus path
Documentation/mm/vmalloced-kernel-stacks.rst
Extension
.rst
Size
5734 bytes
Lines
154
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

=====================================
Virtually Mapped Kernel Stack Support
=====================================

:Author: Shuah Khan <skhan@linuxfoundation.org>

.. contents:: :local:

Overview
--------

This is a compilation of information from the code and original patch
series that introduced the `Virtually Mapped Kernel Stacks feature
<https://lwn.net/Articles/694348/>`

Introduction
------------

Kernel stack overflows are often hard to debug and make the kernel
susceptible to exploits. Problems could show up at a later time making
it difficult to isolate and root-cause.

Virtually mapped kernel stacks with guard pages cause kernel stack
overflows to be caught immediately rather than causing difficult to
diagnose corruptions.

HAVE_ARCH_VMAP_STACK and VMAP_STACK configuration options enable
support for virtually mapped stacks with guard pages. This feature
causes reliable faults when the stack overflows. The usability of
the stack trace after overflow and response to the overflow itself
is architecture dependent.

.. note::
        As of this writing, arm64, powerpc, riscv, s390, um, and x86 have
        support for VMAP_STACK.

HAVE_ARCH_VMAP_STACK
--------------------

Architectures that can support Virtually Mapped Kernel Stacks should
enable this bool configuration option. The requirements are:

- vmalloc space must be large enough to hold many kernel stacks. This
  may rule out many 32-bit architectures.
- Stacks in vmalloc space need to work reliably.  For example, if
  vmap page tables are created on demand, either this mechanism
  needs to work while the stack points to a virtual address with
  unpopulated page tables or arch code (switch_to() and switch_mm(),
  most likely) needs to ensure that the stack's page table entries
  are populated before running on a possibly unpopulated stack.
- If the stack overflows into a guard page, something reasonable
  should happen. The definition of "reasonable" is flexible, but
  instantly rebooting without logging anything would be unfriendly.

VMAP_STACK
----------

When enabled, the VMAP_STACK bool configuration option allocates virtually
mapped task stacks. This option depends on HAVE_ARCH_VMAP_STACK.

- Enable this if you want the use virtually-mapped kernel stacks
  with guard pages. This causes kernel stack overflows to be caught
  immediately rather than causing difficult-to-diagnose corruption.

.. note::

        Using this feature with KASAN requires architecture support
        for backing virtual mappings with real shadow memory, and

Annotation

Implementation Notes