I only recently started looking into smartphones (got two android devices to play with just this winter), and some things seem surprising and strange to me, since I'm coming from a PC (GNU/Linux) background. So several technical questions come to mind when trying to learn more about this. One thing I'm curious about is the fimware layer, that is, the part that connects the hardware to the OS, on generic current smartphones, and how it differs from what we currently have on PCs.
On PCs, everything is relatively simple, the UEFI is the central firmware that handles hardware initialisation and starting a payload (bootloader or OS). One thing PC users come to expect is that UEFI allows booting from different media, be it several hard disks, external storage, DVD etc. And UEFI acts as a sort of bootloader itself, having the ability to list registered EFI files and boot from them (although vendor implementations vary here).
So the standard boot procedure on PCs is like this: UEFI starts the hardware, selects the first UEFI boot entry, loads a bootloader (typically GRUB), the bootloader presents the user with a list of OSs and loads the selected OS (GNU/Linux or Windows). There are variations of this (notably Coreboot that can skip all the middlemen and start the OS directly), but what I described is a typical modern dual-boot scenario.
It seems that a lot of these assumptions don't work for current smartphones. You usually have a "locked bootloader" (already raises a question: is this really a bootloader, or is that a part of the firmware? Where is it, in the internal memory – the "hard disk" – or on a separate reserved flash storage?). Often times you can unlock said "bootloader" (it seems that this was a major consumer victory at some point).
When it's "unlocked", then you can install something called a "recovery". (One of the two devices has TWRP installed and I know how to use it, but not exactly how it works.) Oddly enough, it seems that a "recovery" is even expected to be installed after "unlocking the bootloader" by the manufacturer itself (the service menu on my HTC device has an option literally called "Recovery"). From what I can tell, this recovery is something a bit similar to what the bootloader on PCs does (TWRP allows creating and switching between "ROM slots", which is pretty much boot entries), but it also has backup/restore functionality (from what I can tell, that means creating an image of all OS files and dumping it into a specified directory), partitioning functionality, and some tools for offline modification of the OS ("ZIP flashing" and such).
Tasks like that on PCs are usually done either from within the OS, or by booting from external media (which is safer). So here the question is, what prevents doing that on smartphones? Why doesn't the "recovery" act like a standard bootloader: allow selecting between OSs to boot, and if there is an SD card with recovery software on it inserted, boot from it?
Then the "ROMs" themselves. On PCs, you just insert installation media and install whatever you like (minding the partitions and dealing with OS driver support). What prevents doing that on smartphones? This probably follows from the last question, but why can't you insert an SD card with, say, a Gentoo ARM base system, then use it to bootstrap an installation on internal storage?
On a related note, I'm unpleasantly surprised with the whole Android "rooting" thing. On GNU/Linux, such a thing is unfathomable. You install the OS and you set the root password. In the current smartphone world it's like the manufacturer owns the smartphone, not you, and refuses to give the root password for some notorious reason... This also brings up a question: if users don't get the root password, what is the security system on Android like? On GNU/Linux you can't install any application without root rights, which is fair because that means you will think twice before installing applications, and viruses can't destroy your system or change any system configuration files because that requires a root password.
And then about the firmware itself. Does it work different from UEFI, and if so, how? Are there any standards, like UEFI is on x86? Can the firmware be replaced (like it is possible on x86 with Coreboot)?
Thanks for any information you can give me on all these questions :)
On PCs, everything is relatively simple, the UEFI is the central firmware that handles hardware initialisation and starting a payload (bootloader or OS). One thing PC users come to expect is that UEFI allows booting from different media, be it several hard disks, external storage, DVD etc. And UEFI acts as a sort of bootloader itself, having the ability to list registered EFI files and boot from them (although vendor implementations vary here).
So the standard boot procedure on PCs is like this: UEFI starts the hardware, selects the first UEFI boot entry, loads a bootloader (typically GRUB), the bootloader presents the user with a list of OSs and loads the selected OS (GNU/Linux or Windows). There are variations of this (notably Coreboot that can skip all the middlemen and start the OS directly), but what I described is a typical modern dual-boot scenario.
It seems that a lot of these assumptions don't work for current smartphones. You usually have a "locked bootloader" (already raises a question: is this really a bootloader, or is that a part of the firmware? Where is it, in the internal memory – the "hard disk" – or on a separate reserved flash storage?). Often times you can unlock said "bootloader" (it seems that this was a major consumer victory at some point).
When it's "unlocked", then you can install something called a "recovery". (One of the two devices has TWRP installed and I know how to use it, but not exactly how it works.) Oddly enough, it seems that a "recovery" is even expected to be installed after "unlocking the bootloader" by the manufacturer itself (the service menu on my HTC device has an option literally called "Recovery"). From what I can tell, this recovery is something a bit similar to what the bootloader on PCs does (TWRP allows creating and switching between "ROM slots", which is pretty much boot entries), but it also has backup/restore functionality (from what I can tell, that means creating an image of all OS files and dumping it into a specified directory), partitioning functionality, and some tools for offline modification of the OS ("ZIP flashing" and such).
Tasks like that on PCs are usually done either from within the OS, or by booting from external media (which is safer). So here the question is, what prevents doing that on smartphones? Why doesn't the "recovery" act like a standard bootloader: allow selecting between OSs to boot, and if there is an SD card with recovery software on it inserted, boot from it?
Then the "ROMs" themselves. On PCs, you just insert installation media and install whatever you like (minding the partitions and dealing with OS driver support). What prevents doing that on smartphones? This probably follows from the last question, but why can't you insert an SD card with, say, a Gentoo ARM base system, then use it to bootstrap an installation on internal storage?
On a related note, I'm unpleasantly surprised with the whole Android "rooting" thing. On GNU/Linux, such a thing is unfathomable. You install the OS and you set the root password. In the current smartphone world it's like the manufacturer owns the smartphone, not you, and refuses to give the root password for some notorious reason... This also brings up a question: if users don't get the root password, what is the security system on Android like? On GNU/Linux you can't install any application without root rights, which is fair because that means you will think twice before installing applications, and viruses can't destroy your system or change any system configuration files because that requires a root password.
And then about the firmware itself. Does it work different from UEFI, and if so, how? Are there any standards, like UEFI is on x86? Can the firmware be replaced (like it is possible on x86 with Coreboot)?
Thanks for any information you can give me on all these questions :)
Aucun commentaire:
Enregistrer un commentaire