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
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 
à 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
Je n’ai pas utilisé le bon bouton répondre, mais je m’adressais à @mattotop qui confondait experimental et Sid. Ma réponse était peut être trop complète (en parlant de mon expérience), c’est pour ça que j’invitais à un retour à la conversation d’origine.
De fait…
Sinon, concernant la testing, la sid, et un fonctionnement correct, ça dépend si tu considères la stabilité du système en fonctionnement, ou si tu considères les problèmes de dépendances.
Pour la sid, les problèmes que j’ai eu sont surtout sur la stabilité du système, plus que les questions de dépendances.
Pour la testing, il y a des soucis forts de dépendance tout au long de sa stabilisation, mais le système est vite plus stable que la sid et vers la fin de sa maturation, la testing est souvent bien, quand même.
Aprés, j’ai installé ma premi-ère debian en slink ou potato, je ne sais plus, et avec l’expérience, pour une machine perso, mais qui doit rester suffisament stable pour ne pas empêcher de bosser, le meilleur compromis entre stabilité et versions fraiches que j’ai trouvé, c’est la stable, avec des préférences pour entretenir certains paquets en backport.
Enfin c’est ma préférence.
Etat des lieux
grep bugs /proc/cpuinfo
bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2
bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2
root@debian:/# spectre-meltdown-checker
Spectre and Meltdown mitigation detection tool v0.34
Checking for vulnerabilities on current system
Kernel is Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.17-1 (2018-02-14) x86_64
CPU is AMD Athlon(tm) II P340 Dual-Core Processor
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: NO
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable)
* Kernel has array_index_mask_nospec: NO
* Checking count of LFENCE instructions following a jump in kernel: NO (only 2 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS: VULNERABLE (Kernel source needs to be patched to mitigate the vulnerability)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Full AMD retpoline)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that your CPU is unaffected)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: NO
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
A false sense of security is worse than no security at all, see --disclaimer
root@debian:/#
ça progresse avec le noyau 4.9.0.6
root@debian:/# spectre-meltdown-checker
Spectre and Meltdown mitigation detection tool v0.34
Checking for vulnerabilities on current system
Kernel is Linux 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u2 (2018-02-21) x86_64
CPU is AMD Athlon(tm) II P340 Dual-Core Processor
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: NO
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: NO
> STATUS: NOT VULNERABLE (Mitigation: Full AMD retpoline - vulnerable module loaded)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that your CPU is unaffected)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: NO
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
A false sense of security is worse than no security at all, see --disclaimer
root@debian:/#
root@debian:/# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline - vulnerable module loaded
root@debian:/#