-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
mgmt: mcumgr: grp: img_mgmt: Add optional max image size reduction #66615
Changes from all commits
90bdba4
abfc9a8
d997f53
28af6eb
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -153,6 +153,38 @@ config MCUMGR_GRP_IMG_MUTEX | |
can be used by applications to reset the image management state (useful if there are | ||
multiple ways that firmware updates can be loaded). | ||
|
||
choice MCUMGR_GRP_IMG_TOO_LARGE_CHECK | ||
prompt "Image size check overhead" | ||
default MCUMGR_GRP_IMG_TOO_LARGE_DISABLED | ||
help | ||
MCUboot images should be limited to the maximum size that the bootloader can swap, in | ||
order to know this size, additional information is needed from the MCUboot | ||
configuration, otherwise an image can be uploaded that is too large for the bootloader | ||
to swap, this selects which method to use. | ||
|
||
Note: setting this to a non-disabled option will prevent uploading of padded and | ||
confirmed images, if support for that is required then this feature should be left as | ||
disabled. | ||
|
||
config MCUMGR_GRP_IMG_TOO_LARGE_DISABLED | ||
bool "Disabled" | ||
help | ||
Will not take MCUboot configuration into account when checking for maximum file size. | ||
|
||
config MCUMGR_GRP_IMG_TOO_LARGE_SYSBUILD | ||
bool "Via Sysbuild from MCUboot configuration" | ||
depends on ROM_END_OFFSET > 0 || MCUBOOT_UPDATE_FOOTER_SIZE > 0 | ||
help | ||
Will use the image overhead size calculated during Sysbuild image configuration. | ||
|
||
config MCUMGR_GRP_IMG_TOO_LARGE_BOOTLOADER_INFO | ||
bool "Via retention bootloader info" | ||
depends on RETENTION_BOOTLOADER_INFO_OUTPUT_FUNCTION | ||
help | ||
Will fetch the maximum image size from the bootloader info retention subsystem module. | ||
Comment on lines
+180
to
+184
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should be able to, also, provide this info at compile time. At all we are able to calculate space needed for footer in MCUboot, when we know size of slot and write block size. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is provided at compile time when using the sysbuild option. If not using sysbuild then you cannot get that information |
||
|
||
endchoice | ||
|
||
module = MCUMGR_GRP_IMG | ||
module-str = mcumgr_grp_img | ||
source "subsys/logging/Kconfig.template.log_config" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible for us to develop MCUboot/bootutil function that would check the image for valid footer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not possible, well, depending on what you mean by valid footer. Only MCUboot can confirm the image properly due to possibly being encrypted, an application could do some minor validation but nothing more than that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually you can use imgtool to pad, confirm and encrypt image.
But yes, I guess you can not check the footer if the MCUboot only knows the key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also can't check that here because to check that you need to receive the whole image
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The image slot trailer, the one that stores swap bits, etc, is not encrypted. actually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not encrypted no but only mcuboot can verify that it is a valid image or supported on that device, the application can't know anything more than the basic validity of parts of the image