Memorizzazione nella cache di compilazione

A partire da Android 10, l'API Neural Networks (NNAPI) fornisce funzioni per supportare la memorizzazione nella cache degli elementi di compilazione, il che riduce il tempo impiegato per la compilazione all'avvio di un'app. Grazie a questa funzionalità di memorizzazione nella cache, il conducente non deve gestire o ripulire i file memorizzati nella cache. Questa è una funzionalità facoltativa che può essere implementata con NN HAL 1.2. Per ulteriori informazioni su questa funzione, consulta ANeuralNetworksCompilation_setCaching.

Il driver può anche implementare la memorizzazione nella cache della compilazione indipendentemente da NNAPI. Questa funzionalità può essere implementata indipendentemente dall'utilizzo o meno delle funzionalità di memorizzazione nella cache di HAL e NDK NNAPI. AOSP fornisce una libreria di utilità di basso livello (un motore di memorizzazione nella cache). Per ulteriori informazioni, consulta Implementazione di un motore di memorizzazione nella cache.

Panoramica del flusso di lavoro

Questa sezione descrive i flussi di lavoro generali con la funzionalità di memorizzazione nella cache della compilazione implementata.

Informazioni sulla cache fornite e hit della cache

  1. L'app passa una directory di memorizzazione nella cache e un checksum univoco per il modello.
  2. Il runtime NNAPI cerca i file della cache in base al checksum, alla preferenza di esecuzione e al risultato del partizionamento e li trova.
  3. NNAPI apre i file della cache e passa i handle al driver con prepareModelFromCache.
  4. Il driver prepara il modello direttamente dai file della cache e lo restituisce.

Informazioni sulla cache fornite e mancata corrispondenza della cache

  1. L'app passa un checksum univoco per il modello e una directory per la memorizzazione nella cache.
  2. Il runtime NNAPI cerca i file di memorizzazione nella cache in base al checksum, alle preferenze di esecuzione e al risultato del partizionamento e non li trova.
  3. NNAPI crea file della cache vuoti in base al checksum, alla preferenza di esecuzione e al partizionamento, apre i file della cache e passa gli handle e il modello al driver con prepareModel_1_2.
  4. Il driver compila il modello, scrive le informazioni sulla memorizzazione nella cache nei file della cache e restituisce il modello preparato.

Informazioni sulla cache non fornite

  1. L'app richiama la compilazione senza fornire informazioni sulla memorizzazione nella cache.
  2. L'app non passa nulla relativo alla memorizzazione nella cache.
  3. Il runtime NNAPI passa il modello al driver con prepareModel_1_2.
  4. Il driver compila il modello e restituisce il modello preparato.

Informazioni sulla cache

Le informazioni sulla memorizzazione nella cache fornite a un driver consistono in un token e in handle dei file della cache.

Token

Il token è un token di memorizzazione nella cache di lunghezza Constant::BYTE_SIZE_OF_CACHE_TOKEN che identifica il modello preparato. Lo stesso token viene fornito quando si salvano i file della cache con prepareModel_1_2 e si recupera il modello preparato con prepareModelFromCache. Il cliente del conducente deve scegliere un token con un tasso di collisione basso. Il driver non riesce a rilevare una collisione di token. Una collisione si traduce in un'esecuzione non riuscita o in un'esecuzione riuscita che produce valori di output errati.

Handle dei file della cache (due tipi di file della cache)

I due tipi di file della cache sono cache dei dati e cache del modello.

  • Cache di dati:da utilizzare per memorizzare nella cache i dati costanti, inclusi i buffer di tensori pre-elaborati e trasformati. Una modifica alla cache dei dati non deve avere un effetto peggiore della generazione di valori di output errati al momento dell'esecuzione.
  • Cache del modello:da utilizzare per memorizzare nella cache i dati sensibili alla sicurezza, come il codice macchina compilato eseguibile nel formato binario nativo del dispositivo. Una modifica alla cache del modello potrebbe influire sul comportamento di esecuzione del driver e un cliente malintenzionato potrebbe utilizzarla per eseguire operazioni oltre l'autorizzazione concessa. Pertanto, il driver deve verificare se la cache del modello è danneggiata prima di preparare il modello dalla cache. Per ulteriori informazioni, consulta Sicurezza.

Il driver deve decidere come vengono distribuite le informazioni della cache tra i due tipi di file della cache e indicare quanti file della cache sono necessari per ogni tipo con getNumberOfCacheFilesNeeded.

Il runtime NNAPI apre sempre gli handle dei file della cache con le autorizzazioni di lettura e scrittura.

Sicurezza

Nella memorizzazione nella cache della compilazione, la cache del modello potrebbe contenere dati sensibili alla sicurezza, come il codice macchina eseguibile compilato nel formato binario nativo del dispositivo. Se non è protetta correttamente, una modifica alla cache del modello potrebbe influire sul comportamento di esecuzione del driver. Poiché i contenuti della cache sono archiviati nella directory dell'app, i file della cache sono modificabili dal client. Un client con bug potrebbe corrompere accidentalmente la cache e un client malintenzionato potrebbe utilizzarla intenzionalmente per eseguire codice non verificato sul dispositivo. A seconda delle caratteristiche del dispositivo, questo potrebbe essere un problema di sicurezza. Pertanto, il driver deve essere in grado di rilevare la potenziale corruzione della cache del modello prima di preparare il modello dalla cache.

Un modo per farlo è che il driver gestisca una mappa dal token a un hash criptato della cache del modello. Il driver può memorizzare il token e l'hash della cache del modello quando salva la compilazione nella cache. Il driver controlla il nuovo hash della cache del modello con la coppia di token e hash registrata quando recupera la compilazione dalla cache. Questa mappatura deve essere persistente anche dopo i riavvii del sistema. Il driver può utilizzare il servizio Android Keystore, la libreria di utilità in framework/ml/nn/driver/cache, o qualsiasi altro meccanismo adatto per implementare un gestore di mappatura. Al termine dell'aggiornamento del driver, questo gestore di mappatura deve essere reinizializzato per evitare la preparazione dei file della cache di una versione precedente.

Per evitare attacchi di tipo time-of-check to time-of-use (TOCTOU), il driver deve calcolare l'hash registrato prima di salvare in file e calcolare il nuovo hash dopo aver copiato i contenuti del file in un buffer interno.

Questo codice di esempio mostra come implementare questa logica.

bool saveToCache(const sp<V1_2::IPreparedModel> preparedModel,
                 const hidl_vec<hidl_handle>& modelFds, const hidl_vec<hidl_handle>& dataFds,
                 const HidlToken& token) {
    // Serialize the prepared model to internal buffers.
    auto buffers = serialize(preparedModel);

    // This implementation detail is important: the cache hash must be computed from internal
    // buffers instead of cache files to prevent time-of-check to time-of-use (TOCTOU) attacks.
    auto hash = computeHash(buffers);

    // Store the {token, hash} pair to a mapping manager that is persistent across reboots.
    CacheManager::get()->store(token, hash);

    // Write the cache contents from internal buffers to cache files.
    return writeToFds(buffers, modelFds, dataFds);
}

sp<V1_2::IPreparedModel> prepareFromCache(const hidl_vec<hidl_handle>& modelFds,
                                          const hidl_vec<hidl_handle>& dataFds,
                                          const HidlToken& token) {
    // Copy the cache contents from cache files to internal buffers.
    auto buffers = readFromFds(modelFds, dataFds);

    // This implementation detail is important: the cache hash must be computed from internal
    // buffers instead of cache files to prevent time-of-check to time-of-use (TOCTOU) attacks.
    auto hash = computeHash(buffers);

    // Validate the {token, hash} pair by a mapping manager that is persistent across reboots.
    if (CacheManager::get()->validate(token, hash)) {
        // Retrieve the prepared model from internal buffers.
        return deserialize<V1_2::IPreparedModel>(buffers);
    } else {
        return nullptr;
    }
}

Casi d'uso avanzati

In alcuni casi d'uso avanzati, un driver richiede l'accesso ai contenuti della cache (lettura o scrittura) dopo la chiamata di compilazione. Ecco alcuni esempi di casi d'uso:

  • Compilazione Just-in-time: la compilazione viene ritardata fino alla prima esecuzione.
  • Compilazione in più fasi: inizialmente viene eseguita una compilazione rapida e in un secondo momento viene eseguita una compilazione ottimizzata facoltativa, a seconda della frequenza d'uso.

Per accedere ai contenuti della cache (lettura o scrittura) dopo la chiamata di compilazione, assicurati che il driver:

  • Duplica i handle dei file durante l'invocazione di prepareModel_1_2 o prepareModelFromCache e legge/aggiorna i contenuti della cache in un secondo momento.
  • Implementa la logica di blocco dei file al di fuori della normale chiamata di compilazione per impedire una scrittura contemporanea con una lettura o un'altra scrittura.

Implementa un motore di memorizzazione nella cache

Oltre all'interfaccia di memorizzazione nella cache della compilazione di NN HAL 1.2, puoi trovare anche una libreria di utilità per la memorizzazione nella cache nella directory frameworks/ml/nn/driver/cache. La nnCache sottodirectory contiene il codice di archiviazione persistente per consentire al driver di implementare la memorizzazione nella cache della compilazione senza utilizzare le funzionalità di memorizzazione nella cache NNAPI. Questa forma di memorizzazione nella cache della compilazione può essere implementata con qualsiasi versione dell'HAL NN. Se il driver sceglie di implementare la memorizzazione nella cache disconnessa dall'interfaccia HAL, è responsabile della liberazione degli elementi archiviati nella cache quando non sono più necessari.