Attaques RETBleed? [Réglé]
gerard-ll Membre non connecté
-
- Voir le profil du membre gerard-ll
- Inscrit le : 09/12/2011
- Groupes :
Au démarrage du PC je vois cette ligne :
"RETBleed: WARNING: Spetre v2 mitigation leaves CPU vilnerable to RETBleed attacks, data leaks possible!"
En français :
"RETBleed : AVERTISSEMENT : la mesure d'atténuation Spetre v2 laisse le processeur vulnérable aux attaques RETBleed, des fuites de données sont possibles !"
Dois-je m'en inquiéter?
Une recherche sur Qwant me donne cette solution :
Caché :
Solution proposée
Pour corriger ce problème, vous pouvez appliquer les étapes suivantes :
Mettre à jour le système :
Assurez-vous que votre système d'exploitation et le noyau sont à jour.
Installez les derniers correctifs de sécurité disponibles.
Commande à exécuter :
Sur le terminal de l'hôte, exécutez la commande suivante pour activer les mitigations nécessaires : bash echo "options kvm-intel mitigations=auto" | sudo tee /etc/modprobe.d/kvm-intel.conf
Ensuite, rechargez le module KVM : bash sudo update-initramfs -u sudo reboot
Vérification :
Après le redémarrage, vérifiez que l'avertissement ne s'affiche plus.
Pour corriger ce problème, vous pouvez appliquer les étapes suivantes :
Mettre à jour le système :
Assurez-vous que votre système d'exploitation et le noyau sont à jour.
Installez les derniers correctifs de sécurité disponibles.
Commande à exécuter :
Sur le terminal de l'hôte, exécutez la commande suivante pour activer les mitigations nécessaires : bash echo "options kvm-intel mitigations=auto" | sudo tee /etc/modprobe.d/kvm-intel.conf
Ensuite, rechargez le module KVM : bash sudo update-initramfs -u sudo reboot
Vérification :
Après le redémarrage, vérifiez que l'avertissement ne s'affiche plus.
Faut-il que je fasse ça?
Tout ça, ça vient du fait que j'ai remplacé mon PC de tests par une tour que mon voisin m'a donné vu qu'il a acheté un autre PC.
J'ai juste débranché le disque dur SSD pour le remettre dans cette tour et ça a fonctionné au démarrage! (Ouai!)
Du coup j'utilise ça :
Caché :
Code TEXT :
[gerard@localhost ~]$ neofetch
.°°. gerard@localhost
°° .°°. ----------------
.°°°. °° OS: Mageia 9 x86_64
. . Host: 90ED003FFR ideacentre 700-25ISH
°°° .°°°. Kernel: 6.6.105-desktop-1.mga9
.°°°. '___' Uptime: 50 mins
.'___' . Packages: 2672 (rpm)
:dkxc;'. ..,cxkd; Shell: bash 5.2.15
.dkk. kkkkkkkkkk .kkd. Resolution: 1680x1050
.dkk. ';cloolc;. .kkd DE: GNOME 44.2
ckk. .kk; WM: Mutter
xO: cOd WM Theme: Adwaita
xO: lOd Theme: Adwaita [GTK2/3]
lOO. .OO: Icons: Adwaita [GTK2/3]
.k00. .00x Terminal: gnome-terminal
.k00; ;00O. CPU: Intel i5-6400 (4) @ 3.300GHz
.lO0Kc;,,,,,,;c0KOc. GPU: NVIDIA GeForce GTX 750 Ti
;d00KKKKKK00d; Memory: 2009MiB / 7872MiB
.,KKKK,.
... au lieu de ça :
Caché :
Code TEXT :
[ggtest@localhost ~]$ [gerard@localhost ~]$ neofetch
.°°. gerard@localhost
°° .°°. ----------------
.°°°. °° OS: Mageia 9 x86_64
. . Kernel: 6.6.101-desktop-1.mga9
°°° .°°°. Uptime: 34 mins
.°°°. '___' Packages: 2411 (rpm)
.'___' . Shell: bash 5.2.15
:dkxc;'. ..,cxkd; Resolution: 1680x1050
.dkk. kkkkkkkkkk .kkd. DE: GNOME 44.2
.dkk. ';cloolc;. .kkd WM: Mutter
ckk. .kk; WM Theme: Adwaita
xO: cOd Theme: Adwaita [GTK2/3]
xO: lOd Icons: Adwaita [GTK2/3]
lOO. .OO: Terminal: gnome-terminal
.k00. .00x CPU: Intel Core 2 Duo E8400 (2) @ 2.997GHz
.k00; ;00O. GPU: AMD ATI Radeon HD 4850
.lO0Kc;,,,,,,;c0KOc. Memory: 903MiB / 3907MiB
;d00KKKKKK00d;
.,KKKK,.Il y a donc un peu plus de puissance, visiblement.
Comme ça je peux mieux apprécier Gnome et voir la différence avec KDE.
Le souci est que c'est une marque, LENOVO que c'est écrit
![:]](/images/smileys/8.gif)
Je n'ai jamais utilisé de marque pour mes PC, toujours des montages avec des processeurs qui sont vendus en boite.
Je me demande si les marques n'utilisent pas du matériel un peu dégradé pour réduire les coûts?
En fin je dis ça peut-être que hallucine un peu
Bon weekend à tous
Edit : J'ai modifié les écrits de ma vieille configuration, c'était un Intel Core 2 Duo E8400.
Édité par gerard-ll Le 16/11/2025 à 10h59
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
gerard-ll Membre non connecté
-
- Voir le profil du membre gerard-ll
- Inscrit le : 09/12/2011
- Groupes :
Jybz :Au lieu de … mageia 7 ?!
Ah zut non!
C'est juste que j'ai fait un copier/collé d'une vielle discussion pour montrer mon ancienne configuration.
Désolé je n'avais pas regardé
gerard-ll Membre non connecté
-
- Voir le profil du membre gerard-ll
- Inscrit le : 09/12/2011
- Groupes :
Mais ça ne change rien au souci qui n'en ai peut-être pas un
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Il est surprenant que cela apparaisse sur un PC hôte. En règle générale, ce message apparait sur les machines virtualbox ( afin d' augmenter les performances de l' hyperviseur ( l' activation des mitigations peut réduire drastiquement les performances)).
Si sur une machine normale, il faut que le bios, le microcode CPU et le noyau supportent ces limitations.
que donne un ( en root) : journalctl -b 0 | grep -i mitigation , ainsi qu' un lscpu ( en utilisateur normal) ?
edit: sur ma machine, je vois ceci pour le lscpu.
Citation :Vulnérabilités :
Gather data sampling : Vulnerable: No microcode
Indirect target selection : Not affected
Itlb multihit : KVM: Mitigation: VMX disabled
L1tf : Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Mds : Mitigation; Clear CPU buffers; SMT vulnerable
Meltdown : Mitigation; PTI
Mmio stale data : Mitigation; Clear CPU buffers; SMT vulnerable
Reg file data sampling : Not affected
Retbleed : Mitigation; IBRS
Spec rstack overflow : Not affected
Spec store bypass : Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1 : Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2 : Mitigation; IBRS; IBPB conditional; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Srbds : Mitigation; Microcode
Tsa : Not affected
Tsx async abort : Mitigation; TSX disabled
De ce que je comprends le gather data sampling est vulnérable ainsi que l' hyperthreading ( pour le l1tf, mds et mmio). Mais bon je n' ai ni envie de flasher le bios, ni désactiver l' hyperthreading.
Édité par nic80 Le 16/11/2025 à 14h05
gerard-ll Membre non connecté
-
- Voir le profil du membre gerard-ll
- Inscrit le : 09/12/2011
- Groupes :
Pour lscpu je vois ça :
Caché :
Code TEXT :
lscpu
Architecture : x86_64
Mode(s) opératoire(s) des processeurs : 32-bit, 64-bit
Tailles des adresses: 39 bits physical, 48 bits virtual
Boutisme : Little Endian
Processeur(s) : 4
Liste de processeur(s) en ligne : 0-3
Identifiant constructeur : GenuineIntel
Nom de modèle : Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
Famille de processeur : 6
Modèle : 94
Thread(s) par cœur : 1
Cœur(s) par socket : 4
Socket(s) : 1
Révision : 3
multiplication des MHz du/des CPU(s) : 38%
Vitesse maximale du processeur en MHz : 3300,0000
Vitesse minimale du processeur en MHz : 800,0000
BogoMIPS : 5399,81
Drapeaux : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc ar
t arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 s
se4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb pti fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed ad
x smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
Caches (somme de toutes) :
L1d : 128 KiB (4 instances)
L1i : 128 KiB (4 instances)
L2 : 1 MiB (4 instances)
L3 : 6 MiB (1 instance)
NUMA :
Nœud(s) NUMA : 1
Nœud NUMA 0 de processeur(s) : 0-3
Vulnérabilités :
Gather data sampling : Vulnerable: No microcode
Indirect target selection : Not affected
Itlb multihit : KVM: Mitigation: VMX unsupported
L1tf : Mitigation; PTE Inversion
Mds : Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Meltdown : Mitigation; PTI
Mmio stale data : Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Reg file data sampling : Not affected
Retbleed : Vulnerable
Spec rstack overflow : Not affected
Spec store bypass : Vulnerable
Spectre v1 : Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2 : Mitigation; Retpolines; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Srbds : Vulnerable: No microcode
Tsa : Not affected
Tsx async abort : Not affectedPour "journalctl -b 0 | grep -i mitigation" je vois ça :
Caché :
Code TEXT :
[gerard@localhost ~]$ journalctl -b 0 | grep -i mitigation
Hint: You are currently not seeing messages from other users and the system.
Users in groups 'adm', 'systemd-journal', 'wheel' can see all messages.
Pass -q to turn off this notice.Bon je n'en sais pas plus
gerard-ll Membre non connecté
-
- Voir le profil du membre gerard-ll
- Inscrit le : 09/12/2011
- Groupes :
Code TEXT :
[root@localhost gerard]# journalctl -b 0 | grep -i mitigation nov. 16 11:39:47 localhost kernel: Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization nov. 16 11:39:47 localhost kernel: Spectre V2 : Mitigation: Retpolines nov. 16 11:39:47 localhost kernel: RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!
gerard-ll Membre non connecté
-
- Voir le profil du membre gerard-ll
- Inscrit le : 09/12/2011
- Groupes :
gerard-ll Membre non connecté
-
- Voir le profil du membre gerard-ll
- Inscrit le : 09/12/2011
- Groupes :
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Est ce que la ligne de commande grub aurait une instruction de ne pas charger de microcode cpu ?
cat /proc/cmdline permet de voir ce qui a été lancé par grub.
Je pense qu' il est nécessaire d' activer le dépot nonfree ( les microcodes semblant se trouver dans un paquet dans ce dépot).
edit: je dirais que c' est ce paquet là. microcode-0.20250812-3.mga9.nonfree
Édité par nic80 Le 16/11/2025 à 14h25
gerard-ll Membre non connecté
-
- Voir le profil du membre gerard-ll
- Inscrit le : 09/12/2011
- Groupes :
Code TEXT :
[gerard@localhost ~]$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.6.105-desktop-1.mga9 root=UUID=41be212d-3163-41e9-9af4-95ec52ccdbc6 ro splash quiet noiswmd resume=UUID=5cdfe8e6-4d1e-4cf7-bb8c-f196d14aeb5d audit=0 vga=791
gerard-ll Membre non connecté
-
- Voir le profil du membre gerard-ll
- Inscrit le : 09/12/2011
- Groupes :
Code TEXT :
[ 0.019818] [Firmware Bug]: TXC DEADLINE disabled due to Errata: please update microcode to version 0xb2 (or later) [ 0.077711] x86/cpu: VMX (outside TXT) disabled by BIOS
gerard-ll Membre non connecté
-
- Voir le profil du membre gerard-ll
- Inscrit le : 09/12/2011
- Groupes :
Ce n'est pas mon PC principal c'est juste pour mes sauvegardes et quelques tests.
Merci à tous de vous êtes penché sur mon souci
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Attention ici avoir le noyau à jour ne protège pas contre ces vulnérabilités qui sont liées au matériel ( ici le cpu ( et ce que ce soit Intel ou AMD); la course à qui calculera le plus vite est principalement la cause de tout ceci ( du coup on les ralenti après coup
). Ici en utilisant le paquet de microcode, le nouveau microcode est chargé en mémoire à chaque démarrage du pc ( j' ai utilisé l' option dis_ucode_ldr dans grub pour empêcher ceci pour test et le lscpu faisait encore plus "peur"), et bien entendu le warning est apparu...Du coup ici, soit le paquet n' est pas installé et donc le nouveau microcode n' est pas chargé entrainant le warning.
Attention, comme indiqué précédemment, c' est un ensemble de composants qui permet de se protéger contre ces vulnérabilités ( noyau, bios, microcode). Un Bios trop ancien par exemple peut entrainer un plantage au niveau grub/noyau (écran noir) dans le chargement du microcode de rechange.
D' ailleurs si le dépot non free n' est pas activé, on peut supposer que le pilote graphique nouveau est utilisé à la place du pilote Nvidia ( ce qui ne doit pas poser de problème à Gnome, mais plus à Plasma).
edit: est ce que cela voudrait dire que si on ne veut pas du pilote propriétaire ( et donc pas le dépot non free), on aurait une distribution vulnérable ?
Édité par nic80 Le 16/11/2025 à 15h46
gerard-ll Membre non connecté
-
- Voir le profil du membre gerard-ll
- Inscrit le : 09/12/2011
- Groupes :
nic80 :D' ailleurs si le dépot non free n' est pas activé, on peut supposer que le pilote graphique nouveau est utilisé à la place du pilote Nvidia ( ce qui ne doit pas poser de problème à Gnome, mais plus à Plasma).
edit: est ce que cela voudrait dire que si on ne veut pas du pilote propriétaire ( et donc pas le dépot non free), on aurait une distribution vulnérable ?
Ah oui tiens merci de l'info!
J'va rallumer mon PC pour voir si c'est "Nouveau" qui est utilisé.
C'est vrai que sur l'autre c'était une carte AMD ATI Radeon HD 4850.
Et comme j'ai simplement transvasé le disque dur dans ce PC il se peut que ce soit Nouveau du coup.
Je regarde...
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie