I think it has a real place on industrial equipment which the Compute Module 4 is expressly designed for, and I cannot deny that for smartphones it has a very large security value. On iPhone, for example, there has been no exploit since iOS 9 that can persist between reboots. A reboot allows the system to start from a guaranteed-secure state, see something is out of place, and repair it, at least until the same bug is exploited again.
However, that does still have value. Let's say (one dramatic example) that I'm imprisoned. The government so generously agreed to let me use my phone for an hour, but managed to use an exploit to install a keylogger for when I enter in my PIN code (an actual marketed feature of GrayKey). I can simply forcibly reboot the phone using the hardware reset, and then enter my PIN code knowing that their attempts to log my PIN code have failed.
Most phones that allow you to root them just display message about it on the start, I think that's far better solution if you still want to keep the "trusted chain" but not make device into a landfill when user wants to do something else with it. At very least for devices with user-facing UI
What do eFuses have to do with exploits on iOS? Afaik Apple does not use eFuses to prevent downgrades. iOS downgrades are prevented via verification of shsh2 blobs.
E-fuses are commonly used to prevent downgrade attacks, where a system that only boots signed content can be tricked in to booting older versions with known vulnerabilities that can then be chained in to a full exploit.
The short version is a signed firmware can be programmed to not boot if more than X amount of fuses are burned, so when a change occurs that the vendor wants to ensure can't be downgraded they just increase that number and burn fuses as part of the update process. Older versions fail the check and crash themselves. There is a hardware modification that can be done to prevent fuses from being burnt but that obviously has to be done before the update.
E-fuses enforce Secure Boot. Secure Boot, which cannot be disabled, are used to ensure that no exploit, no virus, no modification, can last beyond a reboot. If I want to put my device back into a guaranteed-secure state (at least for the moment), a reboot will always do the trick. I don't need to reinstall the operating system every time I'm uncertain.
This is especially important for things like smartphones. Yes, you can't boot other Operating Systems on your iPhone and there's no way to disable that. On the other hand, there's no way for a hostile government, or just your crazy ex, to permanently bug your device either. They can, of course, use various methods to try to re-infect your device after each reboot but it's hit-or-miss, especially as the bugs get fixed.
> E-fuses enforce Secure Boot. Secure Boot, which cannot be disabled, are used to ensure that no exploit, no virus, no modification, can last beyond a reboot. If I want to put my device back into a guaranteed-secure state (at least for the moment), a reboot will always do the trick. I don't need to reinstall the operating system every time I'm uncertain.
That may work in case of Android or iOS as a whole package (or not) but all e-fuses achieve is that some fixed boot ROM bootloader loads and checks the next stage of boot code against some key and runs it. That's all. All the rest of the verification rests on the mountain of buggy code down the road.
It doesn't guarantee anything else you mentioned. If you ever signed and published a bootloader stage that has bug/fetaure allowing the attacker to bypass signature checking on any code further down, the whole scheme becomes completely useless.
For guaranteeing clean code, all you need to do is to boot clean code. :) Hardware has to reliably allow you to force boot from external storage without running any code that the attacker could have modified. That's all. Very simple and reliable. Some phones allow this. Some SBCs do allow this, too.
[Hopefully] "secure boot" is strictly less reliable and less optimal and much more complicated than this, with way more opportunities to be bitten by bugs in its implementation.
A main purpose of the investment into it for iPhone is to protect their os and drm media interests, not the user. The incentive on laptops is more aligned with users for now, since you can turn it off.
However, that does still have value. Let's say (one dramatic example) that I'm imprisoned. The government so generously agreed to let me use my phone for an hour, but managed to use an exploit to install a keylogger for when I enter in my PIN code (an actual marketed feature of GrayKey). I can simply forcibly reboot the phone using the hardware reset, and then enter my PIN code knowing that their attempts to log my PIN code have failed.