• State Verified Answer
  • Replies 13 replies
  • Subscribers 65 subscribers
  • Views 864 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 328734
Options

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

llly

I successfully enabled littlefs in mcuboot and read/write it successfully (due to project requirements), and then tried to enable littlefs in both mcuboot and app, operating on the same lfs partition. However, I received an error message during the build process, indicating that the partition does not meet the requirements? Or something else. I have tried to make a static partition table with LFS enabled separately in mcuboot or in the app, but there has been no improvement. How can I solve the problem of this partition not meeting the requirements?

In addition, I have made many different attempts based on the error content, and personally think it may be related to TFM? Could it be because mcuboot and the app run in different trust zones that their littlefs zones conflict?

  • 0 in reply to Hieu

    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?

  • 0 in reply to llly

    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.

  • 0 in reply to Hieu

    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.

Related