O M F G
what can I say?
I did it after reading the repartition-Link.
And it worked a 100% like a charm (or how do I say it correctly?).
Why are you @hirnsushi not an Fairphone-Angel?
In the end you also helped @bookworm, too in repartitioning.
Anyway, the outputs (just for the protocol), Success:
But first I set the path variable to my adb-platform-folder, so that I didn’t have to replace the path to IMG-Files and I was able to copy/paste the commands from the Howto.
I started by booting into the bootloader and rebooted into it again, just to make sure, that the commands are working with the new path entry.
the Internet connects us all on the small planet; City hin oder her
and answering a forums post so fast is kinda the same like answering an e-Mail, but everyone can participate on the experience. Isn’t that what makes a good community?; sharing know-how, errors and success?!?
Sure, I’ll take a look, it’s perfectly set to 1.
Also within bootloader, written down in red says: DEVICE STATE - unlocked.
But as we said I skipped the last part from /e/os manual, locking the bootloader.
And also, like you said it’s true. The OEM-Switch mentioned above is not grayed out in /e/os.
So this could cause a problem. Maybe that should be grayed out from any running OS, if bootloader is unlocked, just for security reason.
I am not familiar with Google’s security patch schedule, but it seems there are two every month: at the first day, and at the fifth day. Is this something I need distinguish in this regard?
I am pretty much assume, that /e/OS in fact includes the security patches up to August 5th. But I still do feel uncomfortable since it is not mentioned explicitly.
To my understanding, there is never an issue as long as the bootloader is not relocked by myself. I want to know that nevertheless.
Just to be sure: Is it possible to brick the phone while locking the bootloader, even if you ensure everytime that the OEM unlock capability is activated (i.e. fastboot flashing get_unlock_ability returns 1)?
As long as this is active, it is always possible to execute fastboot flashing unlock[_critical], isn’t it?
It seems there is no way to check if anti-rollback protection would kick-in in advance to locking the bootloader. It sound like this would be super useful.
The interesting information isn’t in the /e/ release notes, but in the commit history of the FP4 specific repo. If you have a look at the bottom of this merge request, you can see, that A.163 has been released in 1.4, while A.170 is planned for 1.5.
The important part is, does your phone match the firmware patch level, which seems to be the case
Since Fairphone has never actually told us anything about the specifics of the bootloader bug, I’d say, there’s always a possibility. But you are probably asking the wrong person, past experiences on this forum have made me a bit overly cautious. (And I’m running Magisk, so I can’t lock it anyway )
Generally you should be fine, others have been able to just unlock their bootloader after a failed attempt, but I can’t guarantee it.
Now confident that I a) won’t brick it with and b) the security patch level should match, I tried it and I can confirm that 1.4-r contains security patches up to 2022-08-05. Thanks @jobal and @hirnsushi!
The remaining part is only because im curious:
@hirnsushi, I feel a bit stupid that I did not think about looking into the commits by myself
Let’s see: Starring at MR!21, it seems the relevant data is the change from 2022-08-05 to 2022-09-05 and that this change is linked to milestone /e/OS v1.5-beta. That essential means that the prior version, i.e. 1.4-r, contains security patches up to 2022-08-05.
It’s seems odd that this repository does not contain a tag 1.4-r. Looking at the corresponding file content would show this information directly.
Listing the history of the file android_device_fairphone_FP4:BoardConfig.mk lists the changes to the security patch date. Jumping to the corresponding change to the actual MR reveals again the assigned milestone (!19 in case of 1.4-r).
One thing I did not expect, but confuses me – and I guess there is something I have missed: the version string mentioned by the /e/ developer, i.e. FP4.FP4D.A.163.20220826 or FP4.FP4G.A.170.20220920, is indeed the very same as used by Fairphone. They “bump” to the Fairphone version. I assumed this would be the Fairphone’s firmware version. Is it something different? I guess it just means /e/ aligned its firmware to that one e.g. in respect of the security patch date.
I was not able to draw the line between the manifest of 1.4-r (which seems to be that version of default.xml) to the specific version of the android_device_fairphone_FP4 repository. Mh, shouldn’t it be there?
There are different patch levels, one is the security updates Google releases and the other are the vendor / firmware patches Fairphone releases. When you see a Fairhphone release pulled in, that means the proprietary blobs have been updated to match upstream (Fairphone in this case).
In newer Android versions the different patch levels are listed in even more detail, that’s what it looks like on my FP4 running A13:
Do you know if anti-rollback protection looks at all these dates or if it only takes e.g. the vendor security patch level into account?
Below are some findings and my understanding how the anti-rollback protection works. Feel free to ignore. It’s slightly out of toic I guess.
To my understanding, the anti-rollback feature is configured by the mobile phone vendor (in this case Fairphone) and utilises write-once memory (or similar, called fuses) of the SoC. The process is standardised as part of Android Verified Boot (AVB). 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.
An interesting question is which party actually signs the rollback index in case of /e/OS. Does Fairphone B.V. assess the image and provide the signature? Does the /e/ foundation own a (derived) key and is capable doing it itself?
This signing party seems to be in charge to deduce the rollback index from the security patch level (dates) and hence “controls” which of these dates are taken into account.
Further reading of the linked documentation reveals that it is possible that several “partitions” contain different rollback indices. Perhaps my assumption that hardware fuses are used directly here is wrong and it is only the backing feature to protect the bootloader, EDL or whatsoever and the actual “firmware rollback protection” based on the security patch levels is designed on top of that in SW.
Quote from the linked documentation:
If verification keys (note: these verify the rollback index) are mutable they must only be set by the end user, e.g. it must never be set at the factory or store or any intermediate point before the end user. Additionally, it must only be possible to set or clear a key while the device is in the UNLOCKED state.
Interesting. Is this used to support custom ROMs and does /e/OS fall under this category in this regard?
Puh – exhausting topic …
I am sorry if I misuse this topic inappropriately. My aim is to get a deeper understanding how anti-rollback protection actually works to understand better, how to avoid triggering eventually.
Just let me know if I drift too far off-topic.
Can’t understand your latest post, I apologize. But you write
in your previous, so I am curious: have you also locked your bootloader after install eOS?
I was lucky in my first attempt to install /e/ and locked it, so now I don’t have a rooted device and all my daily apps (banking, identification, tracking…) work well.
Sorry for not beeing clear enough:
What I have tried was to install /e/OS 1.4.-r over the FP4.FP4D.A.163.20220826 which was succesful. I did keep keep the bootloader unlocked (for now), as well as the “OEM unlock” switch.
So essentially, nothing new
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:
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.