← Toutes les règles
SOCLE-CLD-KRN-011// Kernel command linefaibleruntime effectif

Activer l'isolation des tables de pages du noyau (KPTI)

Exige le paramètre de démarrage noyau pti=on pour forcer l'isolation des tables de pages du noyau, mitigeant Meltdown et protégeant KASLR.

Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 2 normes

Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.

Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.

Pourquoi cette règle

L'isolation des tables de pages du noyau (KPTI) maintient les tables de pages du noyau séparées de celles de l'espace utilisateur, si bien qu'un processus utilisateur ne peut plus lire la mémoire noyau via le canal auxiliaire Meltdown (CVE-2017-5754). Elle renforce aussi le noyau contre les tentatives de contournement de KASLR par fuite d'adresses noyau. Forcer pti=on garantit que la mitigation est active même sur les CPU où le noyau pourrait sinon la désactiver automatiquement.

Ce que vérifie Pavois

Pavois lit la ligne de commande noyau active depuis /proc/cmdline et vérifie la présence de pti=on. C'est la ligne de boot analysée par le noyau, et non /etc/default/grub, une modification GRUB jamais régénérée passerait un scan fichier alors que PTI est encore désactivé. Vous pouvez confirmer l'état réel de la mitigation via /sys/devices/system/cpu/vulnerabilities/meltdown.

describe command('cat /proc/cmdline') do
  its('stdout') { should match(/(^| )pti=on( |$)/) }
end
describe command("grep -hwsF 'pti=on' /etc/default/grub /etc/kernel/cmdline /boot/grub/grub.cfg /boot/grub2/grub.cfg /boot/efi/EFI/*/grub.cfg 2>/dev/null") do
  its('stdout') { should match(/\S/) }
end

Comment vérifier qu’elle est appliquée

Lancez cat /proc/cmdline et confirmez la présence de pti=on. Vérifiez que la mitigation est active avec :

cat /sys/devices/system/cpu/vulnerabilities/meltdown

La sortie attendue indique Mitigation: PTI.

Inspecter et investiguer

L'état de la mitigation est exposé sous sysfs : cat /sys/devices/system/cpu/vulnerabilities/meltdown. Le noyau journalise aussi PTI au démarrage, dmesg | grep -iE 'page table isolation|pti' ou journalctl -k | grep -i pti.

Remédiation

pavois harden apply utilise la ressource kernel_cmdline pour ajouter pti=on à la configuration du bootloader et la régénérer, afin que l'option soit présente au prochain démarrage. Un redémarrage est requis pour qu'il prenne effet.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

parampti=on
reboot_requiredtrue
resourcekernel_cmdline
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

KPTI ajoute un coût de performance mesurable pour les charges intensives en appels système (flushs TLB supplémentaires aux transitions noyau/utilisateur), historiquement jusqu'à ~5-30 % pour les applications liées aux E/S ou aux appels système. Précautions :

  • Mesurez bases de données, stockage à fort IOPS et proxys avant un déploiement de masse.
  • Sur les CPU non affectés par Meltdown, forcer pti=on paie le coût sans gain de sécurité ; arbitrez par plateforme.
  • S'applique uniquement après redémarrage, planifiez une fenêtre de maintenance.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R8direct2.0haute
NISTSI-16support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne

Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.

Sources & références