¿Cómo habilitar correctamente dm-verity y FEC para /system en Motorola X4 con LineageOS 17.1?

Advertencia ¡! ¡Utilícelo bajo su propio riesgo! El sentido y sobre todo la seguridad añadida de todo esto puede ser discutido. Encuentra algunas notas sobre la seguridad al final.

tl;dr:

Me llevó algunos días encontrar una solución para conseguirlo:

[    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

• Construir LOS 17.1 con el commit revertido de la pregunta inicial

• Coloque verity_key en ramdisk/first_stage_ramdisk carpeta

• Añade las siguientes opciones de cmdline, esta es la clave de prueba de 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

• Añadir la partición del sistema al DTB fstab e incluir la opción de verificación

Hay más advertencias de las que pensaba. También intentaré incluir todas las palabras que buscaba en este texto.

Conclusiones clave en relación con el arranque y la dm-veridad sobre el payton

• Parece ser un dispositivo SAR (system-as-Root) heredado (¡La lectura más importante!). El kernel monta el sistema de archivos Root/system por sí mismo, sin necesidad de un ramdisk o una partición de ramdisk. Los argumentos típicos de la línea de comandos para el kernel son Root=/dev/block/mmcblk0p6x donde x es 5 o 6 para la partición A/B del sistema y init=/init.
• Los archivos originales de motorola no contienen un fstab en el ramdisk
• No hay ninguna partición del sistema definida en el DTB en los archivos de motorola
• Por lo tanto, el gestor de arranque parece verificar la imagen de arranque, probablemente con algunos certificados incorporados al gestor de arranque. (las cadenas -a del gestor de arranque lo indican). Luego establece la partición de inicio apropiada y tal vez la línea de comandos para la verificación de la veracidad, más sobre esto más adelante.
• el vendedor se llama oem en motorola.
• Como se mencionó el payton falta fastboot flash avb_custom_key Así que no hay un nuevo y brillante Android Verified Boot (AVB) 2.0 con vbmeta.img. Lo más probable es que sea porque se envió inicialmente con Android 7.0 y nadie se preocupó de actualizar las estructuras.

Algunas cosas sobre la construcción de LineageOS 17.1

• Construir LOS como escrito en su ayuda
• LOS parece que también arranca el SAR heredado, excepto cuando entra en el modo de recuperación.
• Si utilizas las instrucciones siguientes, obtendrás algo parecido a Android Verified Boot 1.0
• El proceso de construcción prepara lo siguiente para dm-verity integración: Creación de boot.img, system.img y vendor.img, añade metadatos de dm-verity al final de system.img y vendor.img y firma boot.img. vendor se verifica en la configuración por defecto de LOS añadiéndolo a fstab y creando adicionalmente una entrada fstab DTB para él.

El proceso general de construcción

• El código base es impresionantemente grande: 190 GB sin ccache

• Revertir el commit mencionado en dm-Android-verity.c

• Utilice la siguiente línea de comandos del Kernel.

• Esto circunscribe A/B y slotselect mecanismo para seleccionar el sistema_a o el sistema_b adecuado. Sin el soporte del bootloader no sé si es posible volver a habilitar A/B.

• Además esta configuración siempre se salta el recovery, aunque intentes arrancar al recovery desde el bootloader.

• Esto no funcionó con androidboot.veritykeyid No sé por qué (todavía).

• ¡Tienes que escapar " y # aquí!

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

• sin force_normal_boot un arranque "normal" va a recovery.

kernel/motorola/msm8998/arch/arm/boot/dts/qcom/sdm630.dtsi:

sistema { compatible = "Android,system"; dev = "/dev/block/platform/soc/c0c4000.sdhci/by-name/system"; tipo = "ext4"; mnt_flags = "ro,barrier=1"; fsmgr_flags = "wait,verify,slotselect"; };

• Tal vez también se pueda omitir el Cambio de DTB (montar particiones con DTB será obsoleto en Android 11) y utilizar un archivo fstab (en algún lugar, tal vez en first_stage_ramdisk).

• asegúrese de que verity está activado en ./make/target/product/verity.mk

PRODUCT_SUPPORTS_BOOT_SIGNER := true PRODUCT_SUPPORTS_VERITY := true PRODUCT_SUPPORTS_VERITY_FEC := true

• Cuando cambie la clave de verificación, no olvide añadirla al núcleo en kernel/motorola/msm8998/certs y comprobar los certificados en el sistema en ejecución en /proc/keys
• Puede obtener los últimos mensajes de arranque (fallidos) en /sys/fs/pstore/console-ramoops
• El sistema resultante se comporta como 2SI ramdisk SAR

Pregunta principal: ¿Añade esto seguridad al dispositivo?

• Puedes bloquear el bootloader después con fastboot flashing lock
• La partición de arranque tiene que ser verificada manualmente con los identificadores de clave mostrados durante el arranque (al menos creo que son algunas firmas del boot.img firmado)
• El flasheo de particiones desde el bootloader no funciona
• Entrar en la recuperación tampoco funciona
• fastboot boot file.img da un error
• fastboot flashing unlock borra los datos del usuario, ¡esto es bueno!
• En caso de que algo vaya mal con el sistema en funcionamiento, tienes que borrar tu dispositivo.
• La actualización se ha vuelto un poco más difícil sin cambios en el actualizador porque la partición A/B está codificada.
• Root necesita estar habilitado para las actualizaciones (al menos ADB Root), por lo que esto seguirá siendo una construcción userdebug.
• Cambios en /sistema puede ser ejecutado sin estropear la dm-veridad, solo hay que firmar el sistema cambiado.
• dm-verity está en eio modo aquí, en realidad no traté de establecerlo en la aplicación.

Preguntas abiertas

• ¿Puedes cambiar el cmdline del kernel desde el bootloader?
• Tal vez usted puede blankflash (fastboot oem blankflash) el dispositivo, no sé lo que sucede en este caso.

Diviértete.