Faille Spectre/Meltdown dans les processeurs. Comment interpréter la commande "grep bugs /proc/cpuinfo"

Tags: #<Tag:0x00007fbd23fc5e30>

Salut
Que conclure de cette commande?

    root@debian:/# grep bugs /proc/cpuinfo
    bugs		: tlb_mmatch fxsave_leak sysret_ss_attrs null_seg amd_e400
    bugs		: tlb_mmatch fxsave_leak sysret_ss_attrs null_seg amd_e400

Est-ce bien la liste des failles corrigées sur mes 2 cpu ? (AMD en l’occurrence)
http://wiki.osdev.org/CPU_Bugs

De ce que j’ai lu à gauche à droite, c’est aussi ce que je comprend: ces flags sont les bugs détectés et corrigés.
A priori les flags cpu_insecure cpu_meltdown kaiser indiquent la protection pour meltdown: https://askubuntu.com/questions/992137/how-to-check-that-kpti-is-enabled-on-my-ubuntu

pour Meltdown j’ai suivi ça
https://cert.ssi.gouv.fr/alerte/CERTFR-2018-ALE-001/

root@debian:/# dmesg | grep 'Kernel/User page tables isolation'
[    0.000000] Kernel/User page tables isolation: disabled
root@debian:/# grep name /proc/cpuinfo
model name	: AMD Athlon(tm) II P340 Dual-Core Processor
model name	: AMD Athlon(tm) II P340 Dual-Core Processor
root@debian:/# uname --all
Linux debian 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux
root@debian:/#

Oui, et il te dit que le KPTI est désactivé.
Heureusement que tu es sous AMD, du coup.

oui
https://cert.ssi.gouv.fr/alerte/CERTFR-2018-ALE-001/
dit
Processeurs AMD
AMD est vulnérable à Spectre, mais pas à Meltdown.

ça a quand meme bougé coté AMD

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886382

apt list *microcode*

amd64-microcode/testing,now 3.20171205.1 amd64  [installé]
intel-microcode/testing 3.20180108.1 amd64
microcode.ctl/testing,stable 1.18~0+nmu2 amd64

Bonjour,

Je suis perdu, ils parlent d’un fix pour Spectre ou Meltdown ou les deux ?
J’ai désactivé le fix venant du noyau pour être tranquille, mais dois-je le réactiver ? Ou alors le microcode n’a rien à voir ?

Ma compréhension mais je ne mets pas ma tête sur le billot :joy:

j’ en reste à ce commentaire concernant les cpu AMD
Yes, they are, although just by Spectre as far as we know (i.e. not
affected by Meltdown).

le changement de microcode ne concerne que Spectre, mais seulement pour Zen


grep bugs /proc/cpuinfo
bugs		: tlb_mmatch fxsave_leak sysret_ss_attrs null_seg amd_e400
bugs		: tlb_mmatch fxsave_leak sysret_ss_attrs null_seg amd_e400
grep name /proc/cpuinfo
model name	: AMD Athlon(tm) II P340 Dual-Core Processor
model name	: AMD Athlon(tm) II P340 Dual-Core Processor

It seems AMD just released a microcode update to disable branch
prediction on its Zen architecture.

https://www.amd.com/fr/technologies/zen-core

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

l’update du noyau concerne Meltdown donc seulement Intel

Merci beaucoup pour toutes ces précisions, c’est bien ce que j’avais compris.
Je n’ai pas compris ce que tu essayais de montrer avec tes grep :confused:

sk4hrr@mufasa:~$ grep bugs /proc/cpuinfo
bugs		: sysret_ss_attrs null_seg
bugs		: sysret_ss_attrs null_seg
bugs		: sysret_ss_attrs null_seg
bugs		: sysret_ss_attrs null_seg
bugs		: sysret_ss_attrs null_seg
bugs		: sysret_ss_attrs null_seg
bugs		: sysret_ss_attrs null_seg
bugs		: sysret_ss_attrs null_seg
bugs		: sysret_ss_attrs null_seg
bugs		: sysret_ss_attrs null_seg
bugs		: sysret_ss_attrs null_seg
bugs		: sysret_ss_attrs null_seg
sk4hrr@mufasa:~$ grep name /proc/cpuinfo
model name	: AMD Ryzen 5 1600X Six-Core Processor
model name	: AMD Ryzen 5 1600X Six-Core Processor
model name	: AMD Ryzen 5 1600X Six-Core Processor
model name	: AMD Ryzen 5 1600X Six-Core Processor
model name	: AMD Ryzen 5 1600X Six-Core Processor
model name	: AMD Ryzen 5 1600X Six-Core Processor
model name	: AMD Ryzen 5 1600X Six-Core Processor
model name	: AMD Ryzen 5 1600X Six-Core Processor
model name	: AMD Ryzen 5 1600X Six-Core Processor
model name	: AMD Ryzen 5 1600X Six-Core Processor
model name	: AMD Ryzen 5 1600X Six-Core Processor
model name	: AMD Ryzen 5 1600X Six-Core Processor
sk4hrr@mufasa:~$ uname -a
Linux mufasa 4.14.0-3-amd64 #1 SMP Debian 4.14.12-2 (2018-01-06) x86_64 GNU/Linux
sk4hrr@mufasa:~$ apt-cache policy amd64-microcode
amd64-microcode:
  Installé : 3.20171205.1
  Candidat : 3.20171205.1
 Table de version :
 *** 3.20171205.1 500
        500 http://ftp.fr.debian.org/debian sid/non-free amd64 Packages
        100 /var/lib/dpkg/status

ca indique les bugs corriges sur ton processeur 12 coeurs

http://wiki.osdev.org/CPU_Bugs

qui est donc un Ryzen qui est donc concerné par le dernier microcode AMD

Par ailleurs le noyau 4.14 n’est pas le plus securisé, vaut mieux garder celui de Stretch
4.9.65-3
https://security-tracker.debian.org/tracker/source-package/linux

Comment expliquer ceci :

fp2@debpacha:~$ egrep 'bugs|name' /proc/cpuinfo 
model name	: Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz
bugs		:
model name	: Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz
bugs		:
model name	: Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz
bugs		:
model name	: Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz
bugs		:
model name	: Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz
bugs		:
model name	: Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz
bugs		:
model name	: Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz
bugs		:
model name	: Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz
bugs		:
fp2@debpacha:~
fp2@debpacha:/var/cache/apt/archives$ sudo dmesg | fgrep -i isolation
[    0.000000] Kernel/User page tables isolation: enabled 
fp2@debpacha:/var/cache/apt/archives$ l linux-image-4.9.0-5-amd64_4.9.65-3+deb9u2_amd64.deb 
37860 -rw-r--r-- 1 root root 38768102 janv.  4 20:49 linux-image-4.9.0-5-amd64_4.9.65-3+deb9u2_amd64.deb
fp2@debpacha:/var/cache/apt/archives$

Autrement dit, KPTI est bien enclenché (je viens de redémarrer), mais les bugs corrigés n’apparaissent pas dans /proc/cpuinfo

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« L’arbre tombe toujours du côté où il penche. »
Proverbe français

Concierge qui roule, ne s’arrête qu’au bas de l’escalier.
Les proverbes philosophiques du Professeur Choron

je dirai que le palliatif KPTI est au niveau du noyau pas dans le microcode cpu, mais je ne suis pas un développeur :slight_smile:
à lire
https://cert.ssi.gouv.fr/alerte/CERTFR-2018-ALE-001/

As tu installé le microcode intel?

apt list *microcode*
En train de lister... Fait
amd64-microcode/testing,now 3.20171205.1 amd64  [installé]
intel-microcode/testing 3.20180108.1 amd64
microcode.ctl/testing,stable 1.18~0+nmu2 amd64

Merci de toutes ces informations !

Je suis sous Sid et j’évite le mélange de dépôts, c’est pour cela que je suis en 4.14 :slight_smile:

C’est illogique.
la sid n’est pas une release, c’est un jeu incomplet de paquets en version de test.
Il faut la compléter avec soit les dépots testing soit les stable pour un fonctionnement correct.

Je pense que tu confonds avec experimental :

“A la différence des versions Debian unstable et testing, experimental n’est pas une distribution complète.” - https://wiki.debian.org/fr/DebianExperimental

Je suis passé par toutes les distributions de Debian :

  • stable : porte bien son nom, mais attendre les mises à jour pour pouvoir changer d’ordinateur (support CPU ou GPU)…
  • testing : pour moi c’est celle-ci qui est instable, j’y ai passé environ six mois de galères (dépendances manquantes, paquets contenant des version bogguées et j’en passe)
  • unstable : j’y ai retrouvé la stabilité tout en ayant des paquets relativement à jour (cycle de validation court)

Bref, pas le sujet ici :wink:

testing n’est certainement pas instable, elle est au départ un clone de stable dans laquelle on ajoute au fur et à mesure des paquets plus récents pour avoir des versions de logiciels plus à jour. C’est par définition la version qui est appelée à passer stable dans l’avenir.
je n’ai jamais eu de soucis tel que tu le décrit en utilisant l’actuel testing/Buster
https://www.debian.org/releases/

J’utilise Debian depuis des années, mon expérience fait que pour mon utilisation personnelle, je ne teste pas à nouveau toutes les distributions. J’installe du Sid parce que depuis toutes ces années, je n’ai jamais eu de gros problème avec. C’est un choix tiré de mon expérience.

:joy:ou peut-être de ton inexpérience :joy:

Veuillez noter que les mises à jour de sécurité pour la distribution « unstable » ne sont pas gérées par l’équipe en charge de la sécurité. Ce qui signifie que les mises à jour de sécurité pour « unstable » ne sont pas faites en temps et en heure.
https://www.debian.org/releases/sid/

Le genre de phrase qui m’agace un peu… On a tous appris à un moment ou un autre et le fait est, qu’avec mon expérience de l’époque, j’ai trouvé unstable plus facile à utiliser que testing. Je ne vois vraiment pas en quoi ça apporte quoique ce soit de porter un jugement sur un choix personnel (même si c’est un choix c*n, ça reste le mien).

Par ailleurs, je sais lire et je sais en quoi la distribution unstable est différente des autres.

c’est un fil de discussion ou on parle de sécurité, donc sid n’est pas le meilleur choix
c’est simplement ce que j’indique