Treble-fähige Geräte müssen das Mounten der ersten Stufe ermöglichen, um sicherzustellen, dass init
Security-Enhanced Linux (SELinux) -Richtlinienfragmente laden kann, die über system
und vendor
verteilt sind. Dieser Zugriff ermöglicht auch das Laden von Kernelmodulen so schnell wie möglich nach dem Kernel-Boot.
Um eine frühe Bereitstellung durchzuführen, muss Android Zugriff auf die Dateisysteme haben, auf denen sich die Module befinden. Android 8.0 und höher unterstützt das Mounten von /system
, /vendor
oder /odm
bereits in der ersten Phase von init
(d. h. bevor SElinux initialisiert wird).
Fstab-Einträge
In Android 9 und niedriger können Geräte mithilfe von Device Tree Overlays (DTOs) fstab
Einträge für früh gemountete Partitionen angeben. In Android 10 und höher müssen Geräte fstab
Einträge für früh gemountete Partitionen mithilfe einer fstab
Datei in der Ramdisk der ersten Stufe angeben. Android 10 führt die folgenden fs_mgr
Flags zur Verwendung in der fstab
Datei ein:
-
first_stage_mount
gibt an, dass eine Partition durch die Initialisierung der ersten Stufe gemountet wird. -
logical
zeigt an, dass es sich um eine dynamische Partition handelt. -
avb= vbmeta-partition-name
gibt dievbmeta
Partition an. Die erste Stufe init initialisiert diese Partition, bevor andere Partitionen gemountet werden. Das Argument für dieses Flag kann weggelassen werden, wenn dievbmeta
Partition für den Eintrag bereits durch einen anderenfstab
Eintrag in einer vorherigen Zeile angegeben wurde.
Das folgende Beispiel zeigt fstab
Einträge zum Festlegen der system
, vendor
und product
als logische (dynamische) Partitionen.
#<dev> <mnt_point> <type> <mnt_flags options> <fs_mgr_flags> system /system ext4 ro,barrier=1 wait,slotselect,avb=vbmeta_system,logical,first_stage_mount vendor /vendor ext4 ro,barrier=1 wait,slotselect,avb=vbmeta,logical,first_stage_mount product /product ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount
In diesem Beispiel gibt der Anbieter die vbmeta
Partition mit dem fs_mgr
Flag avb=vbmeta
an, aber product
lässt das vbmeta
Argument weg, da der Anbieter vbmeta
bereits zur Liste der Partitionen hinzugefügt hat.
Geräte mit Android 10 und höher müssen die fstab
Datei auf der Ramdisk und in der vendor
ablegen.
Ramdisk
Der Speicherort der fstab
Datei auf der Ramdisk hängt davon ab, wie ein Gerät die Ramdisk verwendet.
Geräte mit einer Boot-Ramdisk müssen die fstab
Datei im Stammverzeichnis der Boot-Ramdisk ablegen. Wenn das Gerät sowohl über eine Boot-Ramdisk als auch über eine Wiederherstellungs-Ramdisk verfügt, sind keine Änderungen an der Wiederherstellungs-Ramdisk erforderlich. Beispiel:
PRODUCT_COPY_FILES += device/google/<product-name>/fstab.hardware:$(TARGET_COPY_OUT_RAMDISK)/fstab.$(PRODUCT_PLATFORM)
Geräte , die die Wiederherstellung als Ramdisk verwenden, müssen den Kernel-Befehlszeilenparameter androidboot.force_normal_boot=1
verwenden, um zu entscheiden, ob in Android gebootet oder mit dem Booten in die Wiederherstellung fortgefahren werden soll. Geräte, die mit Android 12 oder höher mit Kernel-Version 5.10 oder höher gestartet werden, müssen bootconfig verwenden, um den Parameter androidboot.force_normal_boot=1
zu übergeben. Bei diesen Geräten führt die Init-Initialisierung der ersten Stufe einen Root-Wechselvorgang zu /first_stage_ramdisk
durch, bevor die frühen Mount-Partitionen gemountet werden. Daher müssen Geräte die fstab
-Datei in $(TARGET_COPY_OUT_RECOVERY)/root/first_stage_ramdisk
ablegen. Beispiel:
PRODUCT_COPY_FILES += device/google/<product-name>/fstab.hardware:$(TARGET_COPY_OUT_RECOVERY)/root/first_stage_ramdisk/fstab.$(PRODUCT_PLATFORM)
Verkäufer
Alle Geräte müssen eine Kopie der fstab
Datei in /vendor/etc
ablegen. Dies liegt daran, dass die erste Init-Stufe die Ramdisk freigibt, nachdem die frühe Bereitstellung der Partitionen abgeschlossen ist, und einen Root-Wechselvorgang durchführt, um die Bereitstellung von /system
nach /
zu verschieben. Alle nachfolgenden Vorgänge, die fstab
Dateien zugreifen müssen, müssen daher die Kopie in /vendor/etc
verwenden. Beispiel:
PRODUCT_COPY_FILES += device/google/<product-name>/fstab.hardware:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.$(PRODUCT_PLATFORM)
Partitionen frühzeitig mounten, VBoot 1.0
Zu den Voraussetzungen für das frühe Mounten von Partitionen mit VBoot 1.0 gehören:
- Geräteknotenpfade müssen ihre
by-name
Symlinks infstab
und devicetree-Einträgen verwenden. Anstatt beispielsweise Partitionen mit/dev/block/mmcblk0pX
anzugeben, stellen Sie sicher, dass Partitionen benannt sind und der Geräteknoten/dev/block/…./by-name/{system,vendor,odm}
lautet. - Die für
PRODUCT_{SYSTEM,VENDOR}_VERITY_PARTITION
undCUSTOM_IMAGE_VERITY_BLOCK_DEVICE
in der Gerätekonfiguration für das Produkt (d. h. indevice/ oem / project /device.mk
) angegebenen Pfade müssen mit den entsprechenden Blockgeräteknoten übereinstimmen, dieby-name
in derfstab
/devicetree angegeben sind Einträge. Beispiel:PRODUCT_SYSTEM_VERITY_PARTITION := /dev/block/…./by-name/system PRODUCT_VENDOR_VERITY_PARTITION := /dev/block/…./by-name/vendor CUSTOM_IMAGE_VERITY_BLOCK_DEVICE := /dev/block/…./by-name/odm
- Einträge, die über Gerätebaum-Overlays bereitgestellt werden, dürfen sich in den
fstab
Dateifragmenten nicht wiederholen. Wenn Sie beispielsweise einen Eintrag zum Mounten von/vendor
im Gerätebaum angeben, darf diefstab
Datei diesen Eintrag nicht wiederholen. - Partitionen, die
verifyatboot
erfordern, dürfen nicht frühzeitig gemountet werden (dies wird nicht unterstützt). - Der Verity-Modus/-Status für verifizierte Partitionen muss in
kernel_cmdline
mit der Optionandroidboot.veritymode
angegeben werden (bestehende Anforderung).
Gerätebaum frühzeitig mounten, VBoot 1.0
In Android 8.x und höher analysiert init
den Gerätebaum und erstellt fstab
Einträge, um die Partition frühzeitig in der ersten Phase bereitzustellen. Ein fstab
Eintrag hat die Form:
src mnt_point type mnt_flags fs_mgr_flags
Devicetree-Eigenschaften sind so definiert, dass sie dieses Format nachahmen:
-
fstab
Einträge müssen sich unter/firmware/android/fstab
im Gerätebaum befinden und über eine kompatible Zeichenfolge verfügen, die aufandroid,fstab
gesetzt ist. - Jeder Knoten unter
/firmware/android/fstab
wird als einzelner früher Mountfstab
Eintrag behandelt. Für einen Knoten müssen die folgenden Eigenschaften definiert sein:-
dev
muss auf den Geräteknoten verweisen, der die Partitionby-name
darstellt -
type
muss der Dateisystemtyp sein (wie in denfstab
Dateien). -
mnt_flags
muss die durch Kommas getrennte Liste der Mount-Flags sein (wie infstab
-Dateien). -
fsmgr_flags
muss die Liste der Android-fs_mgr flags
sein (wie infstab
Dateien).
-
- A/B-Partitionen müssen über die Option
slotselect fs_mgr
verfügen. - dm-verity-fähige Partitionen müssen über die Option
verify fs_mgr
verfügen.
Beispiel: /system und /vendor auf N6P
Das folgende Beispiel zeigt die frühe Bereitstellung von Devicetree für system
und vendor
auf dem Nexus 6P:
/ { firmware { android { compatible = "android,firmware"; fstab { compatible = "android,fstab"; system { compatible = "android,system"; dev = "/dev/block/platform/soc.0/f9824900.sdhci/by-name/system"; type = "ext4"; mnt_flags = "ro,barrier=1,inode_readahead_blks=8"; fsmgr_flags = "wait,verify"; }; vendor { compatible = "android,vendor"; dev = "/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor"; type = "ext4"; mnt_flags = "ro,barrier=1,inode_readahead_blks=8"; fsmgr_flags = "wait"; }; }; }; }; };
Beispiel: /vendor auf Pixel
Das folgende Beispiel zeigt die frühe Bereitstellung von Devicetree für /vendor
auf Pixel (denken Sie daran, slotselect
für Partitionen hinzuzufügen, die A/B unterliegen):
/ { firmware { android { compatible = "android,firmware"; fstab { compatible = "android,fstab"; vendor { compatible = "android,vendor"; dev = "/dev/block/platform/soc/624000.ufshc/by-name/vendor"; type = "ext4"; mnt_flags = "ro,barrier=1,discard"; fsmgr_flags = "wait,slotselect,verify"; }; }; }; }; };
Partitionen frühzeitig mounten, VBoot 2.0
VBoot 2.0 ist Android Verified Boot (AVB) . Die Voraussetzungen für das frühe Mounten von Partitionen mit VBoot 2.0 sind:
- Die Geräteknotenpfade müssen ihre
by-name
Symlinks infstab
und devicetree-Einträgen verwenden. Anstatt beispielsweise Partitionen mit/dev/block/mmcblk0pX
anzugeben, stellen Sie sicher, dass die Partitionen benannt sind und der Geräteknoten/dev/block/…./by-name/{system,vendor,odm}
lautet. - Build-Systemvariablen (wie
PRODUCT_{SYSTEM,VENDOR}_VERITY_PARTITION
undCUSTOM_IMAGE_VERITY_BLOCK_DEVICE
), die für VBoot 1.0 verwendet werden, sind für VBoot 2.0 NICHT erforderlich. Stattdessen sollten in VBoot 2.0 eingeführte Build-Variablen (einschließlichBOARD_AVB_ENABLE := true
) definiert werden; Eine vollständige Konfiguration finden Sie unter Build System Integration for AVB . - Einträge, die über Gerätebaum-Overlays bereitgestellt werden, dürfen sich in den
fstab
Dateifragmenten nicht wiederholen. Wenn Sie beispielsweise einen Eintrag zum Mounten von/vendor
im Gerätebaum angeben, darf diefstab
Datei diesen Eintrag nicht wiederholen. - VBoot 2.0 unterstützt
verifyatboot
nicht, unabhängig davon, ob die frühe Bereitstellung aktiviert ist oder nicht. - Der Verity-Modus/-Status für verifizierte Partitionen muss in
kernel_cmdline
mit der Optionandroidboot.veritymode
angegeben werden (bestehende Anforderung). Stellen Sie sicher, dass die folgenden Korrekturen für AVB enthalten sind:
Devicetree frühzeitig mounten, VBoot 2.0
Die Konfiguration in Devicetree für VBoot 2.0 ist mit der in VBoot 1.0 identisch, mit den folgenden Ausnahmen:
- Das
fsmgr_flag
wird vonverify
aufavb
umgestellt. - Alle Partitionen mit AVB-Metadaten müssen im VBMeta-Eintrag im Gerätebaum enthalten sein, auch wenn die Partition nicht frühzeitig gemountet wird (z. B.
/boot
).
Beispiel: /system und /vendor auf N5X
Das folgende Beispiel zeigt eine frühe Devicetree-Bereitstellung für die system
und vendor
auf dem Nexus 5X. Beachten Sie, dass:
-
/system
wird mit AVB gemountet und/vendor
wird ohne Integritätsprüfung gemountet. - Da das Nexus 5X über keine
/vbmeta
Partition verfügt, befindet sich die vbmeta der obersten Ebene am Ende der/boot
-Partition (Einzelheiten finden Sie in der AOSP-Änderungsliste )./ { firmware { android { compatible = "android,firmware"; vbmeta { compatible = "android,vbmeta"; parts = "boot,system,vendor"; }; fstab { compatible = "android,fstab"; system { compatible = "android,system"; dev = "/dev/block/platform/soc.0/f9824900.sdhci/by-name/system"; type = "ext4"; mnt_flags = "ro,barrier=1,inode_readahead_blks=8"; fsmgr_flags = "wait,avb"; }; vendor { compatible = "android,vendor"; dev = "/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor"; type = "ext4"; mnt_flags = "ro,barrier=1,inode_readahead_blks=8"; fsmgr_flags = "wait"; }; }; }; }; };
Beispiel: /vendor auf Pixel
Das folgende Beispiel zeigt die frühe Montage /vendor
auf einem Pixel. Beachten Sie, dass:
- Im vbmeta-Eintrag werden weitere Partitionen angegeben, da diese Partitionen durch AVB geschützt sind.
- Alle AVB-Partitionen müssen enthalten sein, auch wenn nur
/vendor
frühzeitig gemountet wird. - Denken Sie daran,
slotselect
für Partitionen hinzuzufügen, die A/B unterliegen./ { vbmeta { compatible = "android,vbmeta"; parts = "vbmeta,boot,system,vendor,dtbo"; }; firmware { android { compatible = "android,firmware"; fstab { compatible = "android,fstab"; vendor { compatible = "android,vendor"; dev = "/dev/block/platform/soc/624000.ufshc/by-name/vendor"; type = "ext4"; mnt_flags = "ro,barrier=1,discard"; fsmgr_flags = "wait,slotselect,avb"; }; }; }; }; };