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 
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 
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/statusca 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
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 
à 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
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 
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.
ou peut-être de ton inexpérience
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