Boot ROM

The boot ROM or bootROM is a type of ROM that is used for booting a computer system.[1]

Why it used

Upon power up hardware usually starts uninitialized. To continue booting system may need to read bootloader from some peripheral device. However, hardware itself isn't necessarily sophisticated or flexible enough to sequence this operation. This problem could be solved by placing ROM in well known fixed location immediately available to CPU upon power up. Boot ROM often placed on same die as CPU, however external boot ROMs also exist, especially in older systems. External boot ROMs also used to provide new features, e.g. some network cards allow their computers to boot from network by providing relevant boot ROM implementing relevant network protocols.

Operation

After the voltages have stabilized and that the hardware is ready to start booting, the processor jumps to the address where the Boot ROM is mapped in memory. The code in the boot ROM is then run by the processor.

The boot ROMs will then initialize the hardware busses and peripherals needed to boot. In some cases the bootrom is capable of initializing the RAM, and in other cases it's up to the bootloader to do that.

At the end of the hardware initialization, it will try to load a bootloader from external peripheral(s) (like an eMMC, a microSD card, and so on) or through specific protocol(s) on a buses for data transmission (like USB, UART, etc).

In many System on a chip, the peripherals or busses from which the bootrom tries to load the bootloader from, and the order in which it tries to do that can be configured. This configuration can be done by blowing some electronic fuses inside the System on a chip that are then used to encode that information, or by having specific pins of the System on a chip high or low at boot.

Some boot ROMs are capable of checking the digital signature of the bootloader and refuse to run it and stop the boot if its signature is not valid or that it has not been signed with an authorized key. With some bootroms the hash of the public key needed to verify the signatures is then encoded in electronic fuses that are inside the System on a chip. Some System on a chip bootroms also support a Public key infrastructure and the hash of the CA public key is encoded in the electronic fuses instead, and the bootrom will then be able to check if the bootloader is signed by an authorized key by verifying that key with the CA public key (whose hash is encoded in the electronic fuses).[2][3].

That feature can then be used to implement security features or as hardware root of trust in a Chain of trust, but once configured, users are denied the freedom to replace the bootloader with the one they want. Because of that it has raised strong concerns from the free software community.[4]

Right before jumping to the bootloader, some system on a chip also remove the bootrom from the memory mapping, while other don't, making it possible to dump the bootrom from later analysis.[3] If the boot ROM is still visible, bootloaders can also call the code of the boot ROM (which is sometimes documented).

Suspend to RAM

When a System on a chip enters suspend to RAM mode, in many cases, the processor is completely off while the RAM is put in self refresh mode. When that happens, at resume, the boot ROM is executed again and many boot ROM are able to detect that the System on a chip was in suspend to RAM and can resume by jumping directly to the kernel which then takes care of powering on again the peripherals which were off and restoring the state that the computer was in before.

Specific implementations

Allwinner

On many Allwinner System on a chip (A10, A20, A64), the boot ROM either waits for a bootloader to be loaded through USB (if a specific PIN is high) or tries to boot on several peripherals in a fixed order.[5]

Some Allwinner System on a chip can verify the signature of the booloaders.[6] But most devices being manufactured are not configured for that. This has enabled the Free and open-source software to add support for many the Allwinner System on a chip and devices using them in bootloaders like U-Boot.[7]

Apple

On iOS devices, the boot ROM is called "SecureROM".[8] It is a stripped down version of iBoot. It provides a Device Firmware Upgrade (DFU) mechanism, which can be activated using a special key combination.[9]

NXP

The Boot ROM of NXP System on a chip support configuring the peripherals through specific pins of the system on a chip. On the I.MX6 family it also supports configuring the boot order through efuses.

The Boot ROM of several NXP System on a chip have many ways to load the first stage bootloader (from eMMC, microSD, USB, etc).

Several NXP System on a chip can be configured to verify the signature of the bootloaders. Many devices with such System on a chip were sold without that configured and on them users can install the bootloader they want, including several Free and open-source software bootloaders like Das U-Boot[10] and Barebox.

Texas Instruments

The Boot ROM of several Texas Instruments System on a chip support configuring the peripherals through specific pins of the system on a chip.

The Boot ROM of several Texas Instruments System on a chip have many ways to load the first stage bootloader (which is called MLO in the System on a chip reference manuals):

  • It can be loaded from various storage devices (MMC/SD/eMMC, NAND, etc).
  • With MMC/SD/eMMC, it can be loaded directly from card sectors (called RAW mode in the manual) or from a FAT12/16/32 partition.
  • It can also be loaded from USB or UART

On the OMAP36xx System on a chip, the boot ROM looks for the first stage bootloader at the sectors 0x0 and 0x20000 (128KB),[11] and on the AM3358 System on a chip,[12] it additionally looks at 0x40000 (256KiB) and 0x60000 (384KiB). In both cases its maximum size is 128KiB. This is because the (first stage) bootloader is loaded in an sram that is inside the System on a chip.

The OMAP and AM335x System on a chip can be configured to verify the signature of the booloaders. Many devices with such System on a chip were sold without that configured and on them users can install the bootloader they want, including several Free and open-source software bootloaders like Das U-Boot[13] and Coreboot[14] and Barebox.

STMicro STM32

STMicro STM32 family microcontrollers have builtin on-chip ROM (also referred as "builtin bootloader") [15] to facilitate empty system flashing. Certain pins combination or sometimes efuse and/or empty flash check forces chip to boot from ROM instead of firmware in main flash. This allows empty chips to be flashed without resorting to hardware programming interfaces. Technically this ROM stored in dedicated area of flash array and programmed by STMicro during production. Most STM32 can at least be flashed over UART, some support USB and eventually other interfaces like e.g. I2C, SPI or CAN. Cortex-M CPU core normally fetches vectors from well known address 0x00000000 (initial stack pointer value) and 0x00000004 (initial program counter value). However pins and/or fuses define which memory is mapped at these addresses. Builtin boot ROM is one of mapping options, another would typically be main firmware in flash, in this case firmware supposed to do all jobs boot ROMs do, part of firmware could act as boot loader similar to ST's boot ROM. Hardware could provide read-only enforcement on boot area, turning it into user-provided version of boot ROM.

Known vulnerabilities and exploits

Apple

On devices running iOS, Boot ROM exploits (like Limera1n[16]) are sometimes used for iOS jailbreaking. The advantage for people wanting to jailbreak their devices over exploits that affect iOS is that since the Boot ROM cannot be modified (and that device running iOS don't have fuses to append code to the bootrom), so Apple can't fix the vulnerability on existing devices.

Nintendo Switch

The boot ROM of the Nintendo Switch contained a vulnerability which makes it possible for users to run the bootloader they want.[17][18]

See also

References
  1. Bin, Niu; Dejian, Li; Zhangjian, LU; Lixin, Yang; Zhihua, Bai; Longlong, He; Sheng, Liu (August 2020). "Research and design of Bootrom supporting secure boot mode". 2020 International Symposium on Computer Engineering and Intelligent Communications (ISCEIC): 5–8. doi:10.1109/ISCEIC51027.2020.00009. ISBN 978-1-7281-8171-4. S2CID 231714880.
  2. Secure boot (Mk II)
  3. Emulating Exynos 4210 BootROM in QEMU, 7 March 2018
  4. Single-board computers
  5. BROM linux-sunxi article
  6. SID Register Guide article on the linux-sunxi wiki
  7. U-Boot page on linux-sunxi wiki
  8. "Bootrom article on The iPhone Wiki".
  9. Todesco, Luca. "The One Weird Trick SecureROM Hates" (PDF). Archived (PDF) from the original on 2019-11-08.
  10. imx6.txt
  11. OMAP36xx reference manual (swpu177aa.pdf), 26.4.7.6 MMC/SD Cards
  12. AM3358 reference manual (spruh73p.pdf), 26.1.8.5 MMC / SD Cards.
  13. README.omap3
  14. Beaglebone Black
  15. AN2606 Application note (PDF)
  16. "limera1n article on the iPhone wiki".
  17. "Hackers find an 'unpatchable' way to breach the Nintendo Switch". Engadget. Archived from the original on 2020-11-09. Retrieved 2021-09-30.
  18. Vulnerability Disclosure: Fusée Gelée, 28 October 2021
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.