Why are bootloaders in rewritable storage?


Question

I successfully flashed my device a few times, but I am still paranoid about hard bricks. I am sure I can use my Arduino to fix them, but this made me wonder why bootloaders are stored in rewritable storage. I am aware that there is a PBL and an SBL and all that, and the PBL is in ROM. In this context, "rewritable storage" means a storage medium that can be electronically rewritten (EEPROM, Flash, RAM, etc) and "ROM" means read only storage, not aftermarket Android distributions such as Lineage OS.



Summary:
Why would code that is required to even turn the phone on, not to mention booting Android, be stored in a location that can be rewritten.


Answer

Andy mentions some of the benefits for later upgrade in the field, and these are good points, but there's more to it than that. The bootloader doesn't just need to boot the primary OS, but also the "charging mode", which is itself an embedded Linux kernel. The bootloader needs to bring up the hardware to be a USB endpoint and to talk the fastboot protocol, so that it can receive and flash new recovery and system images. It also has to perform signature validation on those images, using a quite complicated block-based scheme so validation doesn't slow down boot time.



So what? Why does any of this functionality need upgradeability? Because it's complex enough to contain bugs. The original XBox bootloader was 512 bytes long and contained two critical security errors, one of which made it possible to run unsigned code on consumer devices. It wasn't possible to update it in the field. Right away, their main security and anti-piracy mechanism became worthless. Phone manufacturers do not want to have those bugs. They make the bootloader updateable so that the device can be upgraded in the field, and so that it's easier to test and develop the bootloader against the real hardware. It's much harder to develop and test code that will be baked into a ROM - and that extra complexity means there would be more bugs and that phone development would be slower, missing the important launch deadlines.



Having an upgradeable bootloader is only a problem if you try to flash firmware to the phone and screw up. This simply isn't a problem for almost all of the phone market. It's only the crazy hobbyists who brick their phones this way. Worse yet, moving this complex bootloader into ROM wouldn't prevent bricking. There are still many ways a broken firmware can damage the device: by overheating it, by uploading a broken radio firmware, by blowing fuses in the secure element, &c.



So overall, there's a huge cost to putting more complex software somewhere that's hard to test and debug, and can't be patched to add functionality or fix bugs. There's no advantage at all for almost all users, and even those users who insist on shooting themselves in the foot would still have other ways to do that.


Topics


2D Engines   3D Engines   9-Patch   Action Bars   Activities   ADB   Advertisements   Analytics   Animations   ANR   AOP   API   APK   APT   Architecture   Audio   Autocomplete   Background Processing   Backward Compatibility   Badges   Bar Codes   Benchmarking   Bitmaps   Bluetooth   Blur Effects   Bread Crumbs   BRMS   Browser Extensions   Build Systems   Bundles   Buttons   Caching   Camera   Canvas   Cards   Carousels   Changelog   Checkboxes   Cloud Storages   Color Analysis   Color Pickers   Colors   Comet/Push   Compass Sensors   Conferences   Content Providers   Continuous Integration   Crash Reports   Credit Cards   Credits   CSV   Curl/Flip   Data Binding   Data Generators   Data Structures   Database   Database Browsers   Date &   Debugging   Decompilers   Deep Links   Dependency Injections   Design   Design Patterns   Dex   Dialogs   Distributed Computing   Distribution Platforms   Download Managers   Drawables   Emoji   Emulators   EPUB   Equalizers &   Event Buses   Exception Handling   Face Recognition   Feedback &   File System   File/Directory   Fingerprint   Floating Action   Fonts   Forms   Fragments   FRP   FSM   Functional Programming   Gamepads   Games   Geocaching   Gestures   GIF   Glow Pad   Gradle Plugins   Graphics   Grid Views   Highlighting   HTML   HTTP Mocking   Icons   IDE   IDE Plugins   Image Croppers   Image Loaders   Image Pickers   Image Processing   Image Views   Instrumentation   Intents   Job Schedulers   JSON   Keyboard   Kotlin   Layouts   Library Demos   List View   List Views   Localization   Location   Lock Patterns   Logcat   Logging   Mails   Maps   Markdown   Mathematics   Maven Plugins   MBaaS   Media   Menus   Messaging   MIME   Mobile Web   Native Image   Navigation   NDK   Networking   NFC   NoSQL   Number Pickers   OAuth   Object Mocking   OCR Engines   OpenGL   ORM   Other Pickers   Parallax List   Parcelables   Particle Systems   Password Inputs   PDF   Permissions   Physics Engines   Platforms   Plugin Frameworks   Preferences   Progress Indicators   ProGuard   Properties   Protocol Buffer   Pull To   Purchases   Push/Pull   QR Codes   Quick Return   Radio Buttons   Range Bars   Ratings   Recycler Views   Resources   REST   Ripple Effects   RSS   Screenshots   Scripting   Scroll Views   SDK   Search Inputs   Security   Sensors   Services   Showcase Views   Signatures   Sliding Panels   Snackbars   SOAP   Social Networks   Spannable   Spinners   Splash Screens   SSH   Static Analysis   Status Bars   Styling   SVG   System   Tags   Task Managers   TDD &   Template Engines   Testing   Testing Tools   Text Formatting   Text Views   Text Watchers   Text-to   Toasts   Toolkits For   Tools   Tooltips   Trainings   TV   Twitter   Updaters   USB   User Stories   Utils   Validation   Video   View Adapters   View Pagers   Views   Watch Face   Wearable Data   Wearables   Weather   Web Tools   Web Views   WebRTC   WebSockets   Wheel Widgets   Wi-Fi   Widgets   Windows   Wizards   XML   XMPP   YAML   ZIP Codes