Limiter la consommation CPU du sous-système Perf
Fixe kernel.perf_cpu_time_max_percent = 1 pour plafonner le temps CPU que le sous-système Perf peut consommer, protégeant la disponibilité du système.
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.
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
kernel.perf_cpu_time_max_percent plafonne le pourcentage maximal de temps CPU que le sous-système Perf du noyau peut consommer pour traiter les événements de performance. Laisser Perf sans limite permet à une charge d'échantillonnage élevée (ou conçue de façon malveillante) de monopoliser le CPU et de dégrader ou refuser le service. Restreindre Perf à 1% réduit le risque de problèmes de disponibilité dus à une activité de profilage incontrôlée.
Ce que vérifie Pavois
Pavois lit la valeur noyau en vigueur via kernel_parameter('kernel.perf_cpu_time_max_percent') (équivalent à sysctl kernel.perf_cpu_time_max_percent), et non une ligne de /etc/sysctl.d/*.conf. Un fichier peut déclarer 1 alors que le noyau en cours conserve une autre valeur, parce qu'un drop-in l'a écrasé ou que le fichier n'a jamais été appliqué. Le paramètre effectif est la seule preuve faisant foi.
describe kernel_parameter('kernel.perf_cpu_time_max_percent') do
its('value') { should cmp 1 }
end
describe command("grep -hsE '^[[:space:]]*kernel.perf_cpu_time_max_percent[[:space:]]*=[[:space:]]*1([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
its('stdout') { should match(/\S/) }
endComment vérifier qu’elle est appliquée
Exécutez sysctl kernel.perf_cpu_time_max_percent. Sortie attendue :
kernel.perf_cpu_time_max_percent = 1
Inspecter et investiguer
Aucune ligne de journal dédiée. Vérifiez via sysctl kernel.perf_cpu_time_max_percent. Lorsque Perf se brident parce que le traitement a dépassé la limite, le noyau émet un avertissement dans dmesg/journalctl -k du type perf: interrupt took too long ... lowering kernel.perf_event_max_sample_rate.
Remédiation
Le plan de durcissement de Pavois utilise la ressource sysctl pour fixer kernel.perf_cpu_time_max_percent = 1, le persiste dans un drop-in géré par Pavois sous /etc/sysctl.d/, et l'applique à chaud (sans redémarrage). Appliquez-le avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| key | kernel.perf_cpu_time_max_percent |
|---|---|
| resource | sysctl |
| value | 1 |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si non appliqué : une charge Perf sans limite (intentionnelle ou non) peut consommer un CPU excessif, dégradant ou refusant le service.
Précautions avant application :
- C'est un compromis profilage/observabilité. Plafonner Perf à 1% signifie que des exécutions
perflégitimes et lourdes seront bridées et que le noyau peut abaisser automatiquement la fréquence d'échantillonnage, réduisant la précision du profilage. Sur des hôtes dédiés à l'analyse de performance, ce réglage peut devoir être assoupli. - Aucun risque de casse applicative ou de blocage ; le changement est entièrement réversible à chaud.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R9 | direct | 2.0 | haute |
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.