Hacker News Reader

I don't disagree, but it leads to the question from the security guy: how do you fix CVEs in the bootloader after it's shipped (aka in the field)?

View on HN

If you anticipate the need to update the bootloader, you would use a multistage bootloader approach where the first is never altered (as the bootloader should never be altered) and its main function is to select which updatable second stage bootloader to load from multiple options (multiple so that even if one is interrupted mid-update by the application, there is a valid fallback).

My gut says if you're worried about this in the bootloader, it might be doing too much.

Particularly neat approach to both reducing the attack surface of the bootloader and improving the reliability of the actual OTA update process is to have only the bootloader flash the active application/second-stage flash partition. The idea is that the normal application code somehow acquires the new version, verifies it and writes it into separate flash partition and then reboots, bootloader sees that record and, does minimal check for correctness and flashes that to right location. That way the bootloader does not have to know anything about how to get the new firmware image and does not process any untrusted input.

You don't.

When I actually have these conversations with security guys, it's because they've either missed their window on contributing to part selection (in one case because that team hadn't been hired yet!) or no one consulted them in the first place. In both cases the solution is to write some guidelines and get the EEs to use them during part selection in the future.

Reply on news.ycombinator.com