Avviare Linux da Google Drive, un esperimento audace

Un amico vi sfida dimostrandovi di essere riuscito ad eseguire il boot di una distribuzione Linux tramite NFS (Network File System)? Rispondete spiegando di essere in grado di avviare Linux da Google Drive. Vi sembra impossibile? A riuscire nell’impresa è un ricercatore indipendente che spiega nel dettaglio i passaggi seguiti e illustra le tante problematiche incontrate lungo il cammino.

Conoscere il processo di avvio di Linux

Per comprendere la complessità dell’impresa, che ha permesso di avviare Linux da Google Drive, è essenziale conoscere il processo di boot del “pinguino”.

Come nel caso di qualunque altro sistema operativo, il firmware (BIOS/UEFI) avvia il bootloader che, a sua volta, dispone il caricamento del kernel Linux. Il kernel decomprime un filesystem temporaneo nella RAM (initramfs) contenente gli strumenti per montare il filesystem reale. Il kernel, infine, monta il filesystem reale e passa il controllo al sistema di inizializzazione del sistema operativo.

Con l’obiettivo di predisporre il boot da Google Drive, il ricercatore ha provveduto a usare un meccanismo initramfs personalizzato.

Preparazione dell’ambiente e la “scommessa” su FUSE

L’autore del progetto ha utilizzato Arch Linux come base dell’esperimento per avviare il sistema operativo dalla piattaforma Google Drive. Ha clonato il repository Dracut, uno strumento per creare un initramfs personalizzato, quindi ha creato un container Docker per costruire l’ambiente di sviluppo.

Lo sviluppatore ha messo a punto un modulo Dracut per includere i file binari necessari a supportare FUSE (Filesystem in Userspace).

FUSE è un’interfaccia software per sistemi operativi Unix e Unix-like che permette agli utenti sprovvisti di privilegiati elevati di creare i propri file system senza modificare il codice del kernel. All’accesso del file system, il kernel invia le richieste a FUSE: quest’ultimo le elabora in tempo reale e fornisce i risultati al kernel. Il kernel Linux, quindi, presenta i risultati all’utente come se provenissero da un file system tradizionale.

Perché FUSE è essenziale per avviare Linux da Google Drive

FUSE fornisce un’API di alto livello, semplificando lo sviluppo di file system personalizzati rispetto alla programmazione diretta del kernel. Il programma google-drive-ocamlfuse, pubblicato su GitHub, utilizza FUSE per presentare Google Drive come un file system locale. L’inclusione dei binari FUSE a livello di initramfs permette di montare Google Drive nelle prime fasi del processo di avvio.

Tutte le operazioni di lettura/scrittura (I/O) tra il sistema operativo e Google Drive sono gestite da FUSE che si occupa di tradurre tramite API (Application Programming Interface) le chiamate locali in operazioni “comprensibili” al servizio di storage cloud dell’azienda di Mountain View.

Grazie a FUSE, tutta la complessità delle operazioni di rete e delle API di Google Drive è automaticamente nascosta. In questo modo gli utenti hanno accesso a un’interfaccia standard a livello di file system.

Creazione dell’initramfs personalizzato e dell’immagine EFI

L’autore dell’ambizioso progetto spiega che il semplice script Dracut riportato di seguito, ha permesso di aggiungere all’initramfs i binari necessari per FUSE:

#!/bin/bash
check() {
    require_binaries fusermount fuseiso mkisofs || return 1
    return 0
}

depends() {
    return 0
}

install() {
    inst_multiple fusermount fuseiso mkisofs
    return 0
}

EFI (Extensible Firmware Interface) è un’interfaccia tra il firmware del sistema e il sistema operativo. Un’immagine EFI è un file eseguibile che contiene le istruzioni necessarie per avviare il sistema operativo in un ambiente UEFI. Usando ancora Dracut, il ricercatore ha predisposto un’immagine EI personalizzata includendo moduli e driver specifici:

./dracut.sh --kver 6.9.6-arch1-1 \
    --uefi efi_firmware/EFI/BOOT/BOOTX64.efi \
    --force -l -N --no-hostonly-cmdline \
    --modules "base bash fuse shutdown network" \
    --add-drivers "target_core_mod target_core_file e1000" \
    --kernel-cmdline "ip=dhcp rd.shell=1 console=ttyS0"

L’autore ha incontrato diverse difficoltà, tra cui anche problemi con i link simbolici, prestazioni estremamente lente e anomalie con i permessi e gli attributi dei file.

Utilizzando file di configurazione e token di Google Drive nell’initramfs, aggiungendo un certificato TLS, utilizzando driver di rete “ad hoc” e allestendo un bind mont (caratteristica Linux che permette di montare un file o una directory in una posizione diversa nel file system, senza creare una copia fisica dei dati), il ricercatore ha risolto la maggior parte delle problematiche emerse.

Quali sono i possibili sviluppi futuri

L’esperimento, sebbene al momento resti sostanzialmente un esercizio accademico, apre la strada a interessanti possibilità:

• Avvio di Linux da altri servizi remoti
• Utilizzo di repository Git come file system root, permettendo il tracciamento delle modifiche
• Potenziali applicazioni in ambienti cloud native e di edge computing

Quanto realizzato dimostra, ancora una volta, la flessibilità e adattabilità delle soluzioni Linux, utili per spingere al limite ciò che è possibile fare sul versante dei sistemi operativi e dell’archiviazione cloud. Sebbene non sia ancora una soluzione pratica per l’uso quotidiano, il progetto descrive il grande potenziale delle future innovazioni nel campo dell’integrazione tra sistemi operativi e servizi cloud.

Va tenuto in debita considerazione che l’avvio di una distribuzione Linux via NFS o tramite Google Drive, richiede una connessione di rete veloce. Nel primo caso, se ci si limita alla rete locale, le cose funzionano con una Multigigabit Ethernet; diversamente è necessario anche un collegamento ultrabroadband fornito da un operatore di telecomunicazioni.

Credit immagine in apertura: Copilot Designer.