Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
conraid ha scritto:Da una breve ricerca sembra che quella sia un'opzione introdotta da gentoo tramite patch, e altre distribuzioni hanno applicato. Debian e RedHat no mi par di capire. Slackware no.
Non ho capito però se la patch sia per "immagini multiple" o proprio per la voce del config in sé.
Esatto, c'è una patch per grub che fa sì che se in '/boot' viene trovata un'immagine del microcode con uno di questi nomi - 'intel-uc.img intel-ucode.img amd-uc.img amd-ucode.img early_ucode.cpio microcode.cpio' - questa viene aggiunta nella sezione initrd prima di quella del kernel. In pratica dopo un 'grub-mkconfig ti ritrovi nel grub.cfg una sezione initrd di questo tipo:
In questo caso non c'è bisogno di includere il microcode nell'initramfs e viene fatto tutto in automatico senza dover aggiungere opzioni in /etc/default/grub.
io intanto confermo che il nuovo aggiornamento e' risultato efficace per la maggior parte delle mie macchine con processori intel (il tool che fa il check ora sembra essere contento)
* CPU vulnerability to the speculative execution attack variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
* Vulnerable to Variant 3a: YES
* Vulnerable to Variant 4: YES
poi dopo dice "Mitigated according to the /sys interface" anche se alcuni opzioni la cpu non le supporta nemmeno.
Senza microcode è stesso risultato, cambia solamente la riga dove mostra il numero di ucode.
# sh spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.38
Checking for vulnerabilities on current system
Kernel is Linux 4.17.14-cf #3 SMP Thu Aug 9 14:22:57 CEST 2018 x86_64
CPU is Intel(R) Core(TM)2 Duo CPU T7100 @ 1.80GHz
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
* Speculative Store Bypass Disable (SSBD)
* CPU indicates SSBD 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 explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
* CPU microcode is known to cause stability problems: NO (model 0xf family 0x6 stepping 0xd ucode 0xa4 cpuid 0x6fd)
* CPU vulnerability to the speculative execution attack variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
* Vulnerable to Variant 3a: YES
* Vulnerable to Variant 4: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec: YES (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
* Kernel has mask_nospec64 (arm64): NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: NO
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Full retpoline is mitigating the vulnerability)
IBPB is considered as a good addition to retpoline for Variant 2 mitigation, but your CPU microcode doesn't support it
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Reduced performance impact of PTI: NO (PCID/INVPCID not supported, performance impact of PTI will be significant)
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)
CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability: NO
> STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability)
CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface: NO (Vulnerable)
* Kernel supports speculation store bypass: YES (found in /proc/self/status)
> STATUS: VULNERABLE (Your CPU doesn't support SSBD)
Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer
confermo, qui sembra essere tutto a posto.
quello che mi sembra aver capito non e' coperto e' l'hypertreading dei processori intel, ma li' finche' non arriva un ulteriore microcode non ci possiamo fare molto (a parte disabilitarlo dal bios o dalle features del kernel, quando si compila).
ponce ha scritto:quello che mi sembra aver capito non e' coperto e' l'hypertreading dei processori intel, ma li' finche' non arriva un ulteriore microcode non ci possiamo fare molto (a parte disabilitarlo dal bios o dalle features del kernel, quando si compila).
Questa faccenda del 'SMT' mi pare però legata solo alla virtualizzazione - vedi sezione: "Attack Senarios: 2.Malicious guest in a virtual machine".
È corretto?
Perché se così fosse, a mali estremi si disabilita al volo l'hypertreading prima di avviare il guest "non sicuro", oppure lo si confina su uno o più core (che però non ho capito come si fa).
P.s.
Mi sa è roba piuttosto tecnica per uno come me.