Buforowanie kompilacji

Począwszy od Androida 10 interfejs Neural Networks API (NNAPI) udostępnia funkcje umożliwiające buforowanie artefaktów kompilacji, co skraca czas potrzebny na kompilację przy uruchamianiu aplikacji. Dzięki tej funkcji buforowania sterownik nie musi zarządzać plikami w pamięci podręcznej ani ich czyścić. To opcjonalna funkcja, którą można wdrożyć za pomocą NN HAL 1.2. Więcej informacji o tej funkcji znajdziesz na stronie ANeuralNetworksCompilation_setCaching.

Sterownik może też stosować buforowanie kompilacji niezależnie od NNAPI. Można to zaimplementować niezależnie od tego, czy są używane funkcje buforowania NNAPI NDK i HAL. AOSP udostępnia bibliotekę narzędzi niskiego poziomu (mechanizm buforowania). Więcej informacji znajdziesz w artykule Wdrażanie mechanizmu buforowania.

Omówienie przepływu pracy

W tej sekcji opisano ogólne procesy z wdrożonym mechanizmem buforowania kompilacji.

Podano informacje o pamięci podręcznej i trafienie w pamięci podręcznej

  1. Aplikacja przekazuje katalog buforowania i sumę kontrolną unikalną dla modelu.
  2. Środowisko uruchomieniowe NNAPI wyszukuje pliki pamięci podręcznej na podstawie sumy kontrolnej, preferencji wykonania i wyników podziału.
  3. NNAPI otwiera pliki pamięci podręcznej i przekazuje uchwyty do sterownika za pomocą prepareModelFromCache.
  4. Sterownik przygotowuje model bezpośrednio z plików pamięci podręcznej i zwraca przygotowany model.

Podano informacje dotyczące pamięci podręcznej i jej brak

  1. Aplikacja przekazuje unikalną dla modelu sumę kontrolną i katalog do buforowania.
  2. Środowisko uruchomieniowe NNAPI wyszukuje pliki pamięci podręcznej na podstawie sumy kontrolnej, preferencji wykonania i wyników podziału, ale nie znajduje plików pamięci podręcznej.
  3. NNAPI tworzy puste pliki pamięci podręcznej na podstawie sumy kontrolnej, ustawień wykonania i partycjonowania, otwiera pliki pamięci podręcznej oraz przekazuje uchwyty i model do sterownika za pomocą prepareModel_1_2.
  4. Kompiluje on model, zapisuje informacje o buforowaniu w plikach pamięci podręcznej i zwraca przygotowany model.

Nie podano informacji o pamięci podręcznej

  1. Aplikacja wywołuje kompilację bez podawania żadnych informacji o pamięci podręcznej.
  2. Aplikacja nie przekazuje żadnych danych związanych z buforowaniem.
  3. Środowisko wykonawcze NNAPI przekazuje model do sterownika za pomocą prepareModel_1_2.
  4. Sterownik kompiluje model i zwraca przygotowany model.

Informacje o pamięci podręcznej

Informacje dotyczące pamięci podręcznej, które są udostępniane kierowcy, obejmują token i uchwyty plików pamięci podręcznej.

Token

token to token pamięci podręcznej o długości Constant::BYTE_SIZE_OF_CACHE_TOKEN, który identyfikuje przygotowany model. Ten sam token jest podawany podczas zapisywania plików pamięci podręcznej z użyciem funkcji prepareModel_1_2 i pobierania przygotowanego modelu za pomocą funkcji prepareModelFromCache. Klient kierowcy powinien wybrać token o małej częstotliwości kolizji. Kierowca nie może wykryć kolizji tokenów. Kolizja powoduje nieudane wykonanie lub udane wykonanie, które zwraca nieprawidłowe wartości wyjściowe.

Uchwyty plików pamięci podręcznej (dwa typy plików pamięci podręcznej)

Istnieją 2 typy plików pamięci podręcznej: pamięć podręczna danych i pamięć podręczna modelu.

  • Pamięć podręczna na dane: służy do buforowania stałych danych, w tym wstępnie przetworzonych i przekształconych buforów tensorów. Modyfikacja pamięci podręcznej danych nie powinna mieć wpływu na działanie aplikacji, poza generowaniem nieprawidłowych wartości wyjściowych podczas wykonywania.
  • Pamięć podręczna modelu: służy do buforowania danych wrażliwych, takich jak skompilowany wykonywalny kod maszynowy w rodzonym formacie binarnym urządzenia. Zmiana pamięci podręcznej modelu może wpłynąć na zachowanie sterownika, a złośliwy klient może wykorzystać to do wykonania czegoś wykraczającego poza przyznane uprawnienia. Dlatego przed przygotowaniem modelu z pamięci podręcznej sterownik musi sprawdzić, czy pamięć podręczna modelu nie jest uszkodzona. Więcej informacji znajdziesz w artykule Bezpieczeństwo.

Sterownik musi określić, jak informacje o pamięci podręcznej są rozprowadzane między 2 typami plików pamięci podręcznej, oraz podać, ile plików pamięci podręcznej jest potrzebnych dla każdego typu. Informacje te należy podać w getNumberOfCacheFilesNeeded.

Środowisko wykonawcze NNAPI zawsze otwiera uchwyty plików pamięci podręcznej z uprawnieniami zarówno do odczytu, jak i do zapisu.

Bezpieczeństwo

Podczas buforowania kompilacji pamięć podręczna modelu może zawierać dane wrażliwe na bezpieczeństwo, takie jak skompilowany wykonywalny kod maszynowy w natywnym formacie binarnym urządzenia. Jeśli nie są odpowiednio chronione, modyfikacja pamięci podręcznej modelu może wpłynąć na sposób działania sterownika. Treść pamięci podręcznej jest przechowywana w katalogu aplikacji, więc pliki pamięci podręcznej mogą być modyfikowane przez klienta. Wadliwy klient może przypadkowo uszkodzić pamięć podręczną, co z kolei szkodliwy klient może celowo wykorzystać do wykonania niezweryfikowanego kodu na urządzeniu. W zależności od cech urządzenia może to być problem z bezpieczeństwem. Dlatego przed przygotowaniem modelu z pamięci podręcznej sterownik musi być w stanie wykryć potencjalne uszkodzenie pamięci podręcznej modelu.

Jednym ze sposobów jest utrzymywanie przez kierowcę mapy z tokenu na hasz szyfrowany pamięci podręcznej modelu. Podczas zapisywania kompilacji w pamięci podręcznej sterownik może przechowywać token i sumę kontrolną pamięci podręcznej modelu. Podczas pobierania kompilacji z pamięci podręcznej sterownik sprawdza nowy hasz pamięci podręcznej modelu z zarejestrowaną parą tokena i skrótu. Mapowanie powinno być trwałe po ponownym uruchomieniu systemu. Sterownik może użyć usługi magazynu kluczy Androida, biblioteki narzędzi w framework/ml/nn/driver/cache lub innego odpowiedniego mechanizmu do wdrożenia menedżera map. Po aktualizacji sterownika należy ponownie zainicjować tego menedżera mapowania, aby zapobiec przygotowywaniu plików pamięci podręcznej z wcześniejszej wersji.

Aby zapobiec atakom typu od kontroli do momentu użycia (TOCTOU), sterownik musi obliczyć zarejestrowany hasz przed zapisaniem pliku w pliku i obliczyć go po skopiowaniu zawartości pliku do wewnętrznego bufora.

Ten przykładowy kod pokazuje, jak wdrożyć tę logikę.

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;
    }
}

Zaawansowane przypadki użycia

W niektórych zaawansowanych przypadkach sterownik wymaga dostępu do zawartości pamięci podręcznej (do odczytu lub zapisu) po wywołaniu kompilacji. Przykładowe przypadki użycia:

  • Kompilacja w czasie wykonywania: kompilacja jest opóźniona do momentu pierwszego wykonania.
  • Kompilacja wieloetapowa: najpierw wykonywana jest szybka kompilacja, a później (w zależności od częstotliwości użycia) opcjonalna kompilacja zoptymalizowana.

Aby uzyskać dostęp do zawartości pamięci podręcznej (do odczytu lub zapisu) po wywołaniu kompilacji, upewnij się, że sterownik:

  • Duplikaty uchwytów plików podczas wywołania funkcji prepareModel_1_2 lub prepareModelFromCache oraz odczytuje lub zaktualizuje zawartość pamięci podręcznej w późniejszym czasie.
  • Stosuje logikę blokowania plików poza zwykłym wywołaniem kompilacji, aby zapobiec jednoczesnemu odczytowi lub innym zapisom.

Wdróż mechanizm buforowania

Oprócz interfejsu buforowania kompilacji NN HAL 1.2 w katalogu frameworks/ml/nn/driver/cache znajdziesz też bibliotekę narzędzia do buforowania. Podkatalog nnCache zawiera kod trwałego miejsca na dane, który umożliwia sterownikowi implementację funkcji buforowania kompilacji bez używania funkcji buforowania NNAPI. Tę formę buforowania kompilacji można zastosować w dowolnej wersji interfejsu NN HAL. Jeśli sterownik zdecyduje się wdrożyć buforowanie odłączone od interfejsu HAL, sterownik jest odpowiedzialny za zwalnianie artefaktów z pamięci podręcznej, gdy nie są już potrzebne.