Tutti gli articoli di Elena Metelli

FreeBSD finalmente patchato per Spectre / Meltdown

Facebooktwittergoogle_plusredditlinkedin

Seppur con qualche settimana di ritardo, anche su FreeBSD arrivano le mitigation per Spectre e Meltdown.

Sono presenti le patch Meltdown per le CPU Intel tramite un’implementazione KPTI (Kernel Page Table Isolation) simile a quella utilizzata dalle altre distro Linux. È presente inoltre l’ottimizzazione PCID (Process Context Identifier) per le CPU Intel Westmere e successive.

Per quanto riguarda Spectre, viene applicata la IBRS (Indirect Branch Restricted Speculation) per arginare i problemi causati dalla Variante 2 di questa falla.

Le patch sono disponibili sui repository SVN e sono stati assegnati alla versione 11 (stable). Al momento una release di FreeBSD che includa direttamente le patch non esiste.

La versione 11.2 di FreeBSD è schedulata per il rilascio il 27 giugno, anche se a questo punto non si escludono variazioni sulla data di pubblicazione.

Linux su NintendoSwitch grazie ad un exploit

Facebooktwittergoogle_plusredditlinkedin

Nessun hardware è completamente a prova di hack e Nintendo è una di quelle compagnie che investe parecchio per riuscire a produrre dispositivi con meno exploit possibili.

Eppure…

Nei giorni scorsi l’hacking team fail0verflow ha condiviso tramite Twitter un’immagine che mostra Debian installato su un Nintendo Switch:

Il gruppo è conosciuto per aver pubblicato in passato altri hack per svariate console come Wii e PS4. Il team ha anche pubblicato un video in cui Nintendo Switch esegue uno scroller customizzato.

Secondo fail0verflow ci sarebbe una falla nella ROM del chip Nvidia Tegra X1 che contiene istruzioni riguardanti il boot.

Questo tipo di exploit non è risolvibile da alcun tipo di aggiornamento software dato che la ROM viene salvata sul chip al momento della produzione e non più alterabile successivamente.

L’unica soluzione è che Nvidia scovi e sistemi il bug producendo nuovi chip con la ROM patchata.

Al momento fail0verflow non ha rilasciato alcuna informazione tecnica sull’exploit ma conferma che nessuna modifica hardware è stata eseguita per bypassare il boot della ROM. Dalla foto si vede semplicemente hardware extra collegato sul lato destro della console, dove dovrebbe esserci uno dei Joy-Con.

Visto che Linux su desktop stenta ad arrivare, possiamo sperare di vederlo più spesso sulle console?

Fedora: consumo di energia ridotto del 30%

Facebooktwittergoogle_plusredditlinkedin

Negli ultimi mesi Hans de Goede (RedHat) ha lavorato estensivamente sul miglioramento delle performance del consumo energetico sui portatili che utilizzano Fedora.

Tra le aree di interesse ci sono:

  • Panel Self Refresh, feature di Intel disponibile da diversi anni ma quasi mai abilitata di default a causa di svariati problemi rilevati su alcuni hardware;
  • SATA Power Management, feature presente in Fedora Rawhide per la quale sono stati rilevati casi di corruzione disco;
  • auto-supend feature solitamente abilitata su più periferiche.

Lo scorso week end, al FOSDEM 2018, De Goede ha tenuto una presentazione in cui ha illustrato i progressi fatti.

I suoi test sono stati eseguiti su un ThinkPad T440s, ed abilitando tutte le funzionalità sopracitate, ha rilevato un risparmio della batteria di circa il 30% (da 7.9W a 5.6W)!

Ma dove è stata recuperata tutta questa energia?

  • Tramite l’abilitazione dell’auto-suspend di tutti i device USB, il risparmio arriva intorno ai 0.4W. Per fare ciò sono necessarie due patch del kernel: la prima prevede autosuspend di default utilizzando Kconfig e la seconda disabilita auto-suspend stesso per le periferiche non adatte a questo utilizzo, ad esempio Realtek (audio) e Atheros (network)… Del resto avere una NIC che va in autosuspend… Non è cosa;
  • Tramite lo spegnimento di HDA (Intel High Definition Audio), mantenendo la periferica in stato idle vengono aggiunti altri 0.4W al conto totale;
  • Tramite l’abilitazione SATA ALPM (Aggressive Link Power Management) i consumi vengono ridotti di 1-1.5W! Anche se in questo caso la corruzione del disco diventa un tema importante;
  • Tramite l’abilitazione dek meccanismo PSR vengono recuperati 0.5W.

De Goede ha ricevuto un centinaio di report da utenti che hanno testato questa configurazione ma i risultati non sono particolarmente incoraggianti, i problemi sulle periferiche restano moltissimi.

Se siete interessati a contribuire, potete seguire le istruzioni di Hans in questo post e poi inviare una mail di report.

In ogni caso, da fedorista, credo che per il momento mi “accontenterò” delle 12 ore di autonomia garantite dal mio Thinkpad X260 e da Fedora 26!

Systemd vuole dominare il mondo: Pop!_OS passa a Systemd-Boot!

Facebooktwittergoogle_plusredditlinkedin

Pop!_OS è un sistema operativo basato su Ubuntu lanciato nell’ottobre del 2017 e sviluppato da System 76, azienda che progetta e vende desktop e laptop totalmente compatibili con Linux.

Ad ogni annuncio relativo a questo sistema appare chiaro come Pop!_OS abbia ambizioni ben più alte rispetto ad una semplice distribuzione respin, basti osservare la quantità di cambiamenti introdotti, tra cui:

  • Distinst, l’installer della distro (con il supporto di Elementary);
  • Encryption del disco di default;
  • Miglioramento del supporto HiDPI.

A tutto questo ieri ha fatto seguito sul blog di System 76 l’annuncio:

The goal is to reduce the amount of time we get to the desktop by optimizing the boot sequence from the moment you turn on your computer. Instead of using grub to load the kernel and the initramfs on UEFI systems, we’re going to be using systemd-boot, the modern incarnation of gummiboot.

L’obbiettivo è quello di ridurre i tempi di avvio ottimizzando la sequenza di boot dal momento stesso in cui si accende il computer. Invece di utilizzare GRUB per caricare kernel ed initramfs sui sistemi UEFI, utilizzeremo systemd-boot, la moderna incarnazione di gummiboot.

La sfida sta nel riuscire a copiare kernel e initramfs nella ESP (EFI System Partition) dove systemd-boot si aspetta di trovarli in modo da poter fare boot, cosa che attualmente i kernel di Ubuntu non offrono.

Per compensare questa mancanza verrà utilizzato kernelstub, tool che permette l’avvio dal bootloader integrato in EFI.

Il tutto è ancora in fase sperimentale, non si hanno date o release in cui questa feature verrà proposta di default.

Una cosa sembrerebbe certa però: systemd is taking over…

Perché RedHat ha acquisito CoreOS?

Facebooktwittergoogle_plusredditlinkedin

La settimana scorsa RedHat aveva annunciato l’acquisizione di CoreOS per 250 milioni di dollari, decisione che aveva lasciato perplesse molte persone visto che (solitamente), l’azienda acquisisce le società per inglobare nella propria offerta nuove tecnologie.

CoreOS fornisce un sistema operativo ottimizzato per i container e Tectonic, una soluzione per gestire cluster Kubernetes.

Allora perché questa acquisizione? Per togliere di mezzo un concorrente? Non sembrerebbe. RedHat con questa mossa ha di fatto “assunto” 130 persone in più, persone che si aggiungeranno al team di professionisti in azienda per fornire servizi sempre più completi a propri clienti enterprise.

Stavolta la “battaglia” non è contro i grandi rivali di sempre, IBM ed Oracle, il concorrente a conti fatti in questo caso è la Docker Inc., pertanto i prodotti a confronto sono OpenShift Enterprise e Docker Enterprise Edition. Si può concludere quindi come CoreOS molto probabilmente si posizionerà proprio a sostegno di OpenShift.

Paul Cormier, presidente della divisione Products and Technologies di RedHat conclude:

We believe this acquisition cements Red Hat as a cornerstone of hybrid cloud and modern app deployments.

Crediamo che questa acquisizione consolidi RedHat come pilastro del cloud ibrido e dello sviluppo delle moderne applicazioni.

L’aggiunta delle tecnologie di CoreOS alla vasta esperienza RedHat con Kubernetes, nel contesto dell’IT ibrido, la rende forse l’infrastruttura enterprise più credibile e completa oggigiorno.

Con l’intero ecosistema dei container che va maturando, il dominio RedHat dovrebbe solo diventare più forte.

 

Niente Wayland di default su Ubuntu 18.04 LTS

Facebooktwittergoogle_plusredditlinkedin

Ubuntu fa un passo indietro: Bionic Beaver (18.04 LTS) non utilizzerà Wayland di default, si tornerà a X.Org Server.

Ovviamente Wayland non sparirà e sarà possibile selezionarlo nella schermata di login GDM.

Canonical ha motivato la scelta sostenendo che attualmente X.Org offre un miglior supporto per la condivisione schermo (per Skype e Google Hangouts, ad esempio) e remote desktop (VNC, RPD) e che GNOME gestisce meglio i crash sotto X.Org invece che Wayland. Inoltre (anche se non sembrerebbe una delle principali motivazioni) anche alcuni driver NVIDIA per Linux funzionano meglio che su Wayland.

Il team di Ubuntu sta ancora lavorando sul miglioramento delle prestazioni e sulle nuove estensioni, come PipeWire, ed Aprile sembra davvero troppo vicino per includere tutto. Bionic Beaver comunque include degli aggiornamenti importanti tra i quali il kernel 4.15, Mesa 18.0 e GCC 7.

Ubuntu 18.04 utilizzerà la versione 1.19 di X.Org; la versione 1.20 (già rimandata) non sembra verrà rilasciata a breve e non potrà essere inclusa in questa release.

Kernel 4.15: il primo completamente patchato contro Meltdown e Spectre

Facebooktwittergoogle_plusredditlinkedin

After a release cycle that was unusual in so many (bad) ways, this last week was really pleasant. No last-minute panics, just small fixes for various issues. I never got a feeling that I’d need to extend things by yet another week, and 4.15 looks fine to me.

Dopo un ciclo di rilascio inusuale sotto molti (brutti) aspetti, la scorsa settimana è stata molto piacevole. Niente problemi dell’ultimo minuto, solo piccoli fix per alcuni problemi. Non ho avuto la sensazione di dover attendere un’altra settimana, il 4.15 mi sembra a posto.

Con questo messaggio Linus Torvalds annuncia finalmente il rilascio del kernel 4.15, una release che ha richiesto un lungo ciclo di sviluppo, tanto da arrivare alla RC9, cosa che non succedeva dal 2011.

Le difficoltà erano ovviamente dovute al caos Meldown/Spectre, bug hardware che affligge tutte le CPU degli ultimi 20 anni circa. Il kernel 4.15 inaugura una nuova era di kernel che saranno completamente patchati contro i due bug… per chi utilizza CPU x86 e PowerPC. Bene, ma non benissimo diciamo.

Torvalds ribadisce comunque che “non è finita”: mancano ancora i fix per ARM e per la variante 1 di Spectre.

Oltre alle patch per queste vulnerabilità, questa release introduce diverse novità:

  • supporto ad architetture RISC-V;
  • supporto ad AMD SEV (Secure Encripted Virtualization)
  • supporto UNIP (User-Mode Instruction Prevention), per CPU Intel
  • supporto video migliorato e nuove feature per i driver open-source AMDGPU
  • miglioramento del risparmio energetico con l’utilizzo del SATA link power management

Il kernel 4.15 è già disponibile al download, mentre sarà necessario ancora qualche tempo (come sempre) prima che venga rilasciato nei repository ufficiali delle varie distibuzioni.

Patch Meltdown/Spectre: tuning da rifare sui server

Facebooktwittergoogle_plusredditlinkedin

Si torna a parlare di Meltdown e Spectre che nelle ultime settimane hanno travolto il mondo dell’IT e dai quali quasi nessuno è riuscito a salvarsi.

Le maggiori distro Linux hanno già rilasciato una serie di patch per arginare il problema ma, come c’era da aspettarsi, le performance del sistemano calano non indifferentemente.

Questo discorso si applica poco alle workstation mentre lato server la situazione è certamente più critica.

Ma di quanto vengono realmente impattate le performance? Dopo i test di Phoronix di cui abbiamo parlato qui (svolti su CentOS, Ubuntu, Debian e Clear Linux) risponde anche RedHat che ha eseguito dei benchmark su RHEL 7/6/5 dopo aver applicato le patch:

  • Alto impatto: cache memoria, buffer I/O e carico sui database OLTP impattati del 8-19%;
  • Medio impatto: Analytics sui database e macchine virtuali Java subiscono un calo del 3-7%;
  • Basso impatto: HPC (High Performance Computing) e carichi di lavoro elevati sulla CPU sono impattati del 2-5%, molti dei job vengono eseguiti nello user space;
  • Impatto minimo: le tecnologie che bypassano il kernel in favore dell’accesso diretto allo user space subiscono un impatto inferiore al 2%.

Questi cali di performance valgono sia per le installazioni bare metal che per le applicazioni containerizzate (visto che sono trattate come processi Linux generici) anche se quest’ultime sicuramente sono più impattate a causa della frequenza più elevata di operazioni user-to-kernel.

RedHat ha anche rilasciato una serie di indicazioni sui fix applicati sui propri sistemi per consentire agli utenti un tuning post-patch più rapido.

La situazione resta comunque grave su innumerevoli macchine ed appliance che utilizzano distribuzioni datate e non patchabili, inclusi tutti i vari dispositivi IoT… che comunque non se la sono mai passata particolarmente bene!