Wednesday, April 24, 2013
Comparison of Android and iOS Boot Processes
Android is an open source linux based operating system for mobile devices. This code base is often cross compiled to run on ARM processors, which most of the high end smartphones use. Many of these smartphone use the latest OMAP technology from Texas Instruments.
When the system is first powered on, the BOOT ROM loads the Stage1 bootloader from NAND Flash into internal RAM and executes it. It then detects the location of external RAM then loads Stage2 bootloader into the RAM. OEMs restrictions and locks are often placed here.
Stage2 bootloader set ups the network, memory, and everything else that is required to run the kernel.
The kernel sets up the cache, protected memory, scheduling, and loads drivers. When the kernel is finished loading, it starts the init process.
The init process is the first process of the system and is similar to /etc/init.d found on linux systems. The init process considered the root process of all processes. It mounts the standard directories onto the filesystem and runs the init.rc script. Init sets up the environment and starts the zygote process. The portion of the init.rc file below is from my Motorola Droid Bionic running Android 4.x. It gives insight on how the environment is setup in Android.
Zygote and Davlik
Zygote and Davlik are loaded. Davlik is the virtual machine used to interpret Java bytecode on android. Davlik uses Zygote on Android so that a separate VM is not needed for each app, as is standard on desktop operating systems. Zygote allows code to be shared across the Davlik VM and thus lowers the memory footprint and startup time of apps.
System Services are launched next. These include the power manager, battery service, bluetooth service, etc. Once all system services have been loaded, the boot process is considered and fires the standard broadcast action, “ACTION_BOOT_COMPLETED” and the device is read for usage.
The iOS boot process is fairly similar but with enhanced security features. The BOOT ROM is read only and therefore cannot be modified as designed. This is an added security feature but also its weakness because any exploits discovered will stay vulnerable until Apple releases a new hardware device and the end user has to buy the new one.
iOS uses a secure boot chain. That is each stage of the boot process verifies the digital signature of the next before executing it. When the iPhone device is powered on, the BOOT ROM, which is hard-wired during chip fabrication, is loaded into VROM (Virtual ROM) and executed. Inside the BOOT ROM is the Apple’s Root Certificate Authority (CA) public key. It uses the public key to verify the digital signature of the LLB (low level bootloader) before executing it. The LLB is similar to the Stage1 bootloader on Android. The LLB loads iBoot, which is similar to the Android Stage2 bootloader, and then runs the iOS kernel and then the System Software. This completes the boot process for iOS.
Android uses an open architecture which allows third party manufacturers to install their own custom NAND Flash to provide customizations for their device. This open design allows people to install their own ROMs and OS images by design. If the Android NAND Flash were erased and filled it with a custom program, then you can bypass any OEM restrictions and locks. Typical ROMs can be found at: cyanogenmod.
iOS, on the other hand, is a closed architecture and does not allow interoperability with other device manufacturers. Apple wants to be the only one who manufactures the iPhone. It has long been Apple’s strategy to provide both hardware and software together and lock out third party hardware vendors.