Ormai da diversi giorni l’intera comunità di sviluppatori XDA è in fermento per via di un particolare post comparso sui forum, titolato “Google minaccia i modders con Android 4.4”. Un’affermazione di certo abbastanza forte, tra non molto capirete perché: è stata introdotta in via sperimentale una funzionalità nel kernel Android, tale dm-verity, che permette di eseguire dei controlli d’integrità per evitare l’installazione accidentale di rootkit. O almeno questo è ciò che Google ha pensato.
Infatti esiste, in particolari condizioni e in determinati dispositivi, la possibilità che dm-verity renda praticamente impossibile l’installazione di una custom ROM ed è proprio da questo effetto collaterale che prende spunto il titolo del post incriminato.
Sebbene questa situazione sia alquanto remota ed attualmente ancora lontana, è bene chiarire di cosa si tratta.
Che cosa è dm-verity (la definizione “semplice”)?
E’ una funzionalità di Android 4.4 che protegge le parti più delicate del sistema da accessi potenzialmente non desiderati da parte di possibili malware che si identificano nella categoria dei rootkit.
Come diretta conseguenza, però, ciò potrebbe comportare – quando la funzionalità è attiva ed il bootloader del dispositivo Android è bloccato – anche l’impossibilità di “rootare” il proprio telefono ed installare una ROM cucinata.
Che cosa è dm-verity (la definizione “difficile”)?
dm-verity è una feature sperimentale introdotta nel kernel predefinito di Android 4.4, che permette di eseguire delle verifiche sul filesystem a livello di blocco e non a livello di file. Scendendo ancor di più nel tecnico, in dm-verity ad ogni blocco del filesystem (di norma della dimensione di 4KB) del dispositivo viene associato un codice hash – precisamente uno SHA-256; i codici hash di ogni blocco vengono paginati in una struttura ad albero, che farà capo all’hash posto alla cima – il root hash.
Prendete tutto questo meccanismo e immaginatelo in funzione su un filesystem Android: il dm-verity, tramite una chiave pubblica pre-caricata e verificata (eventualmente dal produttore del dispositivo), effettuerà il controllo sull’hash radice per il controllo sull’integrità del filesystem soltanto quando il sistema accede – o tenta di accedere – ad un blocco che vi appartiene e, per eliminare eventuali lag, tale verifica sarà svolta in parallelo con una comune operazione di lettura.
Qualora la verifica di integrità dovesse fallire, di conseguenza ad un tentativo di modifica di un file da parte di un’app, verrà generato un errore di scrittura dal kernel con la conseguenza diretta che l’applicazione (o il demone) che ha tentato la scrittura andrà in errore e, se lo scheduler considera l’errore “critico”, l’app stessa fallirà l’operazione e potrebbe smettere di funzionare.
Ovviamente tutto questo succede se si prova ad accedere ad una parte “protetta” del sistema (quale potrebbero essere una parte della directory /system o la directory /boot) da un dispositivo con bootloader bloccato e dm-verity attivo.
Inutile specificarlo, dm-verity è stato implementato con in mente la lotta ai rootkit dannosi su Android anche se, in realtà, va ad intaccare altri aspetti che vedremo tra breve.
Perchè dm-verity?
Semplicemente per proteggere il proprio sistema operativo dall’azione di malware particolari che potrebbero andare ad intaccare parti delicatissime del sistema (come l’avvio stesso di esso), mettere in pericolo i propri dati personali e in qualche caso impedire addirittura l’avvio del sistema stesso. In sostanza, come già detto sopra, per proteggere Android 4.4 dai rootkit.
Scopo lodevole, quindi perché ne stiamo parlando?
Perché purtroppo, come in ogni cosa, c’è da considerare il rovescio della moneta. Che in questo caso, purtroppo, esiste. E riguarda strettamente la possibilità di installare ROM cucinate sui propri dispositivi.
Partendo dal presupposto che lo sblocco del bootloader è spesso rischioso (e tra l’altro non sempre possibile), l’azione combinata di dm-verity (che, come vi ho detto, verifica l’integrità del filesystem e in caso di accesso a zone di sistema “illegali” blocca il programma che tenta di modificarle) e di un bootloader bloccato potrebbe condurre alla totale impossibilità di procedere all’installazione di una custom ROM.
Lungi comunque dal parlare di catastrofismi, almeno al momento: la funzionalità dm-verity è ancora in fase sperimentale, non è attiva di default in Android 4.4 KitKat e, tra l’altro, molti dei dispositivi in commercio attualmente – ad esempio l’intera linea Nexus, molti dispositivi Sony e gli HTC e Samsung in versione “Google Play” – non brandizzati dispongono di bootloader sbloccabile; in questo caso, il “problema” collegato all’installazione ed allo sviluppo di una custom ROM non si pone.
Restano comunque da analizzare gli sviluppi successivi: personalmente dubito che Google imporrà il blocco all’installazione delle custom ROM anche se, ad onor del vero, c’è da ammettere che un meccanismo di sicurezza quale è il dm-verity sarebbe ottimale per evitare tanti disagi creati proprio dai rootkit.
Staremo a vedere.
