GKI-Modulpartition implementieren

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 befinden, namens system_dlkm. GKI-Module werden von Google mit dem Kernel signiert und sind nur mit der GKI kompatibel, mit der sie erstellt wurden. Es gibt keine ABI-Stabilität zwischen GKI und GKI-Modulen. zum Laden von Modulen GKI- und GKI-Module erstellt und aktualisiert werden, miteinander verbinden.

Unterstützung für system_dklm-Partitionen implementieren

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

  • Von Google zur Build-Zeit signierte Kernelmodule
  • depmod Artefakte

Build system_dlkm

Das Erstellen von system_dlkm ist mit dem Erstellen anderer dynamischer Partitionen vergleichbar. Führen Sie die folgenden Schritte aus, um system_dlkm zu Ihrem Build hinzuzufügen:

  1. Fügen Sie 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 system_dlkm zur Partitionsliste 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 der Datei device.mk die folgende Zeile für Ihr Gerät hinzu:

    AB_OTA_PARTITIONS += system_dlkm

Kernelmodule identifizieren, 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 Kernelmodule im GKI-Build für die Zielarchitektur identifizieren und diese beim Plattformbuild als Quelle für die system_dlkm-Partition angeben.

Für Android 13

Verweisen Sie BOARD_SYSTEM_DLKM_SRC auf einen Ordner, der die erforderlichen GKI-Module enthält Kernel-Objektdateien für das Gerät als Eingabe für das zu generierende Build-System die Partition system_dlkm. Beispiel:

Stellen Sie die Quelle der GKI-Module in einem Ordner bereit und verweisen Sie auf BOARD_SYSTEM_DLKM_SRC in diesem Ordner. Beispiel:

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

Zum Zeitpunkt der Build-Erstellung werden die in BOARD_SYSTEM_DLKM_SRC aufgeführten Module an folgendem Ort installiert: $ANDROID_PRODUCT_OUT/system_dlkm.

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 auf das das Makro BOARD_SYSTEM_KERNEL_MODULES verweist. Bei der Erstellung dieser Module sind in $ANDROID_PRODUCT_OUT/system_dlkm installiert. Jedes Modul in Partition vendor_dlkm, die von den Modulen in system_dlkm abhängig ist Partition generiert korrekte Verweise in modules.dep-Datei für die Partition vendor_dlkm. Aufgrund der partitionierten Abhängigkeiten, von modules.dep, wenn ein Anbietermodul wird geladen, jedes erforderliche GKI-Modul wird automatisch geladen.

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

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

system_dlkm zur Laufzeit bereitstellen

Je nachdem, welches Dateisystem als schreibgeschütztes Dateisystem verwendet wird, fügen Sie Folgendes in 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

Bereitstellung von Partitionen und Laden von Modulen

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

Ein Anbieterprozess, z. B. ein .rc-Skript, kann dann die Kernelmodule laden basierend auf der in modules.load angegebenen Reihenfolge. Der Zulieferunternehmen muss den symbolischen Link /system/lib/modules, um die Module zu laden. Bei Bedarf können die Module auch später vom Anbieterprozess geladen werden.

SELinux

Jede Datei in der system_dlkm-Partition ist mit dem Dateikontext von system_dlkm_file gekennzeichnet. So laden Sie die Datei mit den GKI-Modulen in die Partition system_dlkm: Der Anbieterprozess, der für das Laden der Module verantwortlich ist, benötigt eine sepolicy in die Domain des Anbieters.

Beispiel: dlkm_loader, das von Cuttlefish zum Laden von GKI-Modulen verwendet wird, hat in der Richtliniendatei unter shared/sepolicy/vendor/dlkm_loader.te die folgenden Berechtigungen:

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;

Partition „system-dlkm“ validieren

Google stellt einen GKI VTS-Testfall zur Verfügung, um die system_dlkm-Partition zu prüfen. Bis den Test manuell mit dem folgenden atest-Befehl aufrufen:

  atest -c vts_dlkm_partition_test