Avertissement ! Utilisez-le à vos risques et périls ! Le sens et surtout la sécurité ajoutée de tout ceci peuvent être contestés. Vous trouverez quelques notes sur la sécurité à la fin.
tl;dr :
Il m'a fallu quelques jours pour trouver une solution à ce problème :
[ 2.251328] init: init first stage started!
[ 2.251561] init: Switching root to '/first_stage_ramdisk'
[ 2.252614] init: Using Android DT directory /proc/device-tree/firmware/android/
[ 2.603025] init: [libfs_mgr]Enabling dm-verity for system (mode 0)
[ 2.603181] init: [libfs_mgr]Verity table: updated block device from '/dev/block/platform/soc/c0c4000.sdhci/by-name/system' to '/dev/block/platform/soc/c0c4000.sdhci/by-name/system_b'
[ 2.603195] init: [libfs_mgr]Verity table: updated block device from '/dev/block/platform/soc/c0c4000.sdhci/by-name/system' to '/dev/block/platform/soc/c0c4000.sdhci/by-name/system_b'
[ 2.753873] device-mapper: verity-fec: 259:33: FEC 0: corrected 22 errors
[ 2.830804] device-mapper: verity-fec: 259:33: FEC 4096: corrected 7 errors
[ 2.831080] init: [libfs_mgr]superblock s_max_mnt_count:65535,/dev/block/dm-0
[ 2.854916] device-mapper: verity-fec: 259:33: FEC 0: corrected 22 errors
[ 2.878336] device-mapper: verity-fec: 259:33: FEC 4096: corrected 7 errors
[ 3.001281] device-mapper: verity-fec: 259:33: FEC 1052672: corrected 18 errors
[ 3.001825] EXT4-fs (dm-0): mounted filesystem without journal. Opts: barrier=1
[ 3.001947] init: [libfs_mgr]__mount(source=/dev/block/dm-0,target=/system,type=ext4)=0: Success
[ 3.002215] init: Switching root to '/system'
[ 3.139199] device-mapper: verity-fec: 259:33: FEC 3133440: corrected 12 errors
[ 3.272389] init: [libfs_mgr]Enabling dm-verity for vendor (mode 0)
[ 3.272662] init: [libfs_mgr]Verity table: updated block device from '/dev/block/platform/soc/c0c4000.sdhci/by-name/oem' to '/dev/block/platform/soc/c0c4000.sdhci/by-name/oem_b'
[ 3.272679] init: [libfs_mgr]Verity table: updated block device from '/dev/block/platform/soc/c0c4000.sdhci/by-name/oem' to '/dev/block/platform/soc/c0c4000.sdhci/by-name/oem_b'
[ 3.276744] init: [libfs_mgr]superblock s_max_mnt_count:65535,/dev/block/dm-1
[ 3.279830] EXT4-fs (dm-1): mounting with "discard" option, but the device does not support discard
[ 3.279845] EXT4-fs (dm-1): mounted filesystem without journal. Opts: barrier=1,discard
[ 3.279935] init: [libfs_mgr]__mount(source=/dev/block/dm-1,target=/vendor,type=ext4)=0: Success
-
Construire LOS 17.1 avec le commit inversé de la question initiale.
-
Placez verity_key dans ramdisk/first_stage_ramdisk dossier
-
Ajoutez les options cmdline suivantes, c'est la clé de test d'Android :
BOARD_KERNEL_CMDLINE += Root=/dev/dm-0 dm=\"system none ro,0 1 Android-verity Android:\#7e4333f9bba00adfe0ede979e28ed1920492b40f /dev/block/by-name/system_b\" androidboot.slot_suffix=_b rootwait androidboot.force_normal_boot=1
-
Ajouter la partition système au DTB fstab et inclure l'option verify
Il y a plus d'avertissements ici que je ne le pensais. Je vais également essayer d'inclure tous les mots que je recherchais dans ce texte.
Principales conclusions concernant le démarrage et le dm-verity sur le payton
-
Il semble qu'il s'agisse d'un dispositif SAR (system-as-Root) hérité. (lecture la plus importante !). Le noyau monte le système de fichiers Root/system lui-même, sans utiliser de ramdisk ou de partition ramdisk. Les arguments typiques de la ligne de commande pour le noyau sont les suivants Racine=/dev/block/mmcblk0p6x où x est 5 ou 6 pour la partition du système A/B et init=/init.
- Les fichiers originaux de Motorola ne contiennent pas de fstab dans le disque RAM.
- Il n'y a pas de partition système définie dans le DTB dans les fichiers de Motorola.
- Par conséquent, le chargeur de démarrage semble vérifier l'image de démarrage, probablement avec des certificats intégrés dans le chargeur de démarrage ? (les chaînes -a du chargeur de démarrage y font allusion). Ensuite, il définit la partition de démarrage appropriée et peut-être la ligne de commande pour la vérification de la véracité, plus sur ce point plus tard.
- Le vendeur est appelé OEM sur Motorola.
- Comme mentionné, le Payton est absent. fastboot flash avb_custom_key donc pas de nouveau et brillant Android Verified Boot (AVB) 2.0 avec vbmeta.img. Très probablement parce qu'il a été initialement livré avec Android 7.0 et que personne ne s'est soucié de mettre à jour les structures.
Quelques informations sur la construction de LineageOS 17.1
- Construire LOS comme écrit dans leur aide
- LOS semble aussi démarrer le SAR, sauf quand vous entrez en mode de récupération.
- En utilisant les instructions ci-dessous, vous obtiendrez quelque chose comme Android Verified Boot 1.0.
- Le processus de construction prépare les éléments suivants pour dm-verity l'intégration : Créer boot.img, system.img et vendor.img, ajouter les métadonnées dm-verity à la fin de system.img et vendor.img et signer boot.img. vendor est vérifié dans la configuration LOS par défaut en l'ajoutant à fstab et en créant en plus une entrée DTB fstab pour lui.
Le processus général de construction
-
La base de code est d'une taille impressionnante : 190 Go sans ccache.
-
Revenir sur le commit mentionné dans dm-Android-verity.c
-
Utilisez la ligne de commande suivante pour le noyau.
-
Cette circonvolution A/B et slotselect mécanisme permettant de sélectionner le système_a ou le système_b approprié. Sans le support du bootloader, je ne sais pas s'il est possible de réactiver un jour A/B.
-
De plus, cette configuration ignore toujours la récupération, même si vous essayez de démarrer en récupération depuis le chargeur de démarrage.
-
Cela n'a pas fonctionné avec androidboot.veritykeyid Je ne sais pas (encore) pourquoi.
-
Vous devez vous échapper " et # ici !
device/motorola/sdm660-common/BoardConfigCommon.mk :
BOARD_KERNEL_CMDLINE += Root=/dev/dm-0 rootwait BOARD_KERNEL_CMDLINE += dm=\"system none ro,0 1 Android-verity Android:\#7e4333f9bba00adfe0ede979e28ed1920492b40f /dev/block/by-name/system_b\" BOARD_KERNEL_CMDLINE += androidboot.slot_suffix=_b BOARD_KERNEL_CMDLINE += androidboot.force_normal_boot=1 BOARD_BUILD_SYSTEM_ROOT_IMAGE := false
- sans force_normal_boot un démarrage "normal" va en récupération.
kernel/motorola/msm8998/arch/arm/boot/dts/qcom/sdm630.dtsi :
système { compatible = "Android,system" ; dev = "/dev/block/platform/soc/c0c4000.sdhci/by-name/system" ; type = "ext4" ; mnt_flags = "ro,barrier=1" ; fsmgr_flags = "wait,verify,slotselect" ; } ;
-
Peut-être que vous pouvez aussi laisser de côté le Changement de DTB (le montage de partitions avec DTB sera obsolète dans Android 11) et utiliser un fichier fstab (quelque part, peut-être dans first_stage_ramdisk).
-
assurez-vous que verity est activé dans ./make/target/product/verity.mk
PRODUCT_SUPPORTS_BOOT_SIGNER := true PRODUCT_SUPPORTS_VERITY := true PRODUCT_SUPPORTS_VERITY_FEC := true
- Lorsque vous changez la clé de verité, n'oubliez pas de l'ajouter au noyau dans le fichier kernel/motorola/msm8998/certs et vérifiez les certificats dans le système en cours d'exécution dans /proc/keys
- Vous pouvez obtenir les derniers messages de démarrage (échoués) dans /sys/fs/pstore/console-ramoops
- Le système résultant se comporte comme un disque RAM 2SI SAR.
Question principale : Cela ajoute-t-il de la sécurité à l'appareil ?
- Vous pouvez verrouiller le chargeur de démarrage après avec fastboot flashing lock
- La partition de démarrage doit être vérifiée manuellement à l'aide des identifiants de clé affichés lors du démarrage (du moins, je pense qu'il s'agit de signatures du fichier boot.img signé).
- Flashage des partitions à partir du chargeur de démarrage ne fonctionne pas
- Entrer dans la récupération ne fonctionne pas non plus
-
fastboot fichier de démarrage.img donne une erreur
-
fastboot flashing déverrouillage efface les données utilisateur, c'est bien !
- En cas de problème avec le système en cours d'exécution, vous devez effacer votre appareil.
- La mise à jour est devenue un peu plus difficile sans modification du programme de mise à jour car la partition A/B est codée en dur.
- Root doit être activé pour les mises à jour (au moins ADB Root), donc cela restera une construction userdebug.
- Changements apportés à /système peut être exécuté sans perturber le dm-verity, il suffit de signer le système modifié.
- dm-verity est en eio ici, je n'ai pas essayé de le régler sur l'application.
Questions ouvertes
- Pouvez-vous modifier la ligne de commande du noyau à partir du chargeur de démarrage ?
- Peut-être que vous pouvez blankflash (fastboot oem blankflash) l'appareil, je ne sais pas ce qui se passe dans ce cas.
Amusez-vous bien !
