Tutti gli articoli di Marco Bonfiglio

Primi effetti su Wine per Oracle vs Google… E se Microsoft dedicesse qualcosa di simile?

Facebooktwittergoogle_plusredditlinkedin

Solo poco tempo fa, nel caso che vede Google contrapposta ad Oracle, abbiamo dato la notizia della decisione della corte di ritenere le API di Java sotto copyright, e il loro uso (con reimplementazione su altri sistemi) da parte di Google illegittimo; ora i primi effetti – la paura – di quella sentenza si cominciano a vedere.

Domenica 1 aprile (Pasqua), nella newsletter di Wine, è comparso un messaggio:

Does anyone know exactly how much this ruling affects Wine? Can we ask the SFC for a legal opinion?

Qualcuno sa esattamente in che misura questa sentenza impatta Wine? Possiamo interpellare l’SFC [Software Freedom Conservancy] per un parere legale?

La preoccupazione nasce dal fatto che Wine rende trasparenti le chiamate alle API per il programma (pensato in origine per funzionare nativamente sotto Windows) e si teme quindi che Microsoft possa intentare una causa simile a quanto fatto da Oracle contro Google. Con un precedente simile la vittoria sarebbe molto probabile.

Come potete ben capire l’analogia è molto forte, tanto che il comitato di gestione di Wine venerdì ha risposto di essere già in contatto con la Software Freedom Conservancy:

The committee has been in contact with Conservancy about this.

Il comitato ha già preso contatto con la Conservancy a questo riguardo.

La Software Freedom Conservancy è un’organizzazione nata nel 2006, che (come la Free Software Foundation) ha l’obbiettivo di promuovere e difendere l’esistenza di software gratuito, libero e open source (FLOSS – Free, Libre, Open Source Software). Conta ormai più di 40 progetti, compresi Git, BusyBox, Boost, Inkscape, QEMU e – appunto – Wine.

Quindi?

As of now, what we’ve learned is that it’s too early to know the effect the decision will have. It’s important to note that the decision isn’t binding on any other courts in the country, and it could be years for the appeals process to complete.

Per ora, quel che sappiamo è che è troppo presto per sapete che effetto avrà la sentenza. È importante notare che la sentenza non lega alcuna altra corte del Paese, e che potrebbero volerci anni per completare il processo di appello.

Insomma, non è ancora stata detta la parola fine. Al meglio, rimandato di qualche anno. Chissà che per allora Microsoft non abbia deciso di regalare le API di Windows alla comunità Linux, di cui ormai fa parte😉

Google e l’OS color Fuchsia

Facebooktwittergoogle_plusredditlinkedin

Che Google abbia sempre qualche cosa in sviluppo, valutazione o sperimentazione è indubbio. Spesso questi progetti sono anche pubblici, ma senza pubblicità che attiri l’attenzione.

Da un paio d’anni ha in sviluppo Fuchsia, un nuovo sistema operativo costruito in casa fin dal kernel, chiamato Zircon. In questi anni ogni tanto è apparso qualche riferimento, ma è rimasto sconosciuto lo scopo, il perché sviluppare un altro sistema operativo. Lo è tutt’ora, ma adesso abbiamo qualche dettaglio su cosa sia Fuchsia, e in cosa si differenzi da quanto già visto.
Google ha infatti pubblicato la documentazione, chiamata The Book.

Fuchsia is not Linux

Fuchsia non è Linux

Le prime parole del documento (nonché il titolo del primo paragafo) servono ad affermare una cosa non ovvia, di questi tempi: il nuovo sistema operativo non è in alcun modo basato su Linux. Fuchsia ha un kernel suo e programmi suoi, tutto fatto in  casa.
Un sistema operativo è formato da almeno due parti: il kernel, che si occupa di gestire l’hardware, ed i programmi base, che danno istruzioni al kernel. Le varie distribuzioni Linux (di cui così spesso parliamo) sono una combinazione del kernel Linux e dei programmi GNU (tanto che sarebbe corretto riferirsi sempre a sistemi GNU/Linux).
Come visto quando abbiamo parlato di Meltdown, lo spazio di memoria assegnato al kernel è separato da quello dei programmi, ed anche quello che può fare il kernel è diverso: dovendo gestire l’hardware, il kernel può mandare dei comandi ai dispositivi, mentre i programmi devono usare il kernel.

Tutto in userland

Leggendo la documentazione salta all’occhio come molte funzioni, che normalmente vediamo parte del kernel (al massimo come modulo da caricare), in Fuchsia siano processi (chiamati servizi) che girano nello spazio utente.
Per esempio, per accedere ad un file normalmente viene chiamato un programma che individua il file in un filesystem (caricato nel kernel), il quale usa un driver (caricato nel kernel) per leggere i dati memorizzati fisicamente sul disco.
In Fuchsia succede una cosa molto simile, ma non identica: un programma chiede il file ad un filesystem (che è un servizio, ovvero un altro programma), il quale chiede informazioni ad un driver (che è un altro servizio) per dare le istruzioni al kernel che legge fisicamente i dati dal disco; la catena di comunicazioni quindi procede a ritroso: il driver comunica il risultato al filesystem che comunica la disponibilità o meno dei dati al programma richiedente.

Scambio messaggi, non dati

Normalmente filesystem e driver devono essere scritti nello stesso linguaggio del kernel, e ne devono condividere le strutture dati visto che usano direttamente quei dati. Questo porta ad uno svantaggio: ad ogni aggiornamento della struttura dati del kernel, il modulo deve essere ricompilato e/o in parte riscritto, per adeguarsi ai cambiamenti.
In Fuchsia i componenti sono programmi a sé stanti che comunicano tra di loro con un protocollo standard: qualunque programma, scritto con qualsiasi linguaggio, sia in grado di comunicare con quel protocollo (chiamato RemoteIO) può svolgere quel compito. Questo vuol dire anche che l’aggiornamento di uno di questi componenti (kernel, filesystem o driver) non implica l’aggiornamento di tutti, e le modifiche di funzionamento o rappresentazione dei dati interno non coinvolge gli altri componenti.

A chi è destinato tutto questo?

Non ci dilungheremo oltre sulle caratteristiche tecniche, che sono peraltro ben approfondibili grazie proprio al Libro di Google. Aggiungiamo solo che l’architettura sembra studiata per avere nativamente certe caratteristiche:

  • un alto livello di sicurezza: ogni processo è indipendente e potrebbe aver accesso solo allo stretto necessario;
  • multipiattaforma: il (micro)kernel e la modularità dei servizi permetterà di avere solo i componenti necessari su hardware embedded, mentre più generale e completo su altri tipi di hardware; inoltre, grazie al sistema a servizi non si è legati ad un linguaggio specifico;
  • facilità di manutenzione: l’aggiunta, l’aggiornamento o la rimozione di un servizio sono istantanei e indipendenti dagli altri.

Queste caratteristiche fanno pensare ad un uso che spazia dai pc ai telefonini, tanto che qualcuno ha già ipotizzato possa essere il futuro sostituto di Android e ChromeOS.
Noi crediamo sia semplicemente un po’ troppo presto per dirlo: il sistema è ad uno stadio di esercizio di stile, non ancora definibile nemmeno come versione Alpha (in cui le funzionalità base sono state implementate), quindi per poter valutare cosa effettivamente sia e dove potrebbe avere senso usare Fuchsia ci vorranno ancora anni.

In compenso, ci fa molto piacere che esista, e che si stia sviluppando tanto velocemente, un’alternativa. Opensource, naturalmente.

Torvalds si esprime su Lockdown con Secure Boot

Facebooktwittergoogle_plusredditlinkedin

Un anno fa David Howell, sviluppatore di Red Hat, ha proposto una serie di modifiche al kernel – come normale in un progetto opensource – chiamata Lockdown (chiusura sotto chiave), ovvero una funzionalità del kernel che lo protegga da tentativi di manomissioni esterne. Le tecniche adottate per questo scopo sono varie:

  • impedire il caricamento di moduli non firmati;
  • impedire l’accesso, specie in scrittura, ad aree di memoria e mountpoint particolari (come /dev/mem o /dev/kmem);
  • impedire l’uso di ioperm/iopl() o la scrittura su /dev/port;
  • impedire l’uso di kexec_load();
  • restrizioni a parti dell’ACPI e di debugfs;
  • possiblità di essere attivata al boot da EFI (e Secure Boot).

Dopo – appunto – quasi un anno, e dopo l’accettazione di queste modifiche, Linus Torvalds ha deciso di far sentire la sua, in quanto non proprio soddisfatto della strada imboccata.

La critica non riguarda la nuova modalità in sé – che, anzi, gli piace -, ma la volontà di attivarla di default nel caso il sistema venga avviato via EFI con Secure Boot e non in altre situazioni, creando una diversità per l’utente finale a parità di impostazioni di sistema operativo. Tra l’altro non è possibile disattivare la funzionalità, a meno di disabilitare anche Secure Boot.

THE TWO FEATURES HAVE NOTHING TO DO WITH EACH OTHER WHAT-SO-EVER.

I do not want my kernel to act differently depending on some really esoteric detail in how it was booted. That is fundamentally wrong.

LE DUE FUNZIONALITÀ [Secure Boot di EFI e Lockdown del kernel] NON HANNO NIENTE A CHE FARE TRA DI LORO, NON IMPORTA COSA.

Non voglio che il mio kernel si comporti differentemente in funzione di qualche dettaglio davvero esoterico nel modo in cui sia stato avviato. Questo è sbagliato in principio.

Ovviamente la sua opinione, per quanto autorevole, espressa con la consueta pacatezza, ha generato una discussione vera e propria, ed in particolare uno scambio intenso con Matthew Garrett, altro sviluppatore Red Hat che si è già occupato dell’integrazione di RHEL con Secure Boot, e che ha collaborato nello sviluppo di Lockdown. Il quale, per difendere meglio la propria posizione, ha creato un post sul suo blog personale.

Noi non entriamo nel merito del discorso, ma ci permettiamo un’osservazione personale: Linus potrebbe avere ragione anche stavolta, se non altro in nome della libertà di scelta dell’utente che Linux, da sempre, incarna.

E voi, da che parte state? Default attivo, default disattivo o legato all’attivazione di Secure Boot?

Oracle vs Google: la saga per Android continua

Facebooktwittergoogle_plusredditlinkedin

Quasi due anni fa parlavamo di questa stessa vicenda, che ormai si trascina da otto anni. E, incredibilmente, non è ancora finita.

L’oggetto del dibattito è il sistema Android, scritto (in gran parte) in Java, grazie alla sua particolarità di generare del codice eseguibile da una grande varietà di dispositivi tramite un programma, la Java Virtual Machine, specifico per il dispositivo. Le specifiche del linguaggio sono libere, ma le implementazioni sono molte; quella di riferimento è sotto copyright ed era distribuita – gratuitamente – da SUN. Nel 2010 Oracle compra SUN, con la sua implemetentazione, e da allora reclama un risarcimento danni a Google per aver usato Java senza permesso.

Esponiamo l’ultima puntata della saga, ma più sotto trovate un riassunto.

A maggio del 2016 la giuria aveva decretato che quello di Google era a tutti gli effetti un uso equo (fair use), ovvero un uso senza fine di lucro (dato che Android, in sé, è opensource e distribuito gratuitamente). Ma il giudice, pochi giorni fa, ha deciso che questa decisione era tecnicamente sbagliata: il fatto che fosse “poco” codice non implicava fosse “poco importante” (uno dei possibili requisiti per il fair use), e quindi ha ribaltato la sentenza: Google ha torto e deve pagare i danni ad Oracle. Quanto? Altro processo per definirlo, ma Oracle chiede non meno di  8,8 miliardi di dollari: 3 volte il fatturato di RedHat.

Le armi a disposizione di Google per evitare un tale esborso sono molte poche; la più efficacie, il ricorso alla corte suprema della California, potrebbe essere anche la più spuntata: già nel 2014 ha tentato questa strada, e la corte ha semplicemente declinato la richiesta. Forse, questa volta, dovrò davvero pagare.

In realtà il problema non è solo una questione di soldi tra Google e Oracle, ma rappresenta un precedente pericolo per l’opensource in generale, in quanto le API rappresentano il codice “di contatto” tra un programma e l’altro, create proprio con l’intento di essere riusate e distribuite: il precedente per cui sono coperte da copyright e non possono essere nemmeno re-implementate rappresenta un concreto ostacolo al loro riuso, ed al riuso del codice in generale.

La sentenza cerca di limitare l’effetto a questo caso, ma rimane davvero indubbio che uno sviluppatore, prima di usare codice scritto da altri, ci penserà almeno due volte…

Piccolo riassunto

Il contendere è il sistema Android (e nello specifico gli introiti generati da esso), il celeberrimo – e usatissimo – sistema operativo oramai sinonimo di smartphone – almeno come unica alternativa ad Apple ed al suo iOS.
Android è basato su Java, che di per sé è un linguaggio opensource, ovvero le sue specifiche sono di pubblico dominio, ma l’implementazione di quelle specifiche, ovvero il codice che viene effettivamente eseguito da un computer, può essere messa sotto copyright, come qualsiasi altro software. Nello specifico, in questo caso, si parla delle API, ovvero la parte più superficiale dell’implementazione fatta apposta per interagire con altri programmi – o diventarne parte.

Quando Google iniziò lo sviluppo di Android, alcune di queste interfacce non erano disponibili per il Java usato dai telefonini, e pensò di ricreare (copiare, se volete) quelle usate sui PC, prendendo spunto dall’implementazione che era (ed è) quella di riferimento: quella di Sun – nel frattempo comprata da Oracle. Il tutto, però, senza chiedere esplicitamente il permesso.

Appena acquisita Sun, Oracle intenta la (prima) causa, che genera una vera e propria telenovela:

  • 2010 – Oracle dice che sono stati infranti dei brevetti e che le API sono sotto copyright: perde subito sul brevetto. Google sostiene di rientrare nel caso di fair use.
  • 2012 – Oracle perde anche sul copyright: per il giudice le API e il codice sono cose diverse, e le prime non sono coperte; fa ricorso.
  • 2014 – Oracle vince: all’appello si stabilisce che le API sono sotto copyright. Google sostiene che allora rientra in gioco il fair use: la giuria deve esprimersi.
  • 2016 – (puntata scorsa) La giuria stabilisce che Google rientra nella fair use. Ma manca ancora la sentenza…

Un nuovo formato video da AOMedia: è nato AV1. Ed è gratis

Facebooktwittergoogle_plusredditlinkedin

Ieri è stata annunciata la disponibilità pubblica del primo codice sperimentale che implementa un nuovo formato di compressione video: l’AV1. Ad annunciarlo il consorzio che ne promuove lo sviluppo e l’adiozione, AOMedia, che raggruppa (tra gli altri) nomi come Amazon, Apple, Google, Facebook, IBM, Cisco, Microsoft, Mozilla, Nvidia e Netflix.

Questo codec si preannuncia come un grande passo avanti nella compressione video, permettendo una riduzione del 30% nelle dimensioni (e con la stessa qualità) rispetto allo stesso video codificato in h264, di fatto lo standard attuale. Inoltre, i video in definizione 4k (e a 30 fps) sono già previsti e supportati (e non estensioni/forzature del formato).

L’altro vantaggio è di essere completamente royalty-free, che tradotto vuol dire gratis: a differenza di mp3 o MPEG2 (il formato dei DVD), qui nessuno detiene brevetti sul codice, e quindi non è necessario pagare alcuna tariffa per l’uso.

Le prime implementazioni (ribadiamo: sperimentali) sono già in giro (GStreamer 1.14), ma con tutta probabilità, visto l’elenco dei sostenitori, non dovremo attendere molto per dei dispositivi che lo supportino nativamente. Fosse solo Netflix sul nostro telefonino…

GRUB fa un passetto avanti e carica immagini initrd

Facebooktwittergoogle_plusredditlinkedin

GNU logo

Lo sviluppo di GRUB (GNU GR, il boot manager di gran lunga più diffuso ed usato dalle distribuzioni del pinguino) è sempre stato lento, ma per un componente così specializzato ed allo stesso tempo critico per un sistema è normale. Non si faccia l’errore però di pensare che l’avanzamento si sia fermato!

È infatti notizia di questa settimana che è stata integrata una nuova funzionalità: la capacità di GRUB di caricare delle immagini initrd direttamente in fase di boot. Questa nuova capacità è particolarmente utile per il caricamento del microcode, che potremmo paragonare al firmware delle CPU, in modo che sia attivo fin dalle prime fasi del boot.

Tutto il polverone per Spectre, Meltdown (ed ora anche Ryzenfall et similia) ha sicuramente accelerato l’implementazione di questa funzionalità, proposta già due anni ma che è stata semplicemente ignorata. O meglio: è stata prevista ed implementata la funzionalità già con GRUB 2.02, ma il suo uso richiede interventi di configurazione complicati.

Quello che è stata implementata ora, per la precisione, è la capacità di GRUB di rilevare (o essere informato per) la presenza di un initrd da caricare, ed occuparsene quindi senza alcun intervento dell’utente. Comodo, non trovate?

Spectre e Meltdown sono solo sensazionalismo?

Facebooktwittergoogle_plusredditlinkedin

L’inizio dell’anno è stato sicuramente dominato dal caso Spectre e Meltdown: annunciato al pubblico l’ultima settimana del 2017, ha causato delle correzioni da applicare a tutti i sistemi operativi; l’essere un bug hardware, e pure diffuso tra varie piattaforme (Intel ed AMD, x86 ed ARM), implicava che nessuno era al sicuro.

Ma forse tutta questa furia non era giustificata. O meglio: il bug è sicuramente presente, e le conseguenze sono accertate, ma è la pericolosità effettiva da dover essere rivalutata. O almeno questo è quanto sostiene Hugh Darvall, direttore delle vendite di Flexera (società software Americana che produce anche InstallShield), in un post intitolato -non a caso- come questo: “Are Spectre and Meltdown just hype?”

Il post è breve, ed incentrato su una considerazione:

Through Secunia Research at Flexera, more than 121 vulnerability intelligence advisories were issued on Spectre and Meltdown. However, most advisories were scored below “Moderately Critical” (one to three out of a maximum score of five). As a matter of fact, 5 advisories scored “Highly Critical” (four out of five).

To put this in perspective, Secunia Research issued another 52 unrelated advisories scored “Highly Critical” in the two weeks following the public disclosure of Meltdown and Spectre. The vulnerabilities were found in widely used software.

Tramite Secunia Research, di Flexera, sono stati esposti più di 121 avvisi di vulnerabilità delle informazioni riguardanti Spectre e Meltdown. Tuttavia, molti degli avvisi avevano punteggio sotto il “Moderatamente Critico” (da 1 a 3 su una scala di massimo 5). Per dovere di cronaca, 5 avvisi erano “Altamente Critici” (4 su 5).

Per mettere la cosa in prospettiva, Secunia Resarch ha esposto altri 52 avvisi non correlati di livello “Altamente Critico” nelle due settimane seguenti l’annuncio al pubblico di Meltdown e Spectre. Le vulnerabilità sono state trovate in software di largo uso.

Quindi, il clamore mediatico è stato eccessivo, ma soprattutto la fretta – o la furia – per scrivere e rilasciare le patch non erano giustificate: il pericolo è (ed era) tutto sommato basso, o almeno non eccezionale.

L’articolo procede quindi a spiegare i tre passi da seguire per essere efficaci nell’affrontare un problema di sicurezza, soprattutto in ambito enterprise:

  1. identificare i pericoli con spirito critico, valutando anche la fonte delle informazioni; identificare quindi la vulnerabilità maggiore, su cui concentrarsi
  2. non cedere all’ansia e creare delle priorità;
  3. approccio conservativo: applicare le patch in ambiente controllato, su un numero limitato di macchine di cui valutare le prestazioni pre e post. Questo serve anche per sapere se la patch non introduce problemi maggiori di quello che deve essere risolto…

E voi, cosa ne pensate?

Purism, Librem e PureOS per il notebook più sicuro al mondo

Facebooktwittergoogle_plusredditlinkedin

Di Purism e dei suoi prodotti abbiamo parlato spesso, soprattutto riguardo a Librem 5, lo smarphone completamente libero (ancora in sviluppo ma già ordinabile).

Alcuni si ricorderanno di Librem 15, uno dei primi notebook pensati e proposti appositamente per software opensource nonché realizzato grazie al crowfounding, che (semplificando) vuol dire libere donazioni. Beh, quel progetto è stato portato avanti, tanto da essere disponibile all’acquisto con hardware rinnovato (come CPU Intel i7  di sesta generazione) ed essere disponibile anche in formato 13″ e (in futuro) tablet da 11″.

E la novità riguarda proprio questi notebook: in un comunicato di fine febbraio viene annunciato che è stato integrato con successo il firmware Heads nel gestore di avvio coreboot, abilitato ad usare TPM (Truster Platform Module) per le firme crittografiche. Sembra un po’ confuso, vero? Proviamo a metterla così: con questo ultimo pezzo di software ogni passo del processo di boot può essere firmato, dandoci la sicurezza che non sia stato alterato o sostituito con qualcosa di pericoloso a nostra insaputa, ma senza usare software chiuso (e talvota bacato) dell’azienda produttrice della CPU o del chipset (ovvero Intel). Il tutto a vantaggio della personalizzazione e della sicurezza: essendo tutto codice opensource, chiunque – non ci stancheremo mai di dirlo – può verificare che non ci siano operazioni pericolose, o anche solo lesive della privacy dell’utente.

Se aggiungiamo che il sistema operativo usato è PureOS, ovvero una distribuzione Linux pensata per sicurezza e privacy basata su debian, le parole del fondatore (ed amministratore delegato) di Purism, Todd Weaver, hanno credibilità:

By activating Heads in our TPM-enabled coreboot by default on all our laptops, this critical piece combined with the rest of our security features will make Librem laptops the most secure laptop you can buy where you hold the keys.

Con l’attivazione predefinita di Heads nel nostro coreboot, abilitato a TPM, su tutti i nostri laptop, questo pezzo critico in combinazione con il resto delle nostre funzioni di sicurezza renderà i laptop Librem i più sicuri che qualcuno possa comprare, e di cui abbia le chiavi.

Ma le novità non sono ancora finite, perché c’è qualcosa anche per Librem 5, lo smartphone: in uno dei post di aggiornamento del progetto viene annunciato lo sviluppo ex-novo di un compositore Wayland per il nuovo telefono, in modo da evitare il (vetusto) server X11. Grazie all’uso delle board di sviluppo equipaggiate col chip i.MX 6, ed in attesa di quelle con chip i.MX 8M, sembra che lo sviluppo sia già a buon punto, con ridimensionamento delle finestre e i primi menù di controllo.

Insieme a questo sviluppo, è in progresso anche la shell, stile GNOME, pensata apposta per un telefono (chiamata phosh). Anche questa è una bella novità, anche se ancora in una fase iniziale. Ci sono anche altri campi di sviluppo collegati:

  • interfacce responsive o adattive in GTK+;
  • supporto dell’input;
  • supporto per la telefonia.

Insomma, Purism porta avanti tanti progetti, ma tutti caratterizzati da una cosa: essere opensource. E noi non possiamo fare altro che apprezzare.