Bootloader redesign for Trezor T 🥾

[tsusanka]

Spec: Notion Design: Zeplin and here:

Text to be finalized.

---

A nice to have feature from Product is to slightly redesign the bootloader. Prerequisites are:

• #1039
• #60

---

Our general idea is to have a homescreen with a user-friendly explanation what just happened and what bootloader is. Next to that we are proposing a hamburger-like menu. This menu contains:

• Display firmware info (header and version)
• Display firmware fingerprint
• Factory reset (wipe including the firmware), basically #60
• Launch firmware (= reboot) - Boot counter (maybe), https://github.com/trezor/trezor-firmware/issues/154

[tsusanka]

Also #994 should be taken into account.

[tsusanka]

Let's do this for both T1 and TT bootloader.

[tsusanka]

@hiviah we will prepare the design however this issue is the foundation of what we would like to have in the next bootloader release. So while we prepare the design we can make funcionality for the items mentioned above (Display firmware info, fingerprint, wipe, reboot, boot counter).

And having https://github.com/trezor/trezor-firmware/issues/1047 would be cool as well.

[tsusanka]

Design added. Upon discussion in the Product team we have decided not to do the Boot counter #154 for now because it increases complexity of the bootloader slightly, complicates the menu (well adds one more item) and the UX is not very great anyway. So there should be only three items:

• Reboot - reboots and launches firmware
• FW info - prints firmware version and fingerprint (maybe also 'vendor' if there is space, see features)
• Factory reset - wipe (the same thing that happens when WipeDevice is received)

For the first and third item there should a screen "Are you sure?". I'll try to obtain design for that one as well.

[tsusanka]

@hiviah Design finalized in Zeplin (link above).

[mcudev]

Reboot is misleading to technical users and lacks meaning to regular users. I'd maybe suggest Launch or Continue or actually an arrow pointing forward icon or a cog icon to indicate execution. Due to restrictions set in the boardloader, the only real reboot is to unplug and since we're in the bootloader already, the only other option is forward to the firmware. FWIW, what people know as a "restart" right now is really the bootloader proceeding forward to the firmware.

A plug icon next to the hamburger that connects the USB stack and changes color to indicate being enabled when pressed could be useful.

[matejzak]

Thank you for your feedback @mcudev. As mentioned in the description of the issue, the copy is yet to be finalized (incl. the buttons).

[hiviah]

One thing to keep in mind that there is very few kB left in the lootloader (~18 kB IIRC). So just by adding the new icons converted to toif, we go gown another 5 kB downto 13 kB.

The old code is extremely hashish (or hackish)as in it uses and reuses methods - e.g. there is only one method handling all 4 possible buttons in the whole bootloader, of whose only 2 are basically used. I literally can't find any elegant code that would make the design->screens->handling nice and also not exceed those 13 kB.

[mcudev]

That's a good point about the bootloader size being capped at 128KiB.

While I'm thinking about it. Here are my thoughts on the fundamental design and properties of the bootloader:

• it is simpler (less complex) and thus better tested which allows it to be run with full privileges (higher than the priv level that firmware usually runs at -- a security feature)

• it checks the authenticity and integrity (via signatures) of the firmware and runs it if everything is OK

• if firmware authenticity or integrity checks fail, it provides a necessary repair mechanism. it does this via USB which is more user friendly than the boardloader's use of microSD (security + complexity vs. usability tradeoff). i should note that the boardloader will only repair bootloader flash sectors after it erases all flash sectors. that's why this firmware repair in the bootloader is required and not just a usability improvement.

• it provides an optional firmware override mode in-case a firmware does not provide an ability to change firmware again (this is a firmware lock-in avoidance, a security feature -- remember that the device design affords for the possibility of a firmware signed by another vendor if it has the pre-blessing of satoshilabs [enforced via vendor header signature checks]) (this is a not-strictly-required [although highly desired] usability feature because the device can always be reset via the more difficult boardloader microSD + bootloader firmware repair processes). note that the current official firmware, early in its execution, disables it's ability to write to the firmware flash sectors and then drops privileges to disable a bug in later firmware code from changing itself (modulu any security bug that allowed regaining privileges to change MPU config). i suppose there is also the question of whether an executing firmware could update itself. i think that's possible by executing from SRAM instead of flash.

• it provides an optional device reset (aka factory reset) feature as a usability improvement over the one that the boardloader provides (via the all flash erase + microSD bootloader install process)

• it provides an optional ability to identify what firmware is loaded, before and without running the firmware. this is optional, but it makes a lot of sense with the optional firmware override mode.

• it provides an optional flow for new user on-boarding. i think this is done because it's an easy way to get people on the latest firmware (by not providing one on new devices). i think people view this as a security feature too, but i don't see it as one. i think we could get the same security level with firmware that definitely and noticeably acts different when it has been configured with a seed ("hey! your device is not setup right now. it'd be a great time to check for a firmware update! or, setup your device now." with buttons).

[mcudev]

Another idea is to have different bootloaders. Since the firmware can change the bootloader, we could have a first run bootloader that focuses on clearing non-bootloader flash sectors and getting the latest firmware. That firmware could replace the first run bootloader with the normal bootloader. To reset the device, a firmware could put the first run bootloader back. Seems technically possible. Would need to think through usability.

[Hannsek]

Additional screens for redesigned bootloader: Waiting for host Confirm to wipe Wiping device Fail Welcome screen successfull FW instalation succesfull wiping do you want tu install FW

For now, we have decided not to include Fingerprint screen in the bootloader. Because of that, firmware info from the menu screen has to be removed. New screen:

[Hannsek]

There were some changes regarding Bootloader screens: rebooting, fail, welcome screen. Also, some new screens were added. See https://www.figma.com/file/l0gG9XeRJ8FTDQ3cfb1wv9/Trezor-T%2C-Trezor-One?node-id=4081%3A19006

[sime]

Please solve #2316 before closing.

[Hannsek]

RSOD + wipe code entered: