Interaction-less update #3363
Interaction-less update #3363
Conversation
|
@TychoVrahe please take a look at the latest changes |
|
@mmilata please take over the outstanding UI issues, namely:
|
There was a problem hiding this comment.
The CI issues are still pending:
- boot args not defined in unix/emulator
- also the new flash_area_erase_partial funciton is not defined for unix, mentioned below too
- legacy does not compile due to the changes in reboot to bootloader message (nanopb is used there unlike in core firmware)
sorry, what I meant is "waiting for host" |
|
The UI + python changes are in #3371, feel free to merge or cherry-pick. |
|
minor nit: we should also check |
|
... firmware (python) doesn't need to check that (for this PR). It doesn't seem practical to export the vtrust flags to python just for this purpose, so maybe just "if vendor name is UNSAFE DO NOT USE" then reject or something dumb like that. going forward this might be a compile time flag, something coming from modtrezorutils or somesuch. |
matejcik
force-pushed
the
cepetr/interless-update
branch
from
cc291e5 to
b147929
Compare
…gned/unsigned arithmetic mix
It would be nice to hide this behind a compile-time flag, but doesn't seem worth introducing one just for it.
matejcik
force-pushed
the
cepetr/interless-update
branch
from
b147929 to
c5817be
Compare
|
QA OK Info:
|
This pull request primarily involves a significant update, commonly referred to as an "interaction-less update,".
resolves #2919
resolves #2794
The interaction-less update can be initiated via the command line using
trezorctl fw update. However, several conditions must be met for this to work:If any of these conditions are not met, the standard firmware upload via the bootloader is selected. Additionally, users can manually enable or disable the interaction-less update by specifying the--iluor--no-iluoptions.The interaction-less update process begins on the
trezorctlside by sending aRebootToBootloadermessage. This message has been extended to include two optional parameters:bootCommandandfirmwareHeader. In this context,bootCommandis set toINSTALL UPGRADE, andfirmwareHeadercontain the new firmware headers (the first ~5.5KB of the binary).When the firmware receives the
RebootToBootloadermessage with theINSTALL UPGRADEcommand, it parses and checks the provided firmware header. It compares the vendor and version fields with the current firmware. If the vendor is the same, and the version is higher, it displays a confirmation dialog. Once the user confirms the firmware upgrade, the firmware proceeds to jump to the bootloader.A new interface between the firmware and the bootloader has been implemented. The firmware can now jump to the bootloader and provide a command (enum) and arguments (up to 256 bytes). In this case, the firmware jumps to the bootloader with the
INSTALL_UPGRADEcommand, and the arguments are set to the hash of the vendor and image header received in theRebootToUploadermessage.When the bootloader is initiated and detects the
INSTALL_UPGRADEcommand, it skips the initial screens and immediately starts waiting for host commands.Following this,
trezorctlcontinues with the standard firmware update process, which includes uploading the new firmware. The bootloader checks whether the uploaded firmware header has the same hash as the firmware confirmed by the user. It also performs the same checks as the firmware (comparing vendor and version). If the firmware is the same and newer, it proceeds with flashing the firmware without further confirmation.