Implementieren Sie eine GKI-Modulpartition

GKI und GKI-Module können unabhängig vom Rest der Partition aktualisiert werden, da sich GKI-Module auf einer separaten dynamischen Partition im Super-Image namens system_dlkm befinden. GKI-Module werden von Google mit dem Kernel-Build-Time-Schlüsselpaar signiert und sind nur mit dem GKI kompatibel, mit dem sie erstellt wurden. Es gibt keine ABI-Stabilität zwischen GKI und GKI-Modulen; Damit Module während der Laufzeit korrekt geladen werden, müssen GKI- und GKI-Module gemeinsam erstellt und aktualisiert werden.

Implementieren Sie die Partitionsunterstützung system_dklm

Die system_dlkm Partition befindet sich als weitere dynamische Partition in der Superpartition. Diese Partition kann enthalten:

  • Zur Buildzeit von Google signierte Kernelmodule
  • depmod Artefakte

Erstellen Sie system_dlkm

Das Erstellen system_dlkm ist ein ähnlicher Prozess wie das Erstellen anderer dynamischer Partitionen. Führen Sie die folgenden Schritte aus, um system_dlkm zu Ihrem Build hinzuzufügen:

  1. Fügen Sie in BoardConfig.mk die folgenden Einträge hinzu:

    BOARD_USES_SYSTEM_DLKMIMAGE := true
BOARD_SYSTEM_DLKMIMAGE_FILE_SYSTEM_TYPE := $(TARGET_RO_FILE_SYSTEM_TYPE)
TARGET_COPY_OUT_SYSTEM_DLKM := system_dlkm

  2. Fügen Sie in der Partitionsliste system_dlkm hinzu: BOARD_GOOGLE_SYSTEM_DYNAMIC_PARTITIONS_PARTITION_LIST := system_dlkm

  3. (Optional) Fügen Sie für A/B- und virtuelle A/B-Geräte die folgende Zeile in der Datei device.mk für Ihr Gerät hinzu:

    AB_OTA_PARTITIONS += system_dlkm

Identifizieren Sie Kernelmodule, die in system_dlkm kopiert werden sollen

Damit Module zur Laufzeit erfolgreich geladen werden können, müssen GKI- und GKI-Module zusammen erstellt werden. Daher müssen Sie Kernel-Module im GKI-Build für die Zielarchitektur identifizieren und diese während des Plattform-Builds als Quelle für die system_dlkm Partition bereitstellen.

Für Android 13

Verweisen Sie BOARD_SYSTEM_DLKM_SRC auf einen Ordner, der die erforderlichen Kernelobjektdateien der GKI-Module für das Gerät als Eingabe für das Build-System zum Generieren der system_dlkm Partition enthält. Zum Beispiel:

Stellen Sie die GKI-Modulquelle in einem Ordner bereit und verweisen Sie BOARD_SYSTEM_DLKM_SRC auf diesen Ordner. Zum Beispiel:

  BOARD_SYSTEM_DLKM_SRC := kernel/prebuilts/5.10/arm64/system_dlkm_staging

Zur Erstellungszeit werden die in BOARD_SYSTEM_DLKM_SRC aufgeführten Module in $ANDROID_PRODUCT_OUT/system_dlkm installiert.

Für Android 14

Wir haben die Implementierung optimiert, indem die Makros ( BOARD_*_KERNEL_MODULES ) für andere *_dlkm Partitionen verwendet werden. Die Liste der erforderlichen GKI-Module für das Gerät sollte durch das Makro BOARD_SYSTEM_KERNEL_MODULES referenziert werden. Zur Erstellungszeit werden diese Module in $ANDROID_PRODUCT_OUT/system_dlkm installiert. Jedes Modul in der Partition vendor_dlkm , das Abhängigkeiten von den Modulen in der Partition „ system_dlkm aufweist, generiert korrekte Referenzen in der Datei „ modules.dep für die Partition vendor_dlkm “. Aufgrund dieser partitionsübergreifenden Abhängigkeiten, die durch modules.dep dargestellt werden, werden beim Laden eines Anbietermoduls automatisch alle erforderlichen GKI-Module geladen.

So installieren Sie beispielsweise alle GKI-Module auf system_dlkm Partition für den GKI arm64 -Kernel 5.15 aus vorgefertigten Versionen:

 BOARD_SYSTEM_KERNEL_MODULES := $(wildcard kernel/prebuilts/5.15/arm64/*.ko)

Mounten Sie system_dlkm zur Laufzeit

Abhängig vom Dateisystem, das als schreibgeschütztes Dateisystem verwendet wird, fügen Sie Folgendes in Ihre fstab ein, um die system_dlkm Partition zur Laufzeit bereitzustellen:

ext4 als schreibgeschütztes Dateisystem

  system_dlkm /system_dlkm ext4 noatime,ro,errors=panic wait,logical,first_stage_mount,slotselect,avb

erofs als schreibgeschütztes Dateisystem

  system_dlkm /system_dlkm erofs ro wait,logical,first_stage_mount,slotselect,avb

Partitionsmontage und Modulladen

Während first_stage_init wird die system_dlkm Partition im /system_dlkm als schreibgeschütztes Dateisystem bereitgestellt. Bei einem erfolgreichen Mount sind symbolische Links unter /system/lib/modules verfügbar, die auf /system_dlkm/lib/modules verweisen.

Ein Anbieterprozess, beispielsweise ein .rc Skript, kann dann die Kernelmodule basierend auf der in modules.load angegebenen Reihenfolge laden. Der Anbieterprozess muss den symbolischen Link /system/lib/modules verwenden, um die Module zu laden. Bei Bedarf kann der Vendor-Prozess die Module auch zu einem späteren Zeitpunkt laden.

SELinux

Jede Datei in der system_dlkm Partition ist mit dem Dateikontext von system_dlkm_file gekennzeichnet. Um die GKI-Moduldatei in die system_dlkm Partition zu laden, benötigt der für das Laden der Module verantwortliche Anbieterprozess eine sepolicy in der Anbieterdomäne.

Beispielsweise verfügt der von Cuttlefish zum Laden von GKI-Modulen verwendete dlkm_loader über die folgenden Berechtigungen in der Richtliniendatei unter shared/sepolicy/vendor/dlkm_loader.te :

allow dlkm_loader self:capability sys_module;
allow dlkm_loader system_dlkm_file:dir r_dir_perms;
allow dlkm_loader system_dlkm_file:file r_file_perms;
allow dlkm_loader system_dlkm_file:system module_load;

Validieren Sie die system-dlkm-Partition

Google stellt einen GKI-VTS-Testfall zur Überprüfung der system_dlkm Partition bereit. Um den Test manuell aufzurufen, verwenden Sie den folgenden atest Befehl:

  atest -c vts_dlkm_partition_test