nRF9160 Questions related to Immutable, MCUBoot & application

[kk2mkk]

Hi Lorenzo,

I have gone through most of the documentation related to Immutable (SB or b0), McuBoot and application and i have the following queries:

1. which one should i choose while building my application b0+MCUBoot+app or b0+app or MCUBoot+app?(to avoid confusion i am treating SPM and app together)
2. when i build my application with b0+MCUBoot+app, what is the procedure to serial upgrade MCUboot image? please point me to an example?
3. I find some threads on serial application DFU but it needs the device to be pushed into recovery mode, cant it be done when the application is running?(consider a use case where my metering application is running from one slot, then a new image is ungraded to the second slot, once the upgrade completes successfully pass the controller to the bootloader to flash & activate the image)

regards

kk

[shibshab]

1.
- If you want an upgradeable bootloader you need b0 and MCUBoot (update the thing that updates the app)
- else if you have an application which consists of SPM and app you cannot use b0 - app
- else if you have an app which does not contain SPM you are free to choose between b0 - app and mcuboot - app

2.
- This would be done using smp over UART. Transfer the signed mcuboot image over serial to the secondary slot, and then on the next reboot MCUBoot perform the swap to the alternate b1 slot (s0 or s1).
- See this page for more information on the sample: docs.zephyrproject.org/.../README.html
- Some modifications would be needed for this to be capable of updating MCUBoot in addition to the application.
  Specifically, you would need some way of communicating whether you want the MCUBoot candidate linked against slot S0 or S1.
  Inspiration for how this is handled elsewhere can be seen here: github.com/.../fota_download.c

3.
- This is the "serial recovery" feature, it can not be done while the application is running. Instead (as you say) it requires some manual action during boot-up so that MCUBoot will start in a special mode.

For your use case, if the image is to be transferred over serial, you would need the feature discussed in question 2.

[kk2mkk]

1.

I have a requirement to have secure boot, so is it possible without having b0 just with mcuboot+app?

At present we are using SLM application since it needs to be build on non secure mode, i need SPM as well along with my application.

As i also need my application upgrade support i need to have MCUBoot to do that as well, so the bottom line is i should have b0+mcuboot+(smp+app).

2.

Let me go through and try it

3.

shibshab said:

For your use case, if the image is to be transferred over serial, you would need the feature discussed in question 2.

I think in question 2 we are discussing about the mucboot upgrade does the same applicable for application upgrade as well? it will great you you could point to some example.

regards

KK

[shibshab]

You can achieve secure boot without b0, in the NCS fork of mcuboot it will lock its own flash area, making it an "immutable bootloader" - which satisfies the secure boot requirement.

You only need B0 and mcuboot if you have a requirement that the bootloader should be upgradeable (protect against future crypto attacks etc)

kk2mkk said:

I think in question 2 we are discussing about the mucboot upgrade does the same applicable for application upgrade as well? it will great you you could point to some example.

I don't follow you, could you explain exactly what you want an example of?

[kk2mkk]

shibshab said:

You only need B0 and mcuboot if you have a requirement that the bootloader should be upgradeable (protect against future crypto attacks etc)

I was wondering since secure boot and app upgrade  features are provided by MCUBoot, do i still need to have an option for MCUBoot upgrade? do you foresee any hard requirement to have mcuboot upgrade...your experience can help me to make a better decision

shibshab said:

I don't follow you, could you explain exactly what you want an example of?

Does DFU of the mcuboot and application both can be done using SMP Server approach?

I have issues in building the SMP server sample, better i will take in to different thread.

regards

KK 

[kk2mkk]

shibshab said:

You only need B0 and mcuboot if you have a requirement that the bootloader should be upgradeable (protect against future crypto attacks etc)

Are you sure that MCUBoot locks the flash? i dont think so, the reason is when we have B0 in place and when we try to flash new image we need to erase the entire chip to ensure the UICR OTP area is been erased for any flash security, but when we have the MCUBoot as a only bootloader and the we try to flash new image it never ask for full chip erase, is my understanding correct?

regards

kk

[shibshab]

You are correct that B0 makes us of the OTP area in the UICR, which require a special argument for the programmer to delete it. This, however, only makes it more difficult for an attacker to tamper with the metadata used by B0, compared to the MCUBoot where the metadata is stored in regular flash alongside the image.

In the NCS fork of MCUBoot there is flash protection in place 
https://github.com/nrfconnect/sdk-mcuboot/blob/master/boot/zephyr/main.c#L434

Here MCUBoot use the same library (fprotect) as B0, and hence the flash locking itself should be considered equally safe.