OMAPBootrom¶

Generic documentation¶

• check the various SOCs the sram size limit in the TRM.
• check the load address / memory mapping of MLO in case of USB boot or boot from eMMC in the TRM.
• Check mmc1 booting constraint (card size, look if < 4GiB works) in the TRM

• Read the TRM sections about SYS_BOOT and booting and document that, ideally write a tool for it, or upstream the code in some other tool.

Documentation¶

The droiddevelopers website has some information on trying to use bugs run free software on several Motorola devices.

• It has documentation on the structure of signed MLOs

• Read droiddevelopers more to understand restricted boot better.
• Also the OMAP wiki might have some information on OMAP restricted boot.
• Also look if there is substancial information in the Technical Reference Manual (TRM) about fuses but that's unlikely.

Code¶

• As march 2020, there are no fuses driver or code for any OMAP in either u-boot, Barebox, Linux, or crucible.
• U-boot documentation mention TI tools that have to be obtained after signing an NDA
• TODO: check if chipsec has infos on OMAP fuses

Possible attacks¶

• Even if it's unlikely, once we understand the OMAP restricted boot better, we could check if some devices are signed but not in enforcing mode.

Simply replacing the SOC with a GP version¶

On IRC there was some interest in replacing the SOC by simply unsoldering it and resoldering a GP OMAP.

For some SOCs like the Allwinner A20, it looks relatively easy to do . That is probably not the case for every SOCs as simply soldering a SOC can be really complicated sometimes (look for reballing for more details on how things can go wrong, and how it's typically repaired).

• Identify the very precise SOC.
• Make sure that POP is not needed. It's a pain to find factories that still know how to do that. See the issue that the GTA04 and the Neo900 are having with that. Note that this can sometimes be seen in the bootloader the source code in the code that tries to identify the device or RAM chip. if the eMMC and the RAM chips are together in the same package, it's then possible to identify the RAM chip simply by identifying which eMMC is there (eMMC have vendor and product IDs among other information).
• Make sure it's easy enough to do for people doing microsoldering board level repairs.
• Ideally make sure that the SOC replacement is safe for the environment (RHOS, CE, no lead, etc)
• Find a way to test the device once the SOC has been replaced for the very first time: We can compile the Xloader source code and load that, and get some prints on the UART, however we need to make sure that we can work in tandem with the person doing the SOC swap in order to validate that everything works together. If not, that person might just restore the normal bootloader and declare the "reparation" a success for instance. Or the person might expect the display to work or to have the stock bootloader which might not even work in GP mode because we don't have TrustZone there. The downstream Linux might not even work either because of TrustZone and the upstream Linux might lack a display driver for instance.
• Write code that init the display and probably does a complete test of the device to make it easier for people that swap the OMAPs to check if the device works.
• Find how to handle the amount of work combined with the insecurity of the supply chain for the OMAPs: If we buy only 1 OMAP and do a lot of work, and when the work is done we can't find any anymore, it would not be a good idea. If we buy a lot and nobody does the work it won't be a good idea either. We don't want to force people to work on things either as it would be a very strong attack on their freedom.

Devices:

¹ We need to check which exact model variant it is. Ifixit usually use the generic model like Galaxy SII instead. And on some variant even the SOC can differ.

² See the Step 12 of the Galaxy Nexus Teardown by Ifixit

• Replicant 6.0 support is not that important because if we get rid of TrustZone we will probably not be able to run the downstream kernel.

• hpagseddy on #replicant on Freenode is interested in working on the hardware parts of it.

Links¶

• http://www.droid-developers.org : This attempts to run user code on several Motorolla smartphones. It includes analysis of the boot chain:
  • Application_Processor_Boot_ROM
  • Booting_chain