Bootloader Basics

Did you ever wonder what a bootloader is? You often hear about bootloaders in the context of safety critical applications and software updates. This article describes the basics of bootloaders for microcontrollers and how it can help you with your application.

1.1 Important concepts & definitions

In order to prevent confusion with the naming we chose the following names for the 3 different pieces of software, which we will talk about in this article:

1. 01Firmware: This is the main software application, which the microcontroller (target) is supposed to run. For example, if your target shall perform a task which controls a motor, this would be your main software application — or your firmware.
2. 02Bootloader: This is technically speaking also firmware, but for the sake of simpler differentiation the bootloader will only be called by its own name. This software runs on the microcontroller.
3. 03Host application: This is a software application that enables you to interact with your bootloader. This application can run on different platforms, but for the mentioned examples here, it runs on a laptop.

Why do you need a bootloader? To keep it short: A bootloader focusses on two aspects: firmware updates and a secure booting procedure.

1.2.1 Firmware updates

A bootloader on a microcontroller lets you update its firmware without any complicated tools. That means, you can update your firmware over the existing communication bus (e.g. CAN Bus, WiFi / Bluetooth) which you also use for all other communication.

Without a bootloader, you can only update the firmware using specialized equipment, which needs to be directly wired to the microcontroller.

1.2.2 Secure boot

A bootloader enables your system to only run trusted firmware. This can be done as follows:

• The bootloader verifies the firmware before starting it.
• The bootloader has policies, which help it mitigate a corrupted firmware image.

So to sum it up: A bootloader makes it simpler to update the firmware on the target and it also makes it more secure.

1.3 What is a bootloader?

In essence, a bootloader is a small software application that runs before your main application (firmware) is launched after a system restart. It is the first application that is executed when the system starts up.

You can see the bootloader as an independent application. It can be developed separate from the main application (firmware). Integrating a bootloader means flashing it to one part of your flash memory while placing your main application (firmware) in another.

1.4 How does it work?

1.4.1 Bootloader context

A bootloader is only part of a larger software system. A bootloader is not working on its own. It only executes the input commands. In order to create these input commands you also need a second program: the host application. This program can for example run on your computer.

To give you a quick example, how this plays out: You send a command on your host program, then the bootloader executes the action and responds with a status or the requested information. In this small example, the user wants to know which version of the code is flashed on the target. So he uses the host application to issue the command to the bootloader, then the bootloader reads the software version and then returns it to the user. This information can be used to determine whether or not this system needs an update to the latest firmware version.

1.4.2 Internal workings

We now know the bootloader's context and how commands are executed. But how does the bootloader work internally? When the system starts with the bootloader, it waits for an incoming command. If a command arrives over the communication interface, then the bootloader executes the corresponding action. Just to name a few examples of what this might be:

• "get main app image firmware version", which makes the bootloader return the image's version number
• "run self-test" can perform a system self test
• "update main app image" allows for the main app image to be updated
• "launch main app" launches the main application

This list is by no means complete. There are many more actions that can be done in the bootloader. For the case that no command arrives within a defined timeout period, then the bootloader commences to launch the main app. The execution jumps into the main application.

2.1 How does a bootloader help with firmware updates and security?

2.1.1 Firmware updates

In this section, we will have a more detailed look on how the bootloader can update the main application firmware on the target. This is still simplified and shall only serve the purpose of giving an overview.

A bootloader does not perform the firmware update all by itself. It requires a host application which sends the firmware image, so that the bootloader can store it in the memory.

• The host application needs to load the main application firmware image and decompose it into several smaller chunks. The data can only be transferred chunk-wise with a serial communication interface. Then the host application sends these chunks one by one.
• The bootloader verifies the successful reception of the chunks. When all chunks were received the bootloader reassembles the complete firmware image on the target. After completion the bootloader can launch the main application.

2.2 Secure system boot

This mechanism ensures that only trusted firmware is executed on the target, rather than a corrupted version from an external party. This problem statement can be summed up by these 3 questions:

1. 01How can I prevent the bootloader from being corrupted in the first place?
2. 02How can I make sure that only trusted firmware is executed on my target?
3. 03What do I do, when I figured that the firmware image is corrupted (for whatever reason)?

2.2.1 How to prevent bootloader corruption?

The bootloader handles a lot of safety critical functions, like updating firmware or verifying the integrity of said firmware. If the bootloader breaks, the firmware can not be launched again and firmware updates can't be done. Since it contains a lot of mission-critical features, it is also the target to malicious actors. To protect the bootloader itself the following measures can be taken:

• Locking Bootloader Memory — prevents accidental overwrites or malicious tampering of the bootloader code.
• Hardware Security Modules (HSMs) — some microcontrollers offer hardware security features for securely storing cryptographic keys.
• Encrypted Firmware Storage — storing firmware in encrypted form prevents unauthorized access.

By implementing these security measures, the bootloader ensures that the system only boots valid, trusted firmware.

2.2.2 How to only execute trusted firmware on your target?

To ensure that only trusted firmware is executed, the bootloader can implement a secure boot process. This typically involves the following steps:

1. 01Signature Verification — the bootloader checks a signature attached to the firmware image. This ensures that the image was created by a trusted source and hasn't been modified.
2. 02Hash Integrity Check — a checksum of the firmware image is computed and compared to a pre-stored checksum value to verify data integrity.
3. 03Anti-Rollback Protection — some secure boot implementations enforce version control to prevent downgrading to an older, potentially vulnerable firmware version.
4. 04Memory Protection — the bootloader can enforce memory access restrictions, preventing unauthorized modifications to critical firmware sections.

By following these steps, the system can prevent malicious firmware from being executed and safeguard against accidental corruption.

2.2.3 What to do, when the firmware is corrupted?

The bootloader is also able to handle corrupted firmware images. This can happen when the integrity check of the secure boot mechanism fails. The user can define which recovery actions should be taken, and the bootloader will execute them either automatically or on command. These following actions can be taken:

• Rollback to a Previous Image — if a backup firmware image is stored in flash memory, the bootloader can revert to a known good version.
• Enter Safe Mode — the system may enter a failsafe mode, allowing only limited operations until a valid firmware update is provided.
• Request a New Firmware Update — the bootloader can signal the host system to re-initiate the firmware update process if an image corruption is detected.

3. Summary and how AGSOTEC can help

This article laid out the basics of bootloaders, but there are many more features which can be tailored to a specific application:

1. 01Firmware updates without specialized hardware — enables updates via UART, USB, SPI, CAN, I2C or OTA instead of JTAG/SWD and simplifies field updates without physical access to the device.
2. 02Enhanced security & integrity checks — supports secure boot to verify firmware authenticity, detects corrupted firmware using hash verification and prevents unauthorized code execution.
3. 03Rollback & redundancy — allows multiple firmware images for safe rollback if an update fails and ensures device reliability in critical applications.
4. 04Separation of bootloader & main application — the bootloader runs independently, allowing easy debugging and maintenance, and reduces the risk of firmware corruption during updates.
5. 05Automated & remote updates — enables firmware updates over standard communication interfaces and supports OTA updates for wireless devices.
6. 06Improved system stability — ensures only validated software is executed and reduces bricking risk due to faulty updates.
7. 07Customizable for specific needs — can be tailored for encryption, authentication and fail-safes.

Originalbeitrag: agsotec.de