-
Notifications
You must be signed in to change notification settings - Fork 668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CONFIG_SINGLE_APPLICATION_SLOT should test and confirm #1931
Comments
It is designed this way, single application has a single slot, there is nothing to confirm or test, you enter serial recovery mode using e.g. a button or if the application is not valid and then load a new image. MCUboot serial recovery does not support image status out of the box and really has no need to in this case, it just adds additional flash usage for no reason |
@nordicjm I think there is another dimension to that. While two slots are needed to ensure reliable fw updates practically mandatory for any loader app (or device may get bricked), one slot takes just half of the flash space that two slots do and sometimes it matters a lot. |
There already is a loader mode where the slot sizes can differ, you have a loader application (which can be immutable or can be updated if you use MCUboot serial recovery), if the loader conditions are met then MCUboot will boot the loader application, if not it will boot to the normal application Example that uses it: https:/thedjnK/net_loader a slim loader application runs which allows for loading images to the device over the network (UDP), once the device reboots it runs that image, upon an additional reboot it reverts back to the loader application |
My loader has to use USB stick so it is not a trivial y-modem recovery app, likely will need updates and enhancements, hence it needs to be easily updatable. Essentially, it needs to be able to update itself the same way the main app is updated. |
Then that's not going to work with mcuboot, either you have 1 single slot or 1 single slot with a loader, or you have 2 double slots, one image pair for the loader and one image pair for the application. |
@nordicjm Unfortunately, that is what I thought but thank you for the confirmation. I think currently the only way it could be done without too much code changes is by using two separate sets of configs which will allow MCUboot to believe that my Secure Loader app using two slots is the only image to be loaded while Secure Loader itself would be configured with |
Alas, many designers do not include a button on their products! If I am early in a project then I will always advocate for a button (or an exposed GPIO pad that can get shorted) as an "escape hatch" to get to the bootloader. Even then, it doesn't get included because we are talking about tiny wearables that need IP66 etc. And to be clear, these sorts of products don't even have a reliable (hardware) means of power cycling or resetting the MCU.
This also does not work because "valid" simply means signed. Pleasantly this solves the problem of an interrupted upgrade. But, a "valid" FW can brick the device if it encounters an error that prevents user interaction. A resilient bootloader and DFU system should not assume that all software is free from bugs.
On the contrary, it fulfills the critical need of preventing a device from being bricked by a bad FW. |
@nordicjm Just a thought: can MCUboot External Loader (MCUBOOT_EXT_LOADER) image be signed and initially encrypted? |
You're going to be in the exact same situation if the firmware confirms itself then crashes. If you don't have a dedicated means of entering the bootloader without the main application doing something then there is a chance the device bricks itself and no amount of tinkering is going to prevent that. |
I don't know what you mean by |
@nordicjm That is right. I analyzed the source code, in particular |
That is right, but just like pretty much anything else in life and in the universe I think this can just be seen in terms of probability. |
@JPHutchins I realized that probably I do not fully understand what |
It means you only have a single slot for the application instead of 2, it means the application cannot update itself, the only way to update the application is by using the bootloader through serial recovery (serial/USB CDC only, no other transports like bluetooth etc.). You can uploade an encrypted image through MCUboot's serial recovery to the slot and it will be decrypted yes |
@JPHutchins Thank you, so I can use this approach in my scenario. Do you happen to know how to correctly prepare single-app image with imagetool? I think there is no dedicated options. Are those the correct options to be used? |
You just generate it normally, |
@JPHutchins Thank you. The only remaining dilemma I have to solve is whether it is more practical to modify MCUboot so that it can install images both by swapping (moving) slots as well as a performing in-place decryption, or implement the latter functionality in my 'secure loader' leaving MCUboot intact. |
Not sure what you mean, if you have a single slot then the image is transferred entirely and them MCUboot will decrypt it. If you have 2 slots then the secondary slot will hold an encrypted image, if the images are swapped then the secondary image will be decrypted and place into the primary slot and the primary slot image will be encrypted and placed into the secondary slot image |
@JPHutchins The problem is that my solution needs to use both strategies (single and double slot) simultaneously. |
It can, you just need to build MCUboot twice which means you will need overlays for each build. First mcuboot build will have slot0 and slot1 for your loader application (which I assume is a modified mcuboot?) then for your second mcuboot you would enable serial recovery mode and have a single slot, slot0 (which is NOT the same slot from the first stage mcuboot) |
Exactly, so practically two MCUboot apps are needed, the second one (secure loader) modified the way so it could load images from USB stick exFAT partition, rather than via serial y-modem, and install them using in-place decryption. |
You need to be aware that there's a reason secure bootloaders are incredibly simple and don't include things like file systems. File systems are complex and it makes it very easy to have bugs in them, bugs which could compromise the whole security of the device. |
USB MSC class complexity hence potential bugs and required fixes/improvements are the very reasons why my 'secure loader' needs two slots and ability to rollback. It cannot, or at least should not be implemented just like an enhanced external serial recovery loader. |
For the Zephyr implementation, there is a separate file single_loader.c. I suppose my first question is why the single application slot configuration is treated separately from the multi-slot configuration at all?
As it stands, it is possible to brick a board using MCUBoot by loading a bad application to the application slot. This is because the single_loader.c implementation does not utilize the test (Swap Info) and confirm (Image OK) flags provided by the Image Trailer spec:
Specifically, when MCUBoot has completed a single slot application upgrade via SMP, USB DFU, or other, it should conform to the same "test" and "confirm" routine as a multi-slot configuration:
The routine described above will prevent an unrecoverable bootloop so long as the user confirms the test image responsibly from within the application.
The text was updated successfully, but these errors were encountered: