If you examine attentively my flowchart, you’ll notice that I only wrote “newer” and “older” patch. Same patch is currently under doubt (for FP6), as mentioned earlier it seems some FP6 got bricked in that situation…
You didn’t got the point.
If get_unlock_ability = 0 and you lock, OEM unlocking is disabled so you cannot unlock in any case.
The testimony is of someone that locked with get_unlock_ability = 0 and everything went fine (no rollback protection triggered) so the phone is booting OK, beeing locked!
The confusion stems from the fact that the Android docs mention a requirement to reset the rollback index on lock/unlock…
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.
…but it’s since become clear that newer bootloaders mostly don’t seem to actually follow that rule.
No idea if there was a policy change at some point, I couldn’t find anything about that, Google / OEMs implementing something that isn’t compliant with their own specs isn’t hugely surprising though.
Or you know, maybe my understanding of the docs is completely wrong and they’re meant differently. Sure would have been great if someone from Fairphone had cleared that up when the issues first appeared, it is what it is
Just do a thorough internet research for the difference between “bootloader locking” and “OEM unlocking” and for the meaning of the flag “get_unlock_ability”. This should reveal all necessary technical documentation.
Thanks for the paper, you’re the best!
What I learned from it :
normally the rollback index is flushed after unlocking so you could theoretically downgrade and then lock, no problem
there are 4 (four) rollback indices in storage at any time. 2 (current and last one) for each slot (a/b). And the locked bootloader verifies that the OS you’re trying to boot has a rollback index equal or greater than any of the 4. There is some discussion about what a successful slot it, it may be less than that, but that’s the idea
there is a temper-evident (i.e. really immutable) part of the storage but i’m not sure what is in it
there is a “board avb rollback index” that may be persistent but didn’t find much info on, maybe that’s up to the manufacturer
the device should return the specific error that bricks a phone. There are three cited : rollback, key, and OS verification. They are only ‘fatal’ when the bootloader is locked. But where’s the log? can’t we access the error?
via Cordon: