Non vorrai mica fare un boot?

Nell'eterna battaglia per la libertà informatica un nuovo colpo viene assestato da UEFI e il Secure Boot.

Di cosa si tratta?

UEFI è un acronimo che significa Uniform Extensible Firmware Interface, e rappresenta una sorta di miglioramento all'EFI (senza la U di Uniform) presentato da Intel e sostenuto da Microsoft fin dai tempi dell'Itanium. In parole povere UEFI rappresenta il nuovo BIOS dei moderni Personal Computer.

UEFI permette una modalità di boot denominata secure boot: solo il software riconosciuto come affidabile da UEFI può avviare un processo di boot del computer. Come fa UEFI a sapere quale software è affidabile? Sostanzialmente il software di boot (boot loader) viene firmato digitalmente con un hash crittografico, tale hash viene mantenuto da UEFI in un repository di chiavi in modo da poter verificare se il software che si sta per lanciare corrisponde a quello fidato o meno.

Dovrebbe quindi apparire evidente il problema: ogni modifica al boot loader di un sistema operativo richiede la memorizzazione di una nuova chiave nel repository UEFI al fine di consentire il boot. C'è anche l'aternativa di disabilitare il secure boot, bypassando quindi il controllo UEFI che permette quindi di lanciare qualsiasi boot loader.

Questa modalità di operare presenta non pochi problemi, principalmente:

• una complessità di gestione a mio avviso non giustificata (almeno al momento);
• la possibilità che un produttore hardware non fornisca la possibilità di disattivare il secure boot nella sua implementazione UEFI;

Si consideri la complessità di gestione. Francamente non sono mai stato molto preoccupato del mio boot loader. Posso capire che ci siano problemi di sicurezza in un kernel che esegue, in un demone che esegue, in uno script. In un boot loader? Quand'è che si cambiano le impostazioni di un loader? Quando si ricompila un kernel (utenti  esperti); quando si aggiorna il sistema (amministratori  responsabili), quando si testa una configurazione differente (sviluppatore  capaci). In nessuno di questi casi il problema è nel boot loader, bensì nelle competenze di chi si occupa della sua configurazione. La cosa quindi non mi spaventa particolarmente.

Si consideri ora la possibilità che un vendor non inserisca l'opzione per disabilitare il secure boot: il sistema non sarà in grado di essere customizzato, nemmeno con le migliori intenzioni. E guarda caso questo sembra quanto successo con Microsoft Windows 8. Risultato: si compra dell'hardware con software OEM (omaggio) che non può essere modificato. Ricorda forse l'incedente della TiVo-ization? E anche ammettendo che l'hardware permetta di disabilitare il secure boot, cosa succede se del software non permette il boot in modalità insicura (come Windows 8 appunto)?

Mi domando quanto passerà prima che anche la Apple abbracci questa nuova limitazione per gli utenti.

Impostare uno splash screen accattivante in FreeBSD/PCBSD

Il boot di un sistema FreeBSD è piuttosto minimale, ma molto efficace: vengono mostrati i messaggi del kernel e dei vari demoni che si avviano. Questo è molto utile per un server, ma potrebbe non essere molto accattivante per un sistema desktop. PCBSD offre un proprio splash screen grafico dalla versione 9, ma è possibile applicarne uno anche ad un FreeBSD puro. I passaggi per la realizzazione di uno splash screen di avvio personalizzato sono abbastanza semplici:

• salvare una immagine in formato PCX (meglio usare una palette ad-hoc e non andare oltre la risoluzione di 1024x768, dopotutto l'immagine non deve essere troppo pesante);

• copiare l'immagine nella cartella /boot della macchina FreeBSD (ad esempio usando scp se si sta editando l'immagine da una macchina remota);
• editare il file /boot/loader.conf della macchina FreeBSD aggiungendo le seguenti righe di configurazione (ovviamente il nome dell'immagine deve coincidere con quello esatto dello splash screen che si vuole avere):

splash_pcx_load="YES"
vesa_load="YES"
bitmap_load="YES"
bitmap_name="/boot/freebsd.pcx"

A questo punto all'avvio della macchina si avra' il nuovo splash screen in esecuzione. E' sufficiente premere un tasto qualunque sulla tastiera della console per ottenere il boot verbose, ossia far sparire lo splash screen e far comparire i messaggi del kernel. Unico accorgimento il nome del file immagine, che deve essere "semplice" (corto e senza caratteri speciali '-','_'). Nell'esempio di cui sopra il nome dell'immagine FreeBSD-Daemon-Wallpaper.pcx è stato modificato nel nome finale freebsd.pcx.

ICAROS

ICAROS è un sistema operativo sperimentale basato sul lavoro dell'Amiga OS. Non ho avuto modo di fare molta pratica, ma la cosa che mi ha subito colpito è che in circa 3 secondi il sistema è caricato e funzionante anche con soli 256 MB di RAM.

Sicuramente una scelta interessante per chi vuole un sistema desktop alternativo (come Haiku) e veloce.

Ecco alcune immagini di una macchina virtuale che ho usato per i test.

Commodore 64 reborn!

Chi si ricorda il Commodore 64, compagno di innumerevoli pomeriggi spesi a caricare i giochi da cassetta o da dischetto mentre si veniva ipnotizzati da schermate fluorescenti?

Ebbene il Commodore 64 esiste ancora, ed è piu' potente di prima (bella forza!), montando hardware da PC di tutto rispetto: 4 GB di ram, scheda video nVidia da 512 MB, scheda Ethernet Gigabit, hard disk sata fino a 3 TB, porte USB, lettore di schede multimediali.

E il sistema operativo è una versione modificata di Linux!

fdisk: Class not found

All'atto dell'inizializzazione di un nuovo disco in FreeBSD mediante fdisk mi sono trovato in console un errore piuttosto strano: "Class not found".
L'errore e' in realta' fittizio, ovvero fdisk fa correttamente il suo lavoro, e l'errore puo' essere tranquillamente ignorato. Incuriosito ho pero' spulciato i sorgenti alla ricerca dello strano messaggio ed e' risultato che l'errore proviene da geom_ctl.c che effettua il seguente pezzo di codice:

static void                                                                              
g_ctl_req(void *arg, int flag __unused)                                                  
{                                                                                        
        struct g_class *mp;                                                              
        struct gctl_req *req;                                                            
        char const *verb;                                                                
        g_topology_assert();                                   

       req = arg;                                                                        
       mp = gctl_get_class(req, "class");                                                
       if (mp == NULL) {                                                                 
                gctl_error(req, "Class not found");                                      
                return;                                                                  
        }

dal quale si nota appunto l'errore di cui sopra. Non sono un esperto di GEOM, ma il mio sospetto e' che il layer di accesso al disco si aspetti di trovare una classe configurata, cosa impossibile perche' il disco non e' ancora stato inizializzato, e quindi lanci un errore GEOM che non si riflette di fatto su fdisk. In altre parole, penso che l'accesso al disco da parte di fdisk faccia scattare il meccanismo GEOM, che si trova impossibilitato a procedere e quindi ripassa la "palla" a fdisk stesso che procede alla scrittura di basso livello. Ma questa e' solo una possibile intuizione del problema....

Messaggi dal kernel in evidenza

Una feature molto interessante di FreeBSD e altri sistemi BSD e' quella di avere una impostazione dei messaggi di console differente da quella dei messaggi dei normali terminali. Questo si traduce in un impatto visivo migliore: i messaggi del Kernel (ad esempio al boot) sono visibili chiaramente in un colore bianco chiaro, mentre quelli dei processi userland restano al classico "grigio da terminale". OpenBSD si spinge oltre, formattando i messaggi del kernel con uno sfondo blu al posto del classico "nero console".
E' possibile fare una configurazione analoga anche in FreeBSD. 

Come prima cosa e' meglio preparare un file di configurazione del Kernel ad-hoc:

cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/GENERIC.colors




e successivamente editarlo inserendo le seguenti righe (modificando i colori a seconda delle preferenze):


options         SC_NORM_ATTR=(FG_WHITE|BG_BLACK)
options         SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
options         SC_KERNEL_CONS_ATTR=(FG_YELLOW|BG_BLUE)
options         SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)

E infine occorre ricostruire ed installare il nuovo kernel:

cd /usr/src
make buildkernel   KERNCONF=GENERIC.colors
make installkernel KERNCONF=GENERIC.colors

Al riavvio la console mostrera' i messaggi del kernel con il nuovo set di colori impostato.

Funzione multi-cursore

Qualche giorno fa ho implementato un semplicissimo esempio didattico di una stored procedure che scorre piu' cursori contemporaneamente. PostgreSQL non consente ad una funzione di ritornare piu' cursori, ma consente ad una funzione di restituire un insieme (setof) di riferimenti a cursori, ossia di "handle" che possono essere usati per le operazioni di FETCH. Il trucco quindi consiste nell'aprire i cursori all'interno della stored procedure per poi ritornare i riferimenti al chiamante, che li userà per ottenere le tuple relative.

AspectJ 1.7 & invokedynamic

E' stato appena rilasciato AspectJ 1.7 che allinea il compilatore (weaver) alla versione 3.7 di Eclipse e presto raggiungerà la versione di Juno (4.x). E' interessante notare che il numero di versione, .7, corrisponde alla major release di Java, la 7 appunto, che il nuovo compilatore supporta. In particolare si sta lavorando molto per supportare la nuova istruzione invokedynamic di Java 7, anche se ancora non ci sono dei join points definiti.

Questa istruzione permette a Java di invocare un metodo su un tipo di oggetto non specificato, aprendo quindi la strada all'integrazione con i linguaggi di scripting. Infatti Kava è sempre stato un linguaggio staticamente tipizzato, e tutte le versione di invokeXXX (come invokevirtual) hanno sempre compreso un tipo sul quale chiamare il metodo oltre alle informazioni dei tipi parametrici e di ritorno. Con la nuova istruzione invece i tipi non sono presenti, di fatto si usa un trucco simile ai puntatori void* di C: nel constant pool si inserisce un MethodHandle che viene linkato alla prima invocazione, lasciando così il bytecode "libero" da tipizzazioni preventive.

FreeBSD & ports: make da root

Si è sempre consigliato di non compilare dei sorgenti con le credenziali di amministratore. La ragione è che gli script di compilazione, make, cmake, configure, e altri possono essere molto complessi e nascondere comandi maliziosi o pericolosi.

Eppure su FreeBSD l'installazione di un port richiede le credenziali di root, e se si tenta di eseguire anche un semplice make da utente normale si viene bloccati con una richiesta di elevazione di privilegi.

Il motivo è semplice: l'installazione di un port potrebbe richiedere l'installazione di altri port. Anche la semplice compilazione potrebbe richiedere l'installazione di altre dipendenze- Ne consegue che per poter effettuare un processo automatizzato la compilazione di un port deve avvenire con credenziali di amministratore, altrimenti ad ogni dipendenza il processo si arresterebbe aspettando l'input dell'amministratore per eseguire una installazione.

Inoltre al momento dell'installazione devono essere create le entry nel repository dei pacchetti (/var/db/packages), che è appunto proprietà esclusiva del super utente.

PHP e ritorno di reference

Ammetto di non aver studiato molto i reference di PHP, ma sono incappato in una stranezza: un metodo che ritorna un reference (quindi tramite operatore &) deve essere usato in un contesto di assegnamento per riferimento, altrimenti si ha sempre la copia.

In altre parole:

function & arrayReference(){ ... }

$arrayRef = arrayReference();

è sbagliato, poiché il metodo ritorna un riferimento, ma questo viene poi usato in un "assegnamento per copia" (la cosa mi ricorda molto il C++). Il modo corretto di procedre è:

function & arrayReference(){ ... }

$arrayRef = & arrayReference();

OpenSolaris inghiottito da Oracle

Beh, di come Oracle si sia comportata con il sistema OpenSource di casa Sun non è certo una novità. Ma è da qualche giorno che nemmeno il non piu' tanto aggiornato planet dedicato a questo sistema operativo, planet.opensolaris.org non apre un aggregatore bensì la pagina ufficiale di Oracle Solaris (si noti l'assenza della parola "Open"). Sarò malizioso, ma io lo vedo come un chiaro segnale che non solo il sistema operativo deve essere rimpiazzato da quello proprietario, ma che perfino le notizie sul sitema operativo open non devono piu' circolare. E intanto sembra che anche altri progetti siano stati "colpiti", e anche il sito di Belenix non risponde piu'...guasto temporaneo o cessazione?