Les appareils compatibles Treble doivent activer le montage de première étape pour garantir que init
peut charger les fragments de stratégie Linux à sécurité améliorée (SELinux) répartis sur les partitions system
et vendor
. Cet accès permet également le chargement des modules du noyau dès que possible après le démarrage du noyau.
Pour effectuer un montage anticipé, Android doit avoir accès aux systèmes de fichiers sur lesquels résident les modules. Android 8.0 et versions ultérieures prennent en charge le montage de /system
, /vendor
ou /odm
dès la première étape de init
(c'est-à-dire avant l'initialisation de SElinux).
Entrées Fstab
Sous Android 9 et versions antérieures, les appareils peuvent spécifier des entrées fstab
pour les premières partitions montées à l'aide de superpositions d'arborescence de périphériques (DTO) . Sous Android 10 et versions ultérieures, les appareils doivent spécifier des entrées fstab
pour les premières partitions montées à l'aide d'un fichier fstab
dans le disque virtuel de première étape. Android 10 introduit les indicateurs fs_mgr
suivants à utiliser dans le fichier fstab
:
-
first_stage_mount
indique qu'une partition sera montée par la première étape d'initialisation. -
logical
indique qu'il s'agit d'une partition dynamique . -
avb= vbmeta-partition-name
spécifie la partitionvbmeta
. La première étape d'initialisation initialise cette partition avant de monter d'autres partitions. L'argument de cet indicateur peut être omis si la partitionvbmeta
de l'entrée a déjà été spécifiée par une autre entréefstab
dans une ligne précédente.
L'exemple suivant montre les entrées fstab
pour définir les partitions system
, vendor
et product
en tant que partitions logiques (dynamiques).
#<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
Dans cet exemple, le fournisseur spécifie la partition vbmeta
à l'aide de l'indicateur fs_mgr
avb=vbmeta
, mais product
omet l'argument vbmeta
car le fournisseur a déjà ajouté vbmeta
à la liste des partitions.
Les appareils exécutant Android 10 et versions ultérieures doivent placer le fichier fstab
dans le disque virtuel et dans la partition vendor
.
Disque RAM
L'emplacement du fichier fstab
dans le disque virtuel dépend de la manière dont un périphérique utilise le disque virtuel.
Les périphériques dotés d'un disque virtuel de démarrage doivent placer le fichier fstab
à la racine du disque virtuel de démarrage. Si le périphérique dispose à la fois d'un disque virtuel de démarrage et d'un disque virtuel de récupération, aucune modification n'est requise sur le disque virtuel de récupération. Exemple:
PRODUCT_COPY_FILES += device/google/<product-name>/fstab.hardware:$(TARGET_COPY_OUT_RAMDISK)/fstab.$(PRODUCT_PLATFORM)
Les appareils qui utilisent la récupération comme disque virtuel doivent utiliser le paramètre de ligne de commande du noyau androidboot.force_normal_boot=1
pour décider s'ils doivent démarrer sous Android ou continuer à démarrer dans la récupération. Les appareils lancés avec Android 12 ou version ultérieure avec la version du noyau 5.10 ou ultérieure doivent utiliser bootconfig pour transmettre le paramètre androidboot.force_normal_boot=1
. Dans ces appareils, la première étape d'initialisation effectue une opération de basculement racine vers /first_stage_ramdisk
avant de monter les premières partitions de montage, les appareils doivent donc placer le fichier fstab
dans $(TARGET_COPY_OUT_RECOVERY)/root/first_stage_ramdisk
. Exemple:
PRODUCT_COPY_FILES += device/google/<product-name>/fstab.hardware:$(TARGET_COPY_OUT_RECOVERY)/root/first_stage_ramdisk/fstab.$(PRODUCT_PLATFORM)
Fournisseur
Tous les appareils doivent placer une copie du fichier fstab
dans /vendor/etc
. En effet, la première étape d'initialisation libère le disque virtuel après avoir terminé le montage initial des partitions et effectue une opération de changement de racine pour déplacer le montage de /system
vers /
. Toutes les opérations ultérieures nécessitant d'accéder aux fichiers fstab
doivent donc utiliser la copie dans /vendor/etc
. Exemple:
PRODUCT_COPY_FILES += device/google/<product-name>/fstab.hardware:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.$(PRODUCT_PLATFORM)
Montage précoce des partitions, VBoot 1.0
Les conditions requises pour monter des partitions avec VBoot 1.0 incluent :
- Les chemins des nœuds de périphériques doivent utiliser leurs liens symboliques
by-name
dans les entréesfstab
et devicetree. Par exemple, au lieu de spécifier des partitions à l'aide de/dev/block/mmcblk0pX
, assurez-vous que les partitions sont nommées et que le nœud de périphérique est/dev/block/…./by-name/{system,vendor,odm}
. - Les chemins indiqués pour
PRODUCT_{SYSTEM,VENDOR}_VERITY_PARTITION
etCUSTOM_IMAGE_VERITY_BLOCK_DEVICE
dans la configuration de l'appareil pour le produit (c'est-à-dire dansdevice/ oem / project /device.mk
) doivent correspondre aux nœuds de périphérique de bloc correspondants spécifiésby-name
dans lefstab
/devicetree entrées. Exemple :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
- Les entrées fournies via les superpositions de l'arborescence des périphériques ne doivent pas se répéter dans les fragments du fichier
fstab
. Par exemple, lorsque vous spécifiez une entrée à monter/vendor
dans l'arborescence des périphériques, le fichierfstab
ne doit pas répéter cette entrée. - Les partitions nécessitant
verifyatboot
ne doivent pas être montées prématurément (cela n'est pas pris en charge). - Le mode/état de vérité pour les partitions vérifiées doit être spécifié dans
kernel_cmdline
à l'aide de l'optionandroidboot.veritymode
(exigence existante).
Montage précoce de DeviceTree, VBoot 1.0
Sous Android 8.x et versions ultérieures, init
analyse l'arborescence des périphériques et crée des entrées fstab
pour monter la partition au début de sa première étape. Une entrée fstab
prend la forme :
src mnt_point type mnt_flags fs_mgr_flags
Les propriétés Devicetree sont définies pour imiter ce format :
- Les entrées
fstab
doivent se trouver sous/firmware/android/fstab
dans l'arborescence des périphériques et doivent avoir une chaîne compatible définie surandroid,fstab
. - Chaque nœud sous
/firmware/android/fstab
est traité comme une seule entréefstab
à montage anticipé. Un nœud doit avoir les propriétés suivantes définies :-
dev
doit pointer vers le nœud de périphérique représentant la partitionby-name
-
type
doit être le type du système de fichiers (comme dans les fichiersfstab
) -
mnt_flags
doit être la liste des indicateurs de montage séparés par des virgules (comme dans les fichiersfstab
) -
fsmgr_flags
doit être la liste desfs_mgr flags
(comme dans les fichiersfstab
)
-
- Les partitions A/B doivent avoir une option
slotselect fs_mgr
. - Les partitions activées par dm-verity doivent avoir une option
verify fs_mgr
.
Exemple : /system et /vendor sur N6P
L'exemple suivant montre le montage anticipé de DeviceTree pour les partitions system
et vendor
sur le 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"; }; }; }; }; };
Exemple : /fournisseur sur Pixel
L'exemple suivant montre le montage anticipé de DeviceTree pour /vendor
sur Pixel (n'oubliez pas d'ajouter slotselect
pour les partitions soumises à A/B) :
/ { 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"; }; }; }; }; };
Montage précoce des partitions, VBoot 2.0
VBoot 2.0 est un démarrage vérifié par Android (AVB) . Les conditions requises pour monter des partitions avec VBoot 2.0 sont les suivantes :
- Les chemins des nœuds de périphériques doivent utiliser leurs liens symboliques
by-name
dans les entréesfstab
et devicetree. Par exemple, au lieu de spécifier des partitions à l'aide de/dev/block/mmcblk0pX
, assurez-vous que les partitions sont nommées et que le nœud de périphérique est/dev/block/…./by-name/{system,vendor,odm}
. - Les variables système de build (telles que
PRODUCT_{SYSTEM,VENDOR}_VERITY_PARTITION
etCUSTOM_IMAGE_VERITY_BLOCK_DEVICE
) utilisées pour VBoot 1.0 ne sont PAS requises pour VBoot 2.0. Au lieu de cela, les variables de build introduites dans VBoot 2.0 (y comprisBOARD_AVB_ENABLE := true
) doivent être définies ; pour une configuration complète, reportez-vous à Build System Integration for AVB . - Les entrées fournies via les superpositions de l'arborescence des périphériques ne doivent pas se répéter dans les fragments du fichier
fstab
. Par exemple, si vous spécifiez une entrée à monter/vendor
dans l'arborescence des périphériques, le fichierfstab
ne doit pas répéter cette entrée. - VBoot 2.0 ne prend pas en charge
verifyatboot
, que le montage anticipé soit activé ou non. - Le mode/état de vérité pour les partitions vérifiées doit être spécifié dans
kernel_cmdline
à l'aide de l'optionandroidboot.veritymode
(exigence existante). Assurez-vous d'inclure les correctifs suivants pour AVB :
Montage précoce de DeviceTree, VBoot 2.0
La configuration dans devicetree pour VBoot 2.0 est la même que celle dans VBoot 1.0 , avec les exceptions suivantes :
- Le
fsmgr_flag
passe deverify
àavb
. - Toutes les partitions avec des métadonnées AVB doivent figurer dans l'entrée VBMeta de l'arborescence des périphériques, même si la partition n'est pas montée tôt (par exemple,
/boot
).
Exemple : /system et /vendor sur N5X
L'exemple suivant montre un montage anticipé de Devicetree pour les partitions system
et vendor
sur le Nexus 5X. Noter que:
-
/system
est monté avec AVB et/vendor
est monté sans vérification d'intégrité. - Comme le Nexus 5X n'a pas de partition
/vbmeta
, la vbmeta de niveau supérieur réside à la fin de la partition/boot
(pour plus de détails, reportez-vous à la liste des modifications AOSP )./ { 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"; }; }; }; }; };
Exemple : /fournisseur sur Pixel
L'exemple suivant montre le montage précoce /vendor
sur un Pixel. Noter que:
- D'autres partitions sont spécifiées dans l'entrée vbmeta car ces partitions sont protégées par AVB .
- Toutes les partitions AVB doivent être incluses, même si seul
/vendor
est monté au préalable. - N'oubliez pas d'ajouter
slotselect
pour les partitions soumises à A/B./ { 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"; }; }; }; }; };