Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

llly — Wed, 10 Jul 2024 01:34:06 GMT

Hi Hieu

Thank you for your answers and suggestions. I will carefully discuss the security risks of using LFS in mcuboot with my colleagues.

This ticket should be able to be closed now.

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

Hieu — Tue, 09 Jul 2024 18:14:36 GMT

Yes, SPU is System Protection Unit. It works in chunks of the configured size, so partitions on flash memory have to be aligned with the SPU Region Size. For example, the default SPU Region Size is 0x8000. Having the littlefs_storage partition aligned means having it start at 0x00000000, 0x00008000, 0x00800000, 0x00808000

And littlefs_storage is aligned with the SPU region size to protect it from unauthorized write operations, yes.

I confirmed the workaround with a few colleagues. As you are already using TF-M, and littlefs_storage has to be aligned anyway, so making the change doesn't affect your project at all.

However, it is a change in the SDK and outside of your project, so you need to keep this in mind when collaborating on the project or starting a new project with the same SDK.
For this scenario, it's recommended to use a workspace project. This is explained here: Workflow 4: Workspace application repository (recommended).

Finally, my colleagues also raise concerns about both the bootloader and the application having access to the same LittleFS partition.

Bootloaders are immutable for the lifetime of a product and it's imperative that they do not have security vulnerabilities or a large attack surface because if you compromise a bootloader, you compromise. Adding LittleFS read/write both adds a vulnerability and increases the attack surface.

We highly recommend that the bootloader stay minimally simple. Giving both the application and the bootloader access to the same file system is especially recommended against.

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

llly — Tue, 09 Jul 2024 01:55:58 GMT

I saw the spu in the device tree, referring to the system protection unit, right?

Is aligning littlefs_storage with the SPU area to protect the lfs partition?

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

llly — Tue, 09 Jul 2024 01:35:49 GMT

Hi Hieu

Thank you for your research,this is indeed useful and looks better than commenting out the check code in partition_manager.py.

But what does this spu mean? The current practice is due to the lack of reserved partitions for tfm in mcuboot, resulting in partition mismatch. Therefore, the check on CONFIG-BUILD-With-TFM was commented out, so that it always reserved partitions for tfm and passed the partition check in mcuboot, right?

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

Hieu — Mon, 08 Jul 2024 19:33:11 GMT

Hi llly,

I have some good news. I was able to pinpoint what the problem is and can think of a workaround. The bad news is that I am only ~85% sure that my workaround is safe.

The issue is in this section: https://github.com/nrfconnect/sdk-nrf/blob/v2.6.1/subsys/partition_manager/pm.yml.file_system#L9-L11

#include <autoconf.h>

littlefs_storage:
  placement:
    before: [tfm_storage, end]
#ifdef CONFIG_PM_PARTITION_REGION_LITTLEFS_EXTERNAL
  region: external_flash
#else

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
#ifdef CONFIG_BUILD_WITH_TFM
    align: {start: CONFIG_NRF_SPU_FLASH_REGION_SIZE}
#endif
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  inside: [nonsecure_storage]
#endif
  size: CONFIG_PM_PARTITION_SIZE_LITTLEFS

CONFIG_BUILD_WITH_TFM is only set for the application, not MCUboot. As you have LittleFS on both, this file is run twice, but with two different requirements for the littlefs_storage partition.

My proposed workaround is to remove the #ifdef and #endif condition and make the littlefs_storage always align with SPU region size.

As mentioned, I am fairly sure there is no issue with this, but I prefer to run this through someone who has a better overview of the partitioning.

I will keep you updated.

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

llly — Tue, 02 Jul 2024 01:05:48 GMT

It's okay. Thank you for your help

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

Hieu — Mon, 01 Jul 2024 18:53:34 GMT

Sorry I wasn't able to figure this out last week. I will continue this week and keep you updated.

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

llly — Mon, 24 Jun 2024 01:16:49 GMT

Look forward to your reply

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

Hieu — Fri, 21 Jun 2024 11:52:37 GMT

There should be better solutions than commenting out a check. I will investigate this and come back to you next week.

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

llly — Fri, 21 Jun 2024 01:19:14 GMT

Hi Hieu

This is where I made the changes in partition_manager.py.

I simply commented out the code that prompted the error message, and then it can be built normally. Currently, there seems to be no problem, but I think there will be a better solution?

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

Hieu — Thu, 20 Jun 2024 20:29:55 GMT

Hi llly,

Nothing stands out to me from the YAML file.

Could you please share the spot in partition_manager.py where the issue happened?

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

llly — Thu, 20 Jun 2024 01:34:10 GMT

Hi Hieu
This is a dynamic partition table that I built when only enabling LFS in mcuboot or app (my project requires a single slot, so there is no mcuboot secondary partition, and I initially thought that the insufficient size of the mcuboot partition affected the activation of LFS, so I set it to 100k)

EMPTY_0:
  address: 0x19000
  end_address: 0x20000
  placement:
    before:
    - mcuboot_pad
  region: flash_primary
  size: 0x7000
app:
  address: 0x28000
  end_address: 0x80000
  region: flash_primary
  size: 0x58000
littlefs_storage:
  address: 0x80000
  end_address: 0x100000
  inside:
  - nonsecure_storage
  placement:
    align:
      start: 0x8000
    before:
    - end
  region: flash_primary
  size: 0x80000
mcuboot:
  address: 0x0
  end_address: 0x19000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x19000
mcuboot_pad:
  address: 0x20000
  end_address: 0x20200
  placement:
    align:
      start: 0x8000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x20000
  end_address: 0x80000
  orig_span: &id001
  - tfm
  - app
  - mcuboot_pad
  region: flash_primary
  size: 0x60000
  span: *id001
mcuboot_primary_app:
  address: 0x20200
  end_address: 0x80000
  orig_span: &id002
  - app
  - tfm
  region: flash_primary
  size: 0x5fe00
  span: *id002
mcuboot_sram:
  address: 0x20000000
  end_address: 0x20008000
  orig_span: &id003
  - tfm_sram
  region: sram_primary
  size: 0x8000
  span: *id003
nonsecure_storage:
  address: 0x80000
  end_address: 0x100000
  orig_span: &id004
  - littlefs_storage
  region: flash_primary
  size: 0x80000
  span: *id004
nrf_modem_lib_ctrl:
  address: 0x20008000
  end_address: 0x200084e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - tfm_sram
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x2000a568
  end_address: 0x2000c568
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20008000
  end_address: 0x2000c568
  orig_span: &id005
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x4568
  span: *id005
nrf_modem_lib_tx:
  address: 0x200084e8
  end_address: 0x2000a568
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2080
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
sram_nonsecure:
  address: 0x20008000
  end_address: 0x20040000
  orig_span: &id006
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x38000
  span: *id006
sram_primary:
  address: 0x2000c568
  end_address: 0x20040000
  region: sram_primary
  size: 0x33a98
sram_secure:
  address: 0x20000000
  end_address: 0x20008000
  orig_span: &id007
  - tfm_sram
  region: sram_primary
  size: 0x8000
  span: *id007
tfm:
  address: 0x20200
  end_address: 0x28000
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x7e00
tfm_nonsecure:
  address: 0x28000
  end_address: 0x80000
  orig_span: &id008
  - app
  region: flash_primary
  size: 0x58000
  span: *id008
tfm_secure:
  address: 0x20000
  end_address: 0x28000
  orig_span: &id009
  - mcuboot_pad
  - tfm
  region: flash_primary
  size: 0x8000
  span: *id009
tfm_sram:
  address: 0x20000000
  end_address: 0x20008000
  inside:
  - sram_secure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x8000

Then I copied this dynamic partition table into a static partition table and enabled LFS in both mcuboot and app, and the above error occurred.

I have temporarily solved this problem, but I don't think it's the right way.

I opened the file ncs\v2.6.1\nrf\scripts\partition_manager.py, found the error line, and commented out this part of the code. The build can be completed, and the code is currently running normally. But I don't know if there's any hidden danger in this.

If you need any other detailed information, please let me know. I am not sure what can help you analyze this issue

RE: Partition conflict when enabling littlefs in both mcuboot and app simultaneously?

Hieu — Wed, 19 Jun 2024 11:14:23 GMT

Hi llly,

Could you please share more details about your setup, and also the static configuration attempt?

Hieu

Update**: There is an important warning I would like to add to this first reply:

[quote user="vthieu"]

We highly recommend that the bootloader stay minimally simple. Giving both the application and the bootloader access to the same file system is especially recommended against.

[/quote]