You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I posted the message below, Friday 12th on the mailing list https://groups.io/g/mcuboot/message/86
Maybe maintainers would prefer to answer here or to go to "github discussion". Let's see.
##############################
Dear all,
I am currently experimenting with authentication algorithms in MCUBoot and could use a bit of help understanding these build options :
MCUBOOT_BOOTSTRAP
MCUBOOT_VALIDATE_PRIMARY_SLOT
and the implications for how often one validates a slot (boot_validate_slot()) and which one(s) ?
Would really appreciate your insights on this :) !
docs/design.md says this about MCUBOOT_VALIDATE_PRIMARY_SLOT "An image is checked for integrity immediately before it gets copied into the
primary slot. If the bootloader doesn't perform an image swap, then it can
perform an optional integrity check of the image in the primary slot if MCUBOOT_VALIDATE_PRIMARY_SLOT is set, otherwise it doesn't perform an
integrity check."
docs/design.md doesn't say anything about MCUBOOT_BOOTSTRAP
One can read this in boot/nuttx/include/mcuboot_config/mcuboot_config.h : "Enable bootstrapping the erased primary slot from the secondary slot"
but I don't understand this last sentence (and specifically what is the meaning of "bootstrap" here)
docs/design.md gives some explanation on the four iterations over all the images in boot/bootutil/src/loader.c:context_boot_go()
and particularly where are the two eventual "integrity and security check" (I will call them from now on "loop1" and "loop4")
Let's suppose I have this :
MCUBOOT_IMAGE_NUMBER = 1 (so no dependency between images)
MCUBOOT_ENC_IMAGE = Off
MCUBOOT_OVERWRITE_ONLY upgrade strategy
After erasing the flash memory entirely, I flash a signed firmware in the slot 2.
What I see currently is this behavior :
Can you reproduce this and is this the intended behavior ?
Case 2 seems to be exactly what I'm looking for, but I want to ensure that setting MCUBOOT_BOOTSTRAP = Off is indeed the correct approach.
Thanks a lot for your help.
Best regards,
Rehan MALAK
The text was updated successfully, but these errors were encountered:
I posted the message below, Friday 12th on the mailing list
https://groups.io/g/mcuboot/message/86
Maybe maintainers would prefer to answer here or to go to "github discussion". Let's see.
##############################
Dear all,
I am currently experimenting with authentication algorithms in MCUBoot and could use a bit of help understanding these build options :
MCUBOOT_BOOTSTRAP
MCUBOOT_VALIDATE_PRIMARY_SLOT
and the implications for how often one validates a slot (boot_validate_slot()) and which one(s) ?
Would really appreciate your insights on this :) !
docs/design.md says this about
MCUBOOT_VALIDATE_PRIMARY_SLOT
"An image is checked for integrity immediately before it gets copied into the
primary slot. If the bootloader doesn't perform an image swap, then it can
perform an optional integrity check of the image in the primary slot if
MCUBOOT_VALIDATE_PRIMARY_SLOT
is set, otherwise it doesn't perform anintegrity check."
docs/design.md doesn't say anything about
MCUBOOT_BOOTSTRAP
One can read this in boot/nuttx/include/mcuboot_config/mcuboot_config.h :
"Enable bootstrapping the erased primary slot from the secondary slot"
but I don't understand this last sentence (and specifically what is the meaning of "bootstrap" here)
docs/design.md gives some explanation on the four iterations over all the images in boot/bootutil/src/loader.c:context_boot_go()
and particularly where are the two eventual "integrity and security check" (I will call them from now on "loop1" and "loop4")
Let's suppose I have this :
MCUBOOT_IMAGE_NUMBER
= 1 (so no dependency between images)MCUBOOT_ENC_IMAGE
= OffMCUBOOT_OVERWRITE_ONLY
upgrade strategyAfter erasing the flash memory entirely, I flash a signed firmware in the slot 2.
What I see currently is this behavior :
Can you reproduce this and is this the intended behavior ?
Case 2 seems to be exactly what I'm looking for, but I want to ensure that setting MCUBOOT_BOOTSTRAP = Off is indeed the correct approach.
Thanks a lot for your help.
Best regards,
Rehan MALAK
The text was updated successfully, but these errors were encountered: