On 10/05/2019, Alberto Cammozzo <ac+nexa@zeromx.net> wrote:
General-purpose computers are astounding. They're so astounding that our society still struggles to come to grips with them, what they're for, how to accommodate them, and how to cope with them. [...]
This rule of thumb serves regulators well, by and large, but it is rendered null and void by the general-purpose computer and the general-purpose network—the PC and the Internet.
We don't know how to build a general-purpose computer that is capable of running any program except for some program that we don't like, is prohibited by law, or which loses us money.
Qualche giorno fa leggevo un articolo che mi ha proprio fatto pensare a questo discorso: https://blog.jessfraz.com/post/why-open-source-firmware-is-important-for-sec... Propone tutta una serie di considerazioni serissime sulla (scarsissima) sicurezza dei processori e sistemi operativi (con qualche piccolissima scivolata laddove confonde UEFI Runtime Services e applicazioni UEFI) e fornisce ottime ragioni per cui tutto lo stack dovrebbe essere software libero prodotto da compilazioni riproducibili. Perché così possiamo capire cosa fa. Così possiamo. Noi.
From the above, it’s pretty clear that for Rings -1 to 3, we have the option to use open source software and have a large amount of visibility and control over the software we run. For the privilege levels under Ring -1, we have less control but it is getting better with the open source firmware community and projects.
It’s counter-intuitive that the code that we have the least visibility into has the most privileges. [...]
Between Ring -2 and Ring -3 we have at least 2 and a half other kernels in our stack as well as a bunch of proprietary and unnecessary complexity. Each of these kernels have their own networking stacks and web servers. The code can also modify itself and persist across power cycles and re-installs. We have very little visibility into what the code in these rings is actually doing, which is horrifying considering these rings have the most privileges. [...]
They are horrifying when they happen though. Just to use one as an example although I will let you find others on your own, there was a bug in the web server of the Intel Management Engine that was there for seven years without them realizing.
How can we make it better?
Chi sono questi "We"? Dopo qualche anno come sviluppatore di kernel io sono parte di questo "We"? Non ho problemi a leggere codice C e me la cavo decentemente con l'Assembly: non dovrei avere grossi problemi con nessuno dei componenti descritti... ma dove potrei mai trovare il tempo di studiarli seriamente? Per debuggare una implementazione delle specifiche UEFI o per il SMM? Temo di no. A meno di venire pagato a tempo pieno per farlo. E se non posso io, che ho gli "skill" adatti, come posso assumere che altri lo facciano? Ed infatti, come mostrò qualche anno fa chiaramente Heartbleed, nessuno lo fa. Nessuno legge VERAMENTE i sorgenti. Una sbirciatina ogni tanto sì. Profonda comprensione solo se costretti. Ma non è la maledizione del TL;DR. E proprio l'assenza di tempo libero. Tuttavia il marketing dell'Open Source è riuscito in qualche modo a convincere il mondo di essere buono e di alta qualità per il solo fatto di essere open. Di meritare fiducia. Per farlo ha giocato sull'ambiguo rapporto con il software libero, dichiarandosene successore nel momento stesso in cui marginalizzava gli hacker. Ma anche sull'illusione che la trasparenza sia sufficiente a garantire la qualità e... l'onestà. Chi mai ruberebbe alla luce del sole? Ma la cosa più divertente è che in quel "We can" di Obamiana memoria si riconoscono tutti. Anche coloro che non saprebbero nemmeno da dove iniziare a leggerlo un kernel. "Possiamo leggere il sorgente" è una affermazione valida solo per coloro che effettivamente possono. Ovvero che hanno le competenze e hanno il tempo. Tutti gli altri sono stati indotti a credere che si possono fidare perché qualcuno, sul pianeta, ha le competenze ed il tempo per studiare e debuggare i sorgenti del software libero che usano, non ha di meglio da fare e sicuramente non userebbe mai eventuali vulnerabilità, ma cercherebbe di correggerle prima che qualche malintenzionato ne approfitti... Ops! Possibile che i malintenzionati abbiano sia le competenze che il tempo? :-D E viene giù il castello di carte. Lo scopo dell'articolo era sostenere l'importanza del firmware open source. Purtroppo però per la stragrande maggioranza della popolazione umana, l'unica vera differenza fra open source e software proprietario è il prezzo. Perché tanto non vanno a leggere i sorgenti. Perché anche quando hanno gli skill, non hanno il tempo. E devono fidarsi ciecamente. Dunque ci troviamo di fronte ad una nuova forma di IP protection, basata non più (o meglio, non solo) sulla legge, ma sulle barriere socio-culturali. Basta per esempio scrivere software così complesso, che mettere su l'infrastruttura per compilarlo da zero richiede giorni. O che richiede mesi per essere compreso e debuggato in profondità. O che richiederebbe decenni per essere sfidato da un concorrente (vedi l'abbandono da parte di Microsoft del proprio web engine a favore di Chromium!) Tuttavia questa nuova barriera è solo necessaria per scoraggiare gli hacker. Per il resto della popolazione basta diffondere l'idea che l'Informatica sia una cosa da specialisti. Testi scritti da specialisti per essere eseguiti passo passo da macchine generali. La "specialità" di chi sa ideare e realizzare soluzioni per un qualsiasi problema... in modo generale. Non è un po' troppo generale come specialità? Chi non sa PROGRAMMARE un computer in modo fluente è un ANALFABETA informatico. Non è colpa sua, ma non dirlo chiaramente significa abbandonarlo alla sua inconsapevole e manipolabile ignoranza. Saper usare la mail, o Excel non lo rende meno analfabeta, meno manipolabile. Il firmware deve essere software libero. Software leggibile e modificabile da TUTTI. Se è leggibile e modificabile solo da una casta di eletti, non è libero affatto. E questo significa che dobbiamo renderlo più semplice. Perché altrimenti seccature come DRM, Copyright e Brevetti diventeranno sempre più secondarie rispetto alla scarsità di tempo e competenze. Giacomo