Skip to content
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

MCUBOOT_BOOTSTRAP meaning with/without MCUBOOT_VALIDATE_PRIMARY_SLOT #1887

Open
Rehan-MALAK opened this issue Jan 16, 2024 · 0 comments
Open

Comments

@Rehan-MALAK
Copy link

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 :

table

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant