[Native Client] Una presentazione tecnica su NaCl

Di - 9 January 2012 - in

Come promesso in occasione dell’articolo sul porting del MAME su Chrome, oggi vi parliamo di Native Client, una piattaforma di Google che permette di eseguire codice nativo Intel x86 o ARM sul browser (attualmente Chrome).

Native Client viene abbreviato scherzosamente NaCl (alludendo al cloruro di sodio) e il progetto è completamente open source e multi piattaforma (Linux, Mac, Windows).

Native Client ha tre diversi scopi – vantaggi.
In primo luogo quello di portare il  web ad un nuovo livello di complessità. Questo perché dà agli sviluppatori la possibilità di creare applicazioni web che fanno uso di codice nativo (attualmente C e C++). Provate ad immaginarvi la possibilità di far girare applicazioni che fanno uso di grafica 3D complessa nel browser. Se fate fatica ad immaginarvi questo allora provate semplicemente a scaricare ed installare Bastion dal Chrome Web Store.
Oltre a ciò, un vantaggio (e al contempo uno scopo) evidente di NaCl è quello di innalzare il ruolo del browser a vero e proprio “appiattitore” delle limitazioni dovute ai diversi sistemi operativi. Con una tecnologia come NaCl le applicazioni programmate tramite codice nativo, possono essere eseguite sui tre maggiori sistemi operativi.
La terza caratteristica importante di NaCl è quella di trattare applicazioni complesse come applicazioni web, con tutti i vantaggi derivanti da questo tipo di approccio: distribuzione tramite Chrome Web Store e sicurezza tipica di una tecologia Sandbox (in questo caso doppia Sandbox).

Un progetto Native Client consiste tipicamente di una combinazione di JavaScript, HTML, CSS, e un modulo Native Client scritto in un linguaggio supportato dal compilatore Native Client (attualmente solo C e C++).
Lo strumento messo a disposizione da Google per lo sviluppo di progetti NaCl è Native Client Software Development Kit (SDK) che permette di creare applicazioni multi piattaforma ed è anch’esso un progetto completamente open source.

Come funziona Native Client

Prima di tutto alcune premesse.
Visto che, come abbiamo visto, una delle caratteristiche principali di questo progetto è quello di mantenere un alto livello di sicurezza, le applicazioni che girano sotto Native Client devono essere sprovviste di codice che può potenzialmente creare danno alla macchina dell’utente.
Per ottenere questo scopo, Native Client utilizza un duplice approccio basato su specifiche restrizioni delle API e un processo di compilazione modificato.
Nonostante Native Client utilizzi, su architettura x86, la tecnologia software-based fault isolation, riesce comunque a mantenere quasi inalterata la velocità nativa del codice (perdita del 5%), cosa che permette di effettuare rendering e calcoli importanti.

Un modulo Native Client compilato (.nexe) viene caricato all’interno di una pagina web tramite un elemento <embed>. L’applicazione web dunque viene definita dalla pagina .html e dai file .nexe.
A livello di runtime, o esecuzione, un modulo Native Client è semplicemente un set di codice macchina formattato secondo specifiche regole. Qualsiasi sia il linguaggio del codice sorgente originario, Native Client esegue la sequenza mostrata sotto.

Per evitare che qualsiasi risorsa di sistema venga compromessa, Native Client blocca le seguenti attività potenzialmente pericolose:

  • Manipolazione diretta di dispositivi o di file. Per le necessità di questo tipo vengono messe a disposizione apposite API che operano con il file system
  • Accesso diretto al sistema operativo
  • Uso di codice auto-modificante per nascondere il reale intento del codice (per esempio la scrittura di parti di memoria protette)

Dal codice nativo al browser

A questo punto vediamo come si comporta Native Client per interfacciarsi con il browser.
Pepper Plug-in API (PPAPI) (da cui potete immaginare il gioco di parole [NaCl – Pepper]) sono delle API open source e multi piattaforma per il browser. Lo scopo è appunto quello di permettere ad un modulo in linguaggio nativo di comunicare con il browser ed accedere alle risorse di sistema in modo sicuro e orientato alla multi piattaforma. La sicurezza si ottiene in particolare perché il modulo Native Client non può effettuare chiamate a livello di sistema operativo ma, questo tipo di risorse, vengono ottenute attraverso specifiche API fornite da Pepper.
Attraverso queste API è possibile:

  • Comunicare con il codice JavaScript nell’applicazione a partire dal codice nativo contenuto nel modulo NaCl
  • Eseguire FileIO
  • Riprodurre audio
  • Renderizzare grafica 3D

Il ruolo di Pepper è ben illustrato dall’immagine seguente

Struttura dell’applicazione

Un’applicazione NaCl si compone delle seguenti parti:

  • Applicazione JavScript / HTML  che fornisce l’interfaccia utente e i meccanismi di gestione degli eventi (event handling), così come le componenti HTML. Offre inoltre la possibilità di eseguire calcoli
  • Pepper API che permette la comunicazione tra il codice JavaScript e il modulo Native Client. Fornisce anche un interfaccia che permette al modulo NaCl di usare e creare risorse browser
  • Modulo Native Client che si occupa tipicamente dei calcoli numerici, renderizzazione di grafica 3D, manipolazione di grandi quantità di dati ed altri compiti gravosi.

Le parti descritte sopra sono suddivise nei seguenti file:

File HTML, CSS e JavaScript
In particolare, il file HTML contiene il tag <embed> per il modulo Native Client come nell’esempio seguente.


<embed name=”nacl_module”
           id=”hello_world”
           width=0 height=0
           src=”hello_world.nmf”
           type=”application/x-nacl” />
</script>


Modulo Native Client
Contiene il codice nativo compilato ed utilizza la libreria Pepper (inclusa nel SDK). Attualmente i soli linguaggi supportati sono C e C++. L’estensione del file compilato è .nexe

Manifest file
Un file che specifica come caricare i moduli per i diversi processori. Attualmente NaCl non è indipendente dal processore e quindi è necessario compilare versioni separate di codice per le varie istruzioni dei processori come ad esempio x86-32, x86-64, ecc… L’estensione del file manifest è .nmf

Nota: la roadmap del progetto prevede che la futura versione degli eseguibili Native Client siano indipendenti dal processore. Questo progetto, già in fase di sviluppo, si chiama Portable Native Client (PNaCl – pronunciato “pinnacle”).

Creare un’applicazione Native Client

La creazione di un’applicazione NaCl consiste dei seguenti passaggi di massima.

  1. Installare la SDK di Native Client
  2. Installare Python (se non già disponibile sul vostro sistema operativo)
  3. Scrivere l’applicazione:
    • Creare l’interfaccia utente tramite HTML, CSS, JavaScript
    • Verificare che le librerie necessarie all’applicazione girino con Native Client. Esiste un repository specifico di librerie di uso comune
    • Creare il modulo Native Client e compilarlo usando la toolchain NaCl contnuta nel SDK
  4. Testare l’applicazione
  5. Distribuire l’applicazione sul Chrome Web Store

Sul sito ufficiale è disponibile un tutorial dettagliato sulla creazione di applicazioni Native Client

Concludiamo con il contenuto del SDK Native Client:

  • Toolchain basato su GNU (gcc, g++, as, ld, gdb, ecc…)
  • API per le librerie (Pepper, POSIX)
  • Template e script vari
  • Script Scons http://en.wikipedia.org/wiki/SCons e file di configurazione per effettuare il building di applicazioni Native Client
  • Esempi
  • Documentazione

Se avete voglia di approfondire l’argomento, vi consiglio di visitare il sito ufficiale di Native Client. Qui potrete trovare molte risorse tra cui la technical overview che ha ispirato questo articolo, tutorial, faq, application gallery, documentazione varia e molto, molto altro ancora.
Chiaramente Google sta puntando molto su questo progetto che, se dovesse prendere piede e svilupparsi bene, rappresenterebbe davvero un passo in avanti “epocale” non solo per il web ma per le applicazioni in generale. Davvero un ponte che unisce applicazioni tradizionali e applicazioni web, il tutto nello spirito della portabilità tra i sistemi operativi.

Leave a Reply

Gabriele Visconti Articolo scritto da

Editor in Chief per Engeene.
Appassionato di Linux, FOSS, videogame e, da poco, di cucina. Parla quattro lingue ed ama leggere libri in lingua inglese.

Contatta l'autore

Previous post:

Next post: