Archivi categoria: Kernel

Kernel Linux: arrivano le prime patch per Spectre V4

Facebooktwittergoogle_plusredditlinkedin

Risale già a qualche settimana fa la scoperta di una nuova falla della serie Meltdown/Spectre da parte dei team di Microsoft e Google ed arrivano anche le prime mitigation nel kernel Linux.

La versione 4.17 rilasciata negli scorsi giorni infatti include anche diverse patch per arginare i problemi che hanno introdotto Spectre e Meltdown:

  • Fix per alcune CPU x86 di produzione cinese;
  • Fix per Spectre per IBM s390;
  • Fix per Spectre V4 per Power7, Power8 e Power9;
  • Fix per Spectre V4 su CPU Intel.

Per il kernel 4.18 sono previste ulteriori patch per mitigare i problemi derivanti dallo Speculative Store Bypass stavolta sulle CPU di AMD che utilizzeranno le direttive SPEC_CTRL / VIRT_SPEC MSR che verranno fornite in futuro dal produttore insieme agli aggiornamenti firmware.

Al momento, questa sembrerebbe anche l’unica mitigation inclusa nel kernel 4.18 che fa riferimento all’architettura x86. Oltre a questa, infatti, sono previsti aggiustamenti anche per Spectre V4 su ARM64 e, finalmente, per Spectre V1/V2 su ARM 32-bit.

Vedremo mai la fine di questa neverending “apply-fix-and-reboot-you-machine” story?

Il prossimo Kernel Linux sarà il 5.0, o forse no. Parola di Torvalds!

Facebooktwittergoogle_plusredditlinkedin

Non è una grande novità il fatto che a Linus Torvalds, creatore e principale sviluppatore del Kernel Linux, i numeri di versione interessino veramente poco.

Infatti in seguito all’annuncio della release candidate del Kernel 4.17 Linus ha fatto intendere che la prossima release potrebbe essere la 5.0. Anche se, di fondo:

The version numbers are meaningless, which should mean that they don’t even follow silly numerological rules

I numeri di versione sono insignificanti, il che dovrebbe significare che non seguono tediose regole numeriche

Il pensiero si riconduce ad un ragionamento relativo all’attuale versione, la quale secondo il signor Linux non brilla per essere una release particolarmente grossa (letteralmente “not shaping up to be a particularly big release“). Come peraltro abbiamo discusso recentemente la stessa versione 4.17 poteva essere considerata una sorta di milestone per via di tutte le righe di codice rimosse (una cosa inedita per il progetto kernel che non aveva mai visto in nessuna release un numero di aggiunte minore rispetto alle rimozioni), ma ha seguito invece la consueta numerazione.

Tutto questo porta alla conclusione:

v5.0 will happen some day. And it should be meaningless. You have been warned.

La versione 5.0 uscirà prima o poi. E dovrebbe essere insignificante. Siete stati avvisati.

Quindi: esce o non esce? Non è dato di saperlo. Quello che emerge con certezza è che il conteggio delle release in Linux continuerà a non portare con se aggiornamenti critici o funzionalità aggiuntive critiche, sarà invece, piaccia o no, decisione unica e insindacabile del suo creatore.

È o non è il nostro dittatore benevolo preferito?

E’ ufficiale: Microsoft ha rilasciato una distribuzione Linux basata su un Kernel personalizzato

Facebooktwittergoogle_plusredditlinkedin

Con il filone “Microsoft ama Linux” ci siamo abituati a vedere comportamenti sempre più controcorrente rispetto alla storia di Microsoft.

Dal rilascio dei propri software in open source, alla collaborazione con Canonical per il rilascio di uno strato Linux in Windows, fino all’inclusione (e promozione) di distribuzioni Linux officiali nello store Azure, pensavamo di aver fatto il callo a questa nuova tendenza.

Ma proprio in un momento di serenità, ecco l’esplosione: Microsoft rilascia una distribuzione Linux.

Si, potete rileggere la frase, c’è proprio scritto quello!

Un paio di giorni fa, infatti, Microsoft ha annunciato una nuova tecnologia chiamata Azure Sphere e pensata per avere un sistema estremamente sicuro per dispositivi IoT, giocattoli connessi ed altri gadget.

E, dovendo fornire un sistema sicuro, da cosa partire? Da Windows? No, molto meglio avvalersi di un kernel Linux (altamente modificabile) e customizzarlo per le loro necessità.

Ed è quello che è stato fatto, scritto nella pietra o, se vogliamo, nel post ufficiale sul blog di Microsoft:

Azure Sphere will bring to these new chips a new customized operating system built for IoT security. This OS incorporates a custom Linux kernel that has been optimized for an IoT environment and reworked with security innovations pioneered in Windows to create a highly secured software environment.

Azure Sphere porterà a questi nuovi chip un nuovo e personalizzato sistema operativo costruito per la sicurezza dell’IoT. Questo OS incorpora un kernel Linux personalizzato che è stato ottimizzato per gli ambienti IoT e rilavorato con innovazioni di sicurezza già utilizzate in Windows per creare un ambiente software altamente sicuro

Quindi si, c’è Linux, ma l’annuncio sembra non dargli troppo credito, sottolineando che hanno dovuto lavorare sul kernel parecchio per renderlo utilizzabile su dispositivi IoT e, soprattutto, “sicuro come Windows” (…).

Il progetto Azure Sphere è molto più ampio, in realtà, e comprende lo sviluppo di chip ad-hoc, l’OS e servizi cloud a compendio di entrambi, ma il fatto che per la parte centrale di tutto (di fatto, è l’OS che fa parlare l’hardware con il cloud) è stato deciso di non usare un sistema Windows -seppur embedded- è sicuramente una svolta sensibile.

Al momento ne nell’articolo di Microsoft, ne nel loro repository GitHub ufficiale è presente il sorgente di questo kernel, stando alla GPLv2 dovranno rilasciarlo per forza… magari stanno aspettando solo la mail di Garrett.

Cosa ne pensate? E’ l’inizio della fine?

Ubuntu 18.04 LTS e Canonical LivePatch: aggiornamenti kernel senza reboot

Facebooktwittergoogle_plusredditlinkedin

Mancano poco meno di due settimane, il 26 aprile, al rilascio di Ubuntu 18.04 LTS (Bionic Beaver) che includerà:

  • Linux Kernel 4.15
  • systemd-resolved sarà il nuovo resolver DNS di default;
  • SSSD aggiornato alla versione 1.16x;
  • X.Org Server come display server di default invece di Wayland;
  • Patch per Meltdown e Spectre;
  • Deprecato Python 2 in favore di Python 3 (versione 3.6).

Una delle novità più interessanti di questa release pero è Canonical LivePatch, un servizio che permette di aggiornare il kernel senza necessità di riavviare il sistema.

In realtà questo servizio era già presente nella scorsa release, la 16.04, ma per questa volta Canonical si è impegnata a rendere questo tool di più facile utilizzo: ora si integra direttamente nella tab Updates, nella sezione dedicata alle impostazioni degli aggiornamenti.

Unici due nei forse:

  • È necessario avere un account Ubuntu SSO;
  • Limitato a 3 sistemi; oltre diventa necessario acquistare una sottoscrizione ad Ubuntu Advantage.

LivePatch è abilitato di default e per ricevere gli aggiornamenti basta semplicemente loggarsi al proprio account. Gli update/patch vengono applicati utilizzando pacchetti Snap.

Che qualcuno poi finisca per usarlo… in produzione?

Linux Kernel 4.17: 500.000 righe di codice in meno

Facebooktwittergoogle_plusredditlinkedin

Solitamente il rilascio di un nuovo Kernel prevede l’aggiunta di parecchio codice ma per la versione 4.17 pare sia arrivato il tempo di pulizie di primavera.

Arnd Bergman, sviluppatore del Kernel Linux di vecchia data, ha proposto di rimuovere il supporto per alcune vecchie (ed anche abbastanza ignote) architetture per poi procedere anche con la rimozione dei device driver relativi.

In the end, it seems that while the eight architectures are extremely different, they all suffered the same fate: There was one company in charge of an SoC line, a CPU microarchitecture and a software ecosystem, which was more costly than licensing newer off-the-shelf CPU cores from a third party (typically ARM, MIPS, or RISC-V). It seems that all the SoC product lines are still around, but have not used the custom CPU architectures for several years at this point.

Alla fine, sembra che nonostante le otto architetture siano estremamente diverse, tutte hanno subito lo stesso destino: una società si occupava della linea SoC (system-on-a-chip), cosa che risultava più costosa che affidare la produzione a terze parti (in genere ARM, MIPS o RISC-V). Sembra che tutti questi prodotti SoC siano ancora in circolazione ma che non stiano più utilizzando le architetture custom ormai da anni.

Le architetture a cui Bergman si riferisce sono:

  • Blackfin
  • Metag
  • Tile
  • MN10300
  • FRV
  • CRIS
  • M32R
  • Score

Ci sarebbero altre due architetture che potrebbero rischiare la rimozione a causa delle release GCC scadute: Unicore21 ed Hexagon. Gli sviluppatori hanno però espresso la volontà di risolvere il problema quanto prima.

Al netto di tutti questi cambiamenti, il Kernel Linux risulterà più leggero di circa 500.000 righe di codice.

Righe di codice per versione

Pare si scenderà di nuovo sotto le 20 milioni di righe!

Reptoline, la via di Google per sanare Spectre nei Kernel Linux già disponibile su RedHat

Facebooktwittergoogle_plusredditlinkedin

Le mitigation introdotte dalle varie distribuzioni per risolvere i problemi di sicurezza derivanti dalle falle Spectre e Meltdown non stanno funzionando a dovere. Nessuna novità in questo, ma tra problemi di performance o copertura limitata, ad esempio alcune esclusioni sui processori AMD64, l’impressione è che ci sia ancora molto da lavorare.

Con l’introduzione di Retpolines Google ha cercato di tagliare la testa al toro, facendo in modo che il Kernel abbia il totale controllo sulle esecuzioni speculative (vera causa del disastro) . L’approccio di Google oltre che essere più veloce è anche molto più generico rispetto alle specifiche patch del microcode di Intel, offre quindi una migliore copertura e vien da se che si possa definire una soluzione superiore.

Ebbene, alla luce di tutto questo, Red Hat ha messo a disposizione diverse analisi sulle performance nelle quali viene evidenziata la valenza dell’approccio Reptoline su diversi tipi di carico e ambito di utilizzo. In ogni caso l’approccio retpoline dimezza essenzialmente l’impatto sulle performance.

Come testare tutto questo? Anche in questo caso Red Hat ha reso disponibile una dettagliata pagina di istruzioni che descrive dalla A alla Z cosa è necessario fare, quali CVE sono coinvolti e, addirittura, come automatizzare l’operatività delle patch mediante profili tuned.

Non resta che mettersi al lavoro!

Critiche a Canonical per la scelta del Kernel 4.15 (non LTS) in Ubuntu 18.04 (LTS)

Facebooktwittergoogle_plusredditlinkedin

null

Considerando che l’uscita di Ubuntu 18.04 LTS ( Long Term Support ) si sta avvicinando, parliamo oggi di un importante novità oltre a quelle già citate: la versione del Kernel. Canonical ha infatti confermato che il cuore della nuova distribuzione di Ubuntu sarà il Kernel 4.15 e non, come detto inizialmente, la versione 4.14.

L’annuncio di questa notizia ha suscitato qualche critica, infatti l’adozione di un kernel non longterm maintenance (qui una panoramica delle Kernel release disponibili) in una distribuzione LTS non è certamente una scelta usuale. La discrepanza tra il kernel predefinito e la distribuzione sarà nel lungo termine notevole: Ubuntu 18.04 LTS rispetterà il supporto attivo per 5 anni, mentre il kernel riceverà gli aggiornamenti di sicurezza per un tempo inferiore ai 2 anni.

Il motivo di questa scelta è relativo alle tempistiche, in quanto deve essere stabilito quale sarà la versione del prossimo kernel LTS disponibile, e sicuramente non sarà disponibile prima del rilascio di tale distribuzione.

Ma dall’altro lato della medaglia, ecco quali sono stati i principali motivi della scelta:

  • Le Patch per Spectre e Meltdown sono già incluse
  • Supporto per i processori AMD Raven Ridge
  • Rilevazione delle temperature sui processori Ryzen e sulle schede AMD Radeon
  • Supporto ai driver open source

Le date di uscita dovrebbero essere le seguenti:

  • 8 marzo: Prima versione beta
  • 5 aprile: Versione beta finale
  • 19 aprile: Rilascio finale
  • 26 aprile: Rilascio della prima versione stabile

A breve quindi si potranno effettuare i primi test sull versione beta. Restate sintonizzati!

Il kernel Linux ancora più chiuso per UEFI Secure Boot

Facebooktwittergoogle_plusredditlinkedin

Delle “feature” introdotte da UEFI Secure Boot e del suo supporto per i sistemi Linux ne abbiamo già parlato in maniera estesa.

Nell’ultimo anno è stato messo parecchio effort nel kernel per il supporto e la gestione dello stesso quando Linux è in esecuzione su un sistema con UEFI Secure Boot e, finalmente, pare si sia vicini ad un supporto ufficiale nel kernel streamline del nostro amato sistema operativo.

Essendo questo componente uno strato che si frappone tra il kernel ed i firmware dell’hardware (una specie di BIOS), alcuni comportamenti di Linux (come l’accesso ad aree della /dev per alterare i parametri firmware) causavano non pochi problemi, al punto -per un primo periodo- di rendere il sistema operativo del pinguino completamente incompatibile con sistemi provvisti di questa feature.

Grazie ad alcune limitazioni che il kernel può auto-indursi quando eseguito con su un sistema con UEFI Secure Boot attivo, come appunto la gestione degli accessi sulla /dev od il blocco dell’accesso ai parametri dei moduli del kernel, si è riusciti ad avere una serie di patch sufficientemente stabili da poterle includere direttamente nel kernel, come richiesto da David Howells sulla mailing list ufficiale.

Il grosso del lavoro di patching è stato supportato da Red Hat che ovviamente, vede il fatto che questo UEFI Secure Boot sia un requisito che a tendere diventerà fondamentale per il funzionamento di sistemi Windows, un possibile “attacco” alla sua diffusione. Se dovessimo metterci nei panni di un produttore hardware, che punta a massimizzare le vendite, decidere di non inserire questo componente rendendosi di fatto non compatibile con i sistemi Microsoft sarebbe una scelta poco lungimirante, e se questo causasse un lock-out da Linux per incompatibilità potrebbe essere un grosso problema per la “distro dal cappello rosso”, soprattutto in ambito enterprise.

Quindi, se tutto procede come previsto, verso il kernel 4.17/4.18 potremmo trovare il primo supporto integrato, nel frattempo non possiamo che seguire gli howto per la nostra distribuzione preferita (indipendentemente da essa, quello presente sulla wiki di Alt Linux risulta molto completo) ed armarci di tanta, tanta pazienza.