Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Verifica avvio

L'avvio verificato richiede la verifica crittografica di tutto il codice eseguibile e dei dati che fanno parte della versione di Android da avviare prima dell'utilizzo. Ciò include il kernel (caricato dalla partizione di boot ), l'albero dei dispositivi (caricato dalla partizione dtbo ), la partizione di system , la partizione del vendor e così via.

Le partizioni piccole, come boot e dtbo , che vengono lette una sola volta vengono in genere verificate caricando l'intero contenuto in memoria e quindi calcolando il suo hash. Questo valore di hash calcolato viene quindi confrontato con il valore di hash previsto . Se il valore non corrisponde, Android non verrà caricato. Per ulteriori dettagli, consultare Boot Flow .

Le partizioni più grandi che non si adattano alla memoria (come i file system) possono usare un albero di hash in cui la verifica è un processo continuo mentre i dati vengono caricati in memoria. In questo caso, l'hash radice dell'albero hash viene calcolato durante il runtime e viene confrontato con il valore hash radice previsto . Android include il driver dm-verity per verificare partizioni più grandi. Se a un certo punto l'hash root calcolato non corrisponde al valore hash root previsto , i dati non vengono utilizzati e Android entra in uno stato di errore. Per ulteriori dettagli, consultare corruzione dm-verity .

Gli hash previsti vengono in genere archiviati alla fine o all'inizio di ciascuna partizione verificata, in una partizione dedicata o in entrambi. Fondamentalmente, questi hash sono firmati (direttamente o indirettamente) dalla radice della fiducia. Ad esempio, l'implementazione di AVB supporta entrambi gli approcci, vedere Avvio verificato Android per i dettagli.

Protezione dal rollback

Anche con un processo di aggiornamento completamente sicuro, è possibile che un exploit del kernel Android non persistente installi manualmente una versione precedente e più vulnerabile di Android, si riavvii nella versione vulnerabile e quindi utilizzi quella versione Android per installare un exploit persistente. Da lì l'attaccante possiede permanentemente il dispositivo e può fare qualsiasi cosa, inclusa la disabilitazione degli aggiornamenti.

La protezione contro questa classe di attacchi si chiama Rollback Protection . La protezione da rollback viene in genere implementata utilizzando l'archiviazione a prova di manomissione per registrare la versione più recente di Android e rifiutando di avviare Android se è inferiore alla versione registrata. Le versioni vengono generalmente monitorate in base alla partizione.

Per ulteriori dettagli su come AVB gestisce le protezioni di rollback, consultare il README di AVB.

Gestione degli errori di verifica

La verifica può avere esito negativo al momento dell'avvio (ad esempio, se l'hash calcolato sulla partizione di boot non corrisponde all'hash previsto) o in fase di esecuzione (ad esempio, se dm-verity rileva un errore di verifica sulla partizione di system ). Se la verifica non riesce all'avvio, il dispositivo non può avviarsi e l'utente finale deve eseguire i passaggi per ripristinare il dispositivo.

Se la verifica fallisce in fase di esecuzione, il flusso è un po 'più complicato. Se il dispositivo utilizza dm-verity, deve essere configurato in modalità restart . In modalità restart , se si verifica un errore di verifica, il dispositivo viene immediatamente riavviato con un flag specifico impostato per indicare il motivo. Il boot loader dovrebbe notare questo flag e cambiare dm-verity per utilizzare la modalità Errore I / O ( eio ) e rimanere in questa modalità fino a quando non è stato installato un nuovo aggiornamento.

Quando si avvia in modalità eio , il dispositivo mostra una schermata di errore che informa l'utente che è stata rilevata la corruzione e che il dispositivo potrebbe non funzionare correttamente. Lo schermo viene visualizzato fino a quando l'utente non lo elimina. In modalità eio il driver dm- eio non riavvierà il dispositivo se si verifica un errore di verifica, invece viene restituito un errore EIO e l'applicazione deve gestire l'errore.

L'intenzione è che il programma di aggiornamento del sistema sia in esecuzione (in modo da poter installare un nuovo sistema operativo senza errori di corruzione) o che l'utente possa ottenere il maggior numero possibile di dati dal dispositivo. Una volta installato il nuovo sistema operativo, il boot loader nota il sistema operativo appena installato e torna alla modalità di restart .