Comment vérifier que KPTI est activé sur mon Ubuntu?


64

On corrige actuellement la vulnérabilité actuelle du processeur Meltdown Intel en activant l'isolation de la table des pages. Il y a une question qui se pose pour savoir comment désactiver cette option: comment désactiver l'isolation des tables de pages pour retrouver les performances perdues à cause du correctif de sécurité du processeur Intel?

Ma question est opposée: existe-t-il un moyen de vérifier sur un système en fonctionnement si le mécanisme PTI est efficace sur le système et donc que le système est protégé? Je recherche spécifiquement cat /proc/somethingou cat /sys/somethingne vérifie pas la version du noyau, le paramètre de configuration, etc.

Réponses:


4

Vous pouvez exécuter la commande ci-dessous pour afficher toutes les mesures d'atténuation disponibles (non seulement pour PTI, mais également pour d'autres vulnérabilités):

$ cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTE Inversion
Mitigation: Clear CPU buffers; SMT vulnerable
Mitigation: PTI
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling

Réponse géniale - courte et pertinente. Je vous remercie.
Martin Vysny le

63
  • Grepping CONFIG_PAGE_TABLE_ISOLATION dans la configuration du noyau comme suggéré par Raniz n'aide pas sur le bureau Ubuntu, mais peut aider sur les instances de cloud:

    grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && \
    echo "patched :)" || echo "unpatched :("
    

  • Vous pouvez vérifier avec /proc/cpuinfocomme JonasCz a suggéré :

    grep -q "cpu_insecure\|cpu_meltdown\|kaiser" /proc/cpuinfo && echo "patched :)" \
    || echo "unpatched :("
    

  • Ou de dmesg(grâce à Jason Creighton ):

    dmesg | grep -q "Kernel/User page tables isolation: enabled" \
    && echo "patched :)" || echo "unpatched :("
    

  • Vous pouvez compiler le programme de test de Raphael Carvalho pour la détection de Meltdown:

    sudo apt-get install git build-essential
    cd /tmp
    git clone https://github.com/raphaelsc/Am-I-affected-by-Meltdown.git
    cd Am-I-affected-by-Meltdown
    make
    sudo sh -c "echo 0  > /proc/sys/kernel/kptr_restrict"
    ./meltdown-checker
    

sur un système patché, il devrait se terminer par une sortie

...
so far so good (i.e. meltdown safe) ...

System not affected (take it with a grain of salt though as false negative
may be reported for specific environments; Please consider running it once again).

Sur le système corrigé, il devrait afficher les éléments suivants:

Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
...
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

N'installez pas 4.4.0-108-generic sur Xenial! Il rompt les fonctionnalités de démarrage / redémarrage / arrêt / suspension !

Installez 4.4.0-109-generic ( pour plus de détails, voir USN-3522-3 )!


Comme Robie Basak l'a déjà écrit , il existe une page sur l' état des vulnérabilités Spectre et Meltdown dans Ubuntu .

De plus il y a:


3
Les mises à jour pour Ubuntu sont prévues pour le 9 janvier. Elles pourraient atterrir plus tôt, mais je n’y compterais pas. insights.ubuntu.com/2018/01/04/…
Raniz

4
Les réponses de type "dmesg | grep isolation" sont préférables à ceci, IMO. Certaines distributions (du moins l'étendue Debian, peut-être d'autres) ont porté PTI sur leur ancien noyau, mais pas l'indicateur cpu_insecure dans / proc / cpuinfo. Sur ces systèmes, consulter le journal dmesg est le seul moyen de vérifier, AFAICT.
Jason Creighton

3
Je pense que la dmesg | grep isolation && echo "patched :)" || echo "unpatched :("commande listée est inutilement dangereuse : elle ne montre pas quelle ligne a été effectivement appariée, et afficherait également "patché :)" si un autre exemple "d'isolement"
choisi au

2
Je recommanderais contre la deuxième suggestion (grepping /proc/cpuinfopour cpu_insecure). Si vous mettez cela dans un script et vous avez un processeur à l'avenir où le problème est résolu dans sa microarchitecture, /proc/cpuinfone dira plus cpu_insecureet votre script pensent que le noyau est non corrigée même si elle est patché . Je recommande également de ne pas utiliser la troisième suggestion, car il est trop probable qu'il y ait un mot isolationdans la dmesgsortie à un moment donné sans qu'il fasse référence à l'isolation de la table des pages du noyau.
Blubberdiblub

4
Après une enquête plus approfondie, ces trois suggestions sont brisées. Grepping pour isolationcorrespondra à la fois Kernel/User page tables isolation: enabledet Kernel/User page tables isolation: disabled on command line.
Marc

18

Exécutez la commande suivante:

dmesg | grep 'page tables isolation'

S'il indique activé, alors PTI est activé. Si rien ne s'affiche ou si vous voyez «désactivé» dans le terminal, PTI est désactivé. Ubuntu n’ayant pas encore publié le correctif, il n’affiche aucun message.


... ou des messages ultérieurs du noyau ont repoussé les messages de démarrage hors de la mémoire tampon du journal du noyau. Si votre noyau imprime des avis concernant des éléments peu graves tels que les paquets réseau étranges, il est courant que les messages de démarrage ne fassent pas partie de la dmesgsortie. Voir /var/log/kern.log*si cela remonte assez loin pour avoir les messages de démarrage. Ubuntu avait l'habitude d'enregistrer la dmesgsortie au démarrage /var/log/dmesg, mais ne semble plus le faire.
Peter Cordes

Le 14 avril, j'ai eu dmesg: invalid option -- 'w'. -Hest également invalide. Enlever les drapeaux a bien fonctionné pour moi, comme dans cette réponse
wjandrea

/var/log/kern.log sur 14.04
eckes

12

Vous pouvez vérifier avec cat /proc/cpuinfo, s'il indique cpu_insecuresous "bugs", alors PTI est activé.

Si c'est vide (ou tout simplement pas dans la liste cpu_insecure), alors vous utilisez probablement un noyau qui n'a pas encore été corrigé (pas Ubuntu), ou vous avez un processeur AMD (pour lequel cela ne sera pas activé, car ils ne sont pas vulnérables).

Actuellement, tous les processeurs sont considérés comme vulnérables dans le dernier noyau 4.15.


4.15 n'est pas encore rendu public
Aadhil RF

C'est le cas si vous téléchargez la dernière version candidate de kernel.org et le compilez vous-même. @Mohammedaadhil
Rétablir Monica le

1
Un candidat à la libération n'est pas une libération.
Ruslan

L'article que vous avez lié a été mis à jour
nixpower le

2
Le noyau 4.14.11 sera défini cpu_insecurepour tout processeur x86; 4.14.12 et les versions plus récentes ne le configurent que pour les processeurs Intel (y compris ceux trop anciens ou trop primitifs pour être vulnérables), et ce même si KPTI est désactivé.
Marque le

8

J'ai trouvé ce bon script sh pour tester les vulnérabilités de Meltdown / spectre sur votre système:

https://github.com/speed47/spectre-meltdown-checker

Le script vérifie que votre système contient les correctifs Meltdown et Specter connus sur votre système pour vous indiquer si ces vulnérabilités sont maintenant limitées par votre système d'exploitation.


2

Vous pouvez vérifier /proc/config.gz pour savoir CONFIG_PAGE_TABLE_ISOLATION=ysi le noyau a été compilé avec KPTI.

Ceci est sur mon système Arch Linux corrigé fonctionnant sous 4.14.11-1:

$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz 
CONFIG_PAGE_TABLE_ISOLATION=y

3
Malheureusement, la configuration du noyau en cours d'exécution /proc/n'est pas activée par défaut dans les noyaux Ubuntu. La solution de contournement (beaucoup moins élégante) est grepping /boot/config-$( uname -r ).
Blubberdiblub

5
Cela vous indique seulement si le noyau a été compilé avec KPTI, pas si KPTI est actif (il peut être désactivé au démarrage, et éventuellement à l'exécution).
Mark

Si vous avez explicitement désactivé KPTI via les paramètres de ligne de commande du noyau, vous n'avez pas besoin de vérifier s'il est actif ou non.
Raniz

1

Sur mon instance AWS Ubuntu 14.04.5 LTS EC2, j'ai exécuté

grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r)

Il devrait dire:

CONFIG_PAGE_TABLE_ISOLATION=y

Pour la mise à jour j'ai fait:

sudo apt-get update && sudo apt-get install linux-image-generic

Je pense aussi que c'est OK:

sudo apt-get update
sudo apt-get dist-upgrade

Pour vérifier la version du noyau:

uname -r

Doit être générique 3.13.0-139 ou plus récent.


Cette méthode est déjà mentionnée dans la réponse
wjandrea
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.