Linux

Uhm, so, the problem isn't only the unlocking but also the re-locking of the bootloader.

Leaving the bootloader unlocked while you're storing sensitive data on the phone means that thieves, but also law enforcement, can read the data that's stored on your phone if they guess the cryptographic key that protects your data correctly. If you're using a 4-digit PIN, there's only 9999 combinations, and guessing the PIN correctly can be done in a few minutes on a modern computer.

If you use a strong password, your data would be secured against thieves and law enforcement. But then you'd have to enter a strong password every time that you boot up the device, which is annoying.

So, if you can re-lock the bootloader after having installed the operating system, then an attacker can't just access the raw, encrypted data and try every possible PIN combination on it. Instead, they'd have to go through the operating system's user interface that's installed on the phone, and that can limit the number of allowed password attempts down to 10 or so, so they probably won't have access to the data on the phone if they don't guess the PIN correctly within 10 attempts.

A locked bootloader works with a trusted chain.

That means:

• There's a trusted enclave on your phone, usually inside the SoC but sometimes it's a dedicated chip. This chip has purposely very little access to it. This one contains the root keys for the encryption used on the phone.
• The phone only boots a bootloader verified by the trusted enclave.
• The verified bootloader verifies and only boots a verified system image.

If everything is implemented correctly and there are no bugs that can be exploited (like e.g. on newer Switch 1 models, older ones had a bug that was exploitable), then the only thing you can do is hardware exploits.

For that you could e.g. solder on a chip that hijacks the connection between the trusted enclave and the SoC (e.g. modchip on newer Switch 1 models) or you have to replace parts, e.g. the trusted enclave chip or the SoC (if the trusted enclave is within the SoC).

That's usually the point where it becomes too costly to be worth it.

There would need to be either a flaw in the cryptography or a flaw in the bootloader. If the OS image is tampered will at all it will refuse to boot as it needs to be signed.

This can be really good for security as it means attacks on your device are very hard. However, it is also a tool to lock down vendor hardware.

Different ways:

Sometimes it’s a cryptographic key thing, if the bootloader doesn’t see an image signed with a trusted key it won’t boot.

Sometimes it’s a flag set in storage that is secure and not writable. Bootloader checks the flag, if it’s set then it enforces signature verification.

Sometimes it’s a hardware thing. Newer chips can come with programmable fuses that can be set to pop. This literally severs an electrical connection within the soc or cpu or whatever and then that is the flag. The nintendo switch’s tegra used this to prevent downgrading; if you upgraded legitimately you’d “burn fuses” and then would be locked on that firmware permanently. downgrading could potentially brick the system. (Maybe someone’s figured out a way around this now, I haven’t fucked with switch stuff since tears of the kingdom came out).

There’s other ways too.

Defeating these methods is generally quite difficult. Sometimes you get lucky and a glaring bootloader exploit is found early on (fusee gelee for the switch) or one that applies to many generations of hardware (checkm8, unpatchable bootrom exploit for iphone 4s-iphone x) but at the same time companies have learned to harden their shit as much as possible and throw money at people who do find these exploits. Even nintendo, who has been notoriously laughably bad at this kind of thing seems to have come much harder at the switch 2. The only thing released to date is a minor userland exploit and even if something more substantial is released they’ll just brick your console for finding/running it

Obfuscation.

Nothing is truly unhackable. The difficulty lies in being unable to undo/retry any failed attempts because you don't have an easy way to read or write to the hardware once you've done it wrong.

Which means if your attempt fails, this probably just means that you're throwing the device away since you can't fix it without access

Great answers here, just gonna add that practically everything is hackable, it's just a question of how hard and what level of access is needed.

Sometimes to hack a device you might need to remove parts and solder in replacements, and that is already a level that is unrealistic for most.

Sometimes it's worth the trouble:

https://www.youtube.com/watch?v=dT9y-KQbqi4