Install /e/ on a Fairphone FP4 - “FP4” (beta)

[anon73661646]

@doak

It is basically a index updated during flashing and it is not allowed to decrement. Since its is is cryptically signed, you can’t tamper with it.
I assume that the root of trust, i.e. key0 from the linked documentation, is rolled out by the mobile phone vendor (i.e. Fairphone in this case) during production. I guess this vendor also predetermines when increments to the rollback index are expected to happen. Perhaps this is even already specified by AVB.

Kind of, but from my very limited understanding not completely right.
A custom ROM doesn’t really have to make use of AVB, which pulls in rollback protection. You can just keep the bootloader unlocked and the whole issue goes away completely.

As you found out yourself, there’s the option of user-settable root of trust as well, which /e/OS, iodé, CalyOS etc. use to set their own keys and sign their releases with. That key gets loaded into “tamper evident” storage and makes it possible to lock the bootloader with one of those ROMs installed.

The specifics of AVB / rollback protection get set in the build system, so by whoever is building the images you are installing to your device. And the index gets updated when those images increment the index, e.g. during an OTA update.
You can have a look at that in action for example in the /e/OS BoardConfig.mk or the CalyxOS BoardConfig.mk.

If you use avbtool, you’ll see that reflected in the images:

avbtool output

foo@bar:$ ./avbtool.py info_image --image /home/foo/Development/Android/calyx/FP4-tp1a.221005.003/image-FP4-tp1a.221005.003/vbmeta_system.img 
Minimum libavb version:   1.0
Header Block:             256 bytes
Authentication Block:     576 bytes
Auxiliary Block:          2688 bytes
Public key (sha1):        29f859183d3f64db6652e498d30ab916662aef90
Algorithm:                SHA256_RSA4096
Rollback Index:           1662336000
Flags:                    0
Rollback Index Location:  0
Release String:           'avbtool 1.2.0'
Descriptors:
    Prop: com.android.build.system.os_version -> '13'
    Prop: com.android.build.system.fingerprint -> 'Fairphone/FP4eea/FP4:11/RKQ1.210503.001/FP4D:user/release-keys'
    Prop: com.android.build.system.security_patch -> '2022-08-05'
    Prop: com.android.build.product.os_version -> '13'
    Prop: com.android.build.product.fingerprint -> 'Fairphone/FP4eea/FP4:11/RKQ1.210503.001/FP4D:user/release-keys'
    Prop: com.android.build.product.security_patch -> '2022-08-05'
    Prop: com.android.build.system_ext.os_version -> '13'
    Prop: com.android.build.system_ext.fingerprint -> 'Fairphone/FP4eea/FP4:11/RKQ1.210503.001/FP4D:user/release-keys'
    Prop: com.android.build.system_ext.security_patch -> '2022-08-05'
    Hashtree descriptor:
      Version of dm-verity:  1
      Image Size:            1121902592 bytes
      Tree Offset:           1121902592
      Tree Size:             8839168 bytes
      Data Block Size:       4096 bytes
      Hash Block Size:       4096 bytes
      FEC num roots:         2
      FEC offset:            1130741760
      FEC size:              8945664 bytes
      Hash Algorithm:        sha1
      Partition Name:        product
      Salt:                  62d86d9743a5cc83ebef37719730ed9ac615603b23af7aadf19cf3e2029d488b
      Root Digest:           fc7c82592f04ef39be89bfa114a92db3da6b5434
      Flags:                 0
    Hashtree descriptor:
      Version of dm-verity:  1
      Image Size:            919646208 bytes
      Tree Offset:           919646208
      Tree Size:             7249920 bytes
      Data Block Size:       4096 bytes
      Hash Block Size:       4096 bytes
      FEC num roots:         2
      FEC offset:            926896128
      FEC size:              7331840 bytes
      Hash Algorithm:        sha1
      Partition Name:        system
      Salt:                  62d86d9743a5cc83ebef37719730ed9ac615603b23af7aadf19cf3e2029d488b
      Root Digest:           0f72873eeb1f9fc0f8df5026bbeba1fda7b4c5ec
      Flags:                 0
    Hashtree descriptor:
      Version of dm-verity:  1
      Image Size:            282202112 bytes
      Tree Offset:           282202112
      Tree Size:             2232320 bytes
      Data Block Size:       4096 bytes
      Hash Block Size:       4096 bytes
      FEC num roots:         2
      FEC offset:            284434432
      FEC size:              2252800 bytes
      Hash Algorithm:        sha1
      Partition Name:        system_ext
      Salt:                  62d86d9743a5cc83ebef37719730ed9ac615603b23af7aadf19cf3e2029d488b
      Root Digest:           a510cf9e25ba68c4cae0ef22524ea151074a807d
      Flags:                 0

Now, according to the docs …

All user data must be cleared when transitioning from the LOCKED to the UNLOCKED state (including the userdata partition and any NVRAM spaces). Additionally all stored_rollback_index[n] locations must be cleared (all elements must be set to zero). Similar action (erasing userdata, NVRAM spaces, and stored_rollback_index[n] locations) shall also happening when transitioning from UNLOCKED to LOCKED

… all those indices should be cleared when transitioning between different states, why we still have to worry about the FPOS patch level when installing /e/OS is beyond me
You’ll have to talk to an actual developer if you need those answers, I’d be very curious as well.