The mysterious unreadable kernseal.txt file on PaX' documentation page has been sitting there since 2003, described as "sealed kernel storage design & implementation." After many years of KERNSEAL ETA WEN jokes, it was finally made available to grsecurity beta customers in August 2023.

Core Problem

The problem KERNSEAL sets out to solve is kernel self-protection: assuming arbitrary read/write access to kernel memory, the goal is to prevent privilege elevation.

Main Idea

The main idea behind PAX_KERNSEAL is the constification of dynamically allocated objects, similar to what PAX_CONSTIFY_PLUGIN does for static ones, as well as completely hiding some objects.

Key Mechanisms

• Sealed pages (__GFP_SEALED/PG_sealed): Mapped read-only in the direct map
• Hidden pages (__GFP_HIDDEN/PG_hidden): Completely unmapped in the direct map
• Per-CPU page tables: Under PAX_PRIVATE_KSTACKS, each task gets a dedicated stack slot with guard pages

Dependencies

• PaX' RAP (Return-oriented Programming prevention)
• PAX_PRIVATE_KSTACKS
• CONFIG_PAX_PER_CPU_PGD
• CONFIG_PAGE_TABLE_ISOLATION (PTI)

Interesting Usage: struct cred

The most obvious usage of KERNSEAL is on struct cred: the mutable fields are split into a separate struct cred_rw, while the cred structure itself is marked as sealed. This means credential's security-sensitive fields (UIDs, GIDs, capabilities) live on sealed pages and cannot be tampered with.

Notable

KERNSEAL is yet another tour de force from the PaX Team, who keeps consistently producing stellar software-only mitigations before everyone else, for almost 25 years. Unlike Apple's hardware-based mitigations (KTRR/CTRR/GXF/APRR/PPL/SPTM/TXM), KERNSEAL doesn't require special hardware support.