Avec toute l’agitation et la parution rapide des correctifs au sujet des failles Meltdown et Spectre, il peut être difficile de savoir si son processeur est affecté et quel est le niveau exact de protection de sa machine.
Afin d’aider les utilisateurs à trouver l’information, le développeur Thomas Gleixner a introduit un nouveau mécanisme qui permet d’avoir une vue unifiée de l’état actuel de son noyau.
Greg Kroah‐Hartman a posté un petit article à ce sujet pour expliquer la commande à lancer :
grep . /sys/devices/system/cpu/vulnerabilities/*
Cela retourne le statut pour chaque vulnérabilité (Meltdown, Spectre v1 et Spectre v2) :
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic ASM retpoline
On voit que, sur le noyau de Greg, la faille Meltdown est comblée (par la fonction de Page Table Isolation). Que la faille Spectre v1 est encore grande ouverte, tandis que la faille Spectre v2 n’est que partiellement corrigée par le mécanisme Retpoline.
Bien entendu, cette commande ne fonctionne que sur les toutes dernières versions du noyau (4.14.14 et rétroportage sur les versions LTS à support étendu). Comme le dit Greg :
« If your kernel does not have that sysfs directory or files, then obviously there is a problem and you need to upgrade your kernel! »
Pour info, avec la dernière mise à jour du noyau effectuée aujourd’hui, voici le résultat de la commande sur mon portable sous Arch Linux :
[patrick@laptop]: ~>$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline
Résumé des discussions préexistantes sur le journal concerné
Sur le risque de la faille pour l’utilisateur lambda : les failles sont connues/publiques, des démonstrations existent (voir les vidéos), y compris des attaques via le navigateur et JavaScript (il faut donc aussi avoir un navigateur à jour (en plus du noyau et/ou du microcode pour processeur), et se demander si un greffon bloquant tout ou partie du JavaScript est nécessaire ou pas pour sa propre utilisation). Le débit de fuite de données peut atteindre 500 Ko/s.
Sur le fait que la fonctionnalité soit accessible à tous les utilisateurs de la machine (plutôt qu’uniquement au super‐utilisateur root) : il n’y a plus besoin de tester la faille ou de vérifier la version du noyau pour connaître les vulnérabilités présentes sur la machine. Néanmoins, la version du noyau ou la ligne de commande de lancement du noyau sont disponibles de multiples façons et permettent déjà de savoir si le noyau est vulnérable. Il reste possible d’empêcher ou restreindre l’accès à cette nouvelle fonctionnalité via SELinux par exemple.
On peut aussi noter que les vulnérabilités sont mentionnées par leurs noms de baptême et non leurs numéros standards d’identification des vulnérabilités en informatique (en l’occurrence CVE-2017-5753, CVE-2017-5754 et CVE-2017-5715).
Le journal contient aussi des discussions sur d’autres sujets annexes, comme les préfixes binaires (Go vs Gio), les Retpolines ou la bonne/mauvaise utilisation de grep.
Merci à ceux qui ont participé à ces discussions, par leurs questions ou leurs réponses.
Aller plus loin
- Journal à l’origine de la dépêche (510 clics)
- [tip:x86/pti] sysfs/cpu: Add vulnerability folder (238 clics)
- Connaître le statut de son noyau concernant Meltdown et Spectre (461 clics)
# Touché coulé ?
Posté par Bastoon . Évalué à 3. Dernière modification le 23 janvier 2018 à 12:14.
Pourtant :
C'est la version la plus à jour de Debian. D'après l'article j'en déduis que Debian n'a encore rien corrigé. Vrai ?
[^] # Re: Touché coulé ?
Posté par Renault (site web personnel) . Évalué à 7.
C'est incomplet.
En effet ta Debian n'a pas tous les derniers correctifs concernant le noyau pour ces failles. Mais il en a probablement une partie.
En fait la commande citée repose sur un correctif arrivé plus tard pour décrire en détail ce qui est appliqué ou pas. Mais certains correctifs existaient avant. Mais pas tous.
De plus comme tu n'as pas la dernière version du noyau, tu devras attendre l'application de ces correctifs par Debian ou d'autres développeurs assurant la maintenance du noyau que tu utilises. Cela prend un peu de temps, d'autant que Debian n'est pas du genre à avoir une politique de mise à jour rapide.
[^] # Re: Touché coulé ?
Posté par Eiffel . Évalué à 4.
Six jeunes m'abusent ce noyau "Debian" est protégé contre Meltdown puisqu'il inclut la KPTI mais pas contre Spectre.
Il y a un script qui traîne sur GitHub pour savoir les failles qui touchent le noyau qui tourne actuellement sur votre machine.
Après je suis dans le même cas que vous, c'est-à-dire que je n'ai pas ces "fichiers" dans mon sysfs. Je rejoins toutefois l'avis de Renault, ces fichiers arriveront mais avec Debian soyons patients.
[^] # Re: Touché coulé ?
Posté par reynum (site web personnel) . Évalué à 10.
#Balance tes porcs
😗 --->[]
kentoc'h mervel eget bezan saotred
[^] # Re: Touché coulé ?
Posté par Frédéric Massot (site web personnel) . Évalué à 2.
Tu peux regarder le fichier "changelog.Debian.gz" dans le dossier "/usr/share/doc/linux-image-4.xxx/"
[^] # Re: Touché coulé ?
Posté par gouttegd . Évalué à 5.
Non, ici on peut seulement en déduire que ta version du noyau n’intègre pas encore le patch mentionné dans l’article.
Mais ce patch ne fait qu’exposer les vulnérabilités du CPU (via l’entrée sysfs
/sys/devices/system/cpu/vulnerabilities) et les mitigations éventuelles. Ce n’est pas parce que ce patch n’est pas appliqué que les patches protégeant contre Meltdown et Spectre ne le sont pas.En l’absence de ce patch, tu peux essayer d’aller consulter la configuration du noyau (par exemple dans
/proc/config.gz, ou dans/boot/config-*). Cherche les optionsCONFIG_PAGE_TABLE_ISOLATION(protection contre Meltdown) etCONFIG_RETPOLINE(protection partielle contre une des variantes de Spectre).[^] # Re: Touché coulé ?
Posté par Kerro . Évalué à 8.
Atténuations ?
Le mot « mitigation » existe en français mais n'est utilisé qu'en juridique/société et choses connexes. Cependant son sens est le même (avis perso) et je sens que ça va parfaitement convenir à l'informatique, l'électronique, la prévention des risques en tous genres, etc.
[^] # Re: Touché coulé ?
Posté par gouttegd . Évalué à 10.
En y repensant, le terme le plus approprié est à mon avis contre-mesure, mais il ne m’est pas venu à l’esprit en écrivant ce message tout à l’heure.
# Y en a un qui n'est pas content
Posté par gUI (Mastodon) . Évalué à 10. Dernière modification le 23 janvier 2018 à 13:38.
Linus a pas eu l'air d'apprécier le correctif annoncé par Intel pour les prochaines archis.
Description du correctif : https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
La réponse de Linus : https://lkml.org/lkml/2018/1/21/192
The whole IBRS_ALL feature to me very clearly says "Intel is not serious about this, we'll have a ugly hack that will be so expensive that we don't want to enable it by default, because that would look bad in benchmarks".
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Y en a un qui n'est pas content
Posté par Albert_ . Évalué à 7.
Chat échaudé craint l'eau froide?
Et on dirait qu'il a pas totalement tord sur la qualité de ce que fait intel actuellement…
Intel Urges OEMs and End Users To Stop Deploying Spectre Patch As It May 'Introduce Higher Than Expected Reboots'
[^] # Re: Y en a un qui n'est pas content
Posté par Eiffel . Évalué à 6.
J'ai regardé rapidement le document d'Intel et je ne trouve pas le correctif proposé très propre.
J'ai un peu l'impression qu'Intel propose des manières de se protéger mais ces manières devront être utilisées par les programmeurs (noyau et plus bas je pense).
J'ai quand même un peu de mal à comprendre leur philosophie. Quand je merde quelque part je corrige tout seul le problème, je ne propose pas des solutions à mes utilisateurs pour se protéger de mes erreurs…
[^] # Re: Y en a un qui n'est pas content
Posté par FantastIX . Évalué à 4. Dernière modification le 24 janvier 2018 à 15:22.
Je pense que c'est difficile de se mettre à la place de quelqu'un dont le produit se retrouve à la portée des doigts de la quasi totalité des êtres humains, parfois en plusieurs exemplaires. À cette échelle et avec une bourde de cette envergure, ce n'est pas une épée qu'ils ont au-dessus de la tête, c'est un panneau "procès" qui clignote en rouge. Je ne suis pas sûr qu'ils arrivent à dormir avec ça sur la conscience… à supposer qu'ils en aient une, ce qui, d'après les propos de Linus Torvalds, ne serait pas garanti à 100%:
# Titre
Posté par iouri . Évalué à 2.
Meltdown et Spectre, comment savoir si votre noyau est vulnérable ou pas
[^] # Re: Titre
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# Version plus générale
Posté par Serge Rossi (site web personnel) . Évalué à 5.
Autre test valable pour plus de distribs :
cat /boot/config-`uname -r` | egrep "CONFIG_PAGE_TABLE_ISOLATION|CONFIG_RETPOLINE"
Réponse pour le noyau courant de la Mageia 6, 4.14.13, : Oui pour PTI, absent pour Retpoline
Rien sur le 4.4.0-112 d'une Ubuntu 16.04.3 LTS
[^] # Re: Version plus générale
Posté par Joël Thieffry (site web personnel) . Évalué à 3.
OVH tient une page de recensement pour toutes les "distributions" déployables sur leurs machines : https://docs.ovh.com/fr/dedicated/meltdown-spectre-kernel-update-per-operating-system/ . Je ne connais pas la fréquence de rafraîchissement de ces informations.
[^] # Re: Version plus générale
Posté par patrick_g (site web personnel) . Évalué à 4.
Comment tu sais si tu n'as que le support minimal de retpoline (
Vulnerable: Minimal generic ASM retpoline) ou bien le support complet (Mitigation: Full generic retpoline) ?[^] # Re: Version plus générale
Posté par gouttegd . Évalué à 7.
Je ne pense pas que tu puisses trouver cette réponse dans la configuration du noyau.
Si j’ai bien compris, la différence entre le minimal generic ASM retpoline et le full generic retpoline dépend du compilateur utilisé pour construire le noyau : il faut un compilateur supportant l’option
-mindirect-branch=thunk-externpour obtenir le full generic retpoline.En l’absence de
-mindirect-branch=thunk-extern, seul le code assembleur présent d’origine dans les sources du noyau (donc écrit « à la main » et non pas généré par le compilateur) bénéficie de retpoline, c’est le minimal generic ASM retpoline.C’est donc vers le compilateur qu’il faut se tourner pour avoir la réponse à cette question (si le patch dont il est question dans le journal n’est pas disponible).
# Checker
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Comme il y a pas mal de manière de tester tout cela, il y a un checker en bash facilement lisible qui capitalise tout cela : Spectre & Meltdown checker
https://github.com/speed47/spectre-meltdown-checker
wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.