Saturday’sTalks: nuova opzione nel Kernel Linux per disabilitare Spectre. Molto rumore per nulla?

3

Delle vulnerabilità Spectre e Meldown, relative alle CPU Intel, ne stiamo parlando ormai da più di un anno. Scenari apocalittici e momenti di panico hanno attraversato la testa di ciascuno di noi, ma ora che i tempi sono più tranquilli è possibile fare un bilancio effettivo.

Quanti attacchi di vasta scala sono stati riconducibili a queste falle? Apparentemente zero, o almeno noi di MMUL non ne siamo al corrente.

Rimane però il fatto che le mitigazioni a questi problemi sono state da subito oggetto di dibattito: in quanto non rimovibile dalla CPU stessa, il problema è stato gestito via software, eliminando la possibilità di utilizzare la funzionalità che scatena il problema. Funzionalità che però garantiva una maggiore velocità di esecuzione dei processi. Risultato? Un generale, e naturale, rallentamento.

Ma se il problema di fatto sembra non sfruttabile o facilmente arginabile con limitazioni di altro tipo, ha ancora senso mantenere le mitigazioni e scadere nelle performance?

La risposta pare sia no, o quantomeno, è nata da subito l’esigenza di rendere l’abilitazione e disabilitazione delle mitigazioni controllabile dall’utente. Come spiega Catalin Cimpanu di ZDNet, dal kernel 4.15 è possibile disabilitare le mitigazioni mediante l’aggiunta del parametro nospectre_v2 alla command line di esecuzione del Kernel. Dal Kernel 4.17 è addirittura possibile disabilitare tutte le mitigazioni relative a Spectre V4 con l’opzione nospec_store_bypass_disable mentre dal 4.19 l’opzione nospectre_v1 fa la stessa cosa per la versione relativa.

L’articolo continua descrivendo altre nuove modalità di disabilitazione come l’aggiunta di un control bit denominato PR_SPEC_DISABLE_NOEXEC che consentirà ai processi figlio di non subire le limitazioni imposte al processo padre.

Ora, l’intera vicenda porta a domandarsi: che sia stato fatto molto rumore per nulla? O è sempre bene andarci cauti e lasciare tutte le mitigazioni al posto onde evitare spiacevoli sorprese? La scelta come sempre (e per fortuna, aggiungerei) è lasciata a chi i sistemi li deve gestire.

Dura la vita del sistemista, ragazzi.

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

3 risposte a “Saturday’sTalks: nuova opzione nel Kernel Linux per disabilitare Spectre. Molto rumore per nulla?”

  1. Avatar Fenix
    Fenix

    Ciao. Ottimo articolo. È possibile avere un mini tutorial che spieghi la procedura completa per disabilitare queste protezioni(intendo i comandi da eseguire, file da modificare, ecc) grazie

  2. Avatar Raoul Scarazzini
    Raoul Scarazzini

    Dipendentemente dalla versione di Kernel che utilizzi, la modalità per abilitare o meno queste opzioni è molto semplice:
    1) Apri il file /etc/default/grub;
    2) Modifichi la variabile GRUB_CMDLINE_LINUX_DEFAULT aggiungendo le opzioni che ti interessano, ad esempio:

    GRUB_CMDLINE_LINUX_DEFAULT="nospectre_v1 nospectre_v2 nospec_store_bypass_disable spectre_v2=off"

    3) Aggiorni la configurazione di grub con:

    # update-grub2
    Sourcing file `/etc/default/grub'
    Sourcing file `/etc/default/grub.d/50_linuxmint.cfg'
    Generating grub configuration file ...
    Found linux image: /boot/vmlinuz-4.15.0-45-generic
    Found initrd image: /boot/initrd.img-4.15.0-45-generic
    Found linux image: /boot/vmlinuz-4.15.0-44-generic
    Found initrd image: /boot/initrd.img-4.15.0-44-generic
    done

    La procedura qui sopra è stata fatta su Ubuntu, ma non è molto differente in Red Hat e affini…

  3. Avatar JustATiredMan
    JustATiredMan

    Dipende dall’utilizzo.
    Se la tue macchine sono in in una rete locale con pochi collegamenti e controllati, verso internet, allora puoi anche prenderti il rischio di disabilitare le mitigazioni.
    Per tutto il resto il rischio è troppo elevato.
    E quello che mi disturba è che Intel stessa stà prendendo sottogamba questa storia, ritardando una soluzione “hardware” per questi problemi.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *