Improved MPU usage in PROTECTED mode

[patacongo]

In PROTECTED mode, the MPU is used to map regions of memory to supervisor- and/or user-accessible memory. Currently, that algorithm is very simple: The entire address range is made accessible in supervisor mode; a single MPU region is used to enable user-mode access in each user memory region.

Each MPU region must bit both of a power-of-two size and with an alignment in memory equal to the size. That is, a 16Kb mapped region must be aligned to a 16Kb address. This simple region mapping causes some serious memory alignment problems. For example, suppose there is 64Kb of memory (say RAM) and we need at least 1Kb for supervisor memory. At best, after the 1Kb memory is set aside for supervisor access, the remaining 63Kb can support a maximum of a 32Kb region, aligned either at the beginning of the 64Kb region or at an offset of 32Kb into the 64Kb region. The remaining 31Kb is lost.

This could be solved by either:

1. Use multiple regions to map the memory. In the above example, we could map 48Kb with two regions (still losing 13Kb) or 56Kb with three regions (still losing 5Kb). Or, better,
2. Use the ARMv7-M sub-regions. For example, map the entire 64Kb, but unmap the single 1Kb sub-region reserved for supervisor mode access (no memory loss).

[TaiJuWu]

MPU setting depends on hardware.
You didn't specific what arch is needed to improve.
Is it only for ARMv7-M or there is another arch need to be improved?

[patacongo]

You didn't specific what arch is needed to improve.

The Issue is older and was based on the ARM implementations at the time. I suspect that most of the MPU implementations derive from the same source and work the same: armv7-m, armv8-m, armv7-r, arm64, ceva, and xtensa. But I would have to look at each.

RISC-V supports a PMP instead of an MPU.

The x86_64 claims to support an MPU in its Kconfig files, i.e. it selects ARCH_HAVE_MPU and/or ARCH_USE_MPU but it doesn't in fact have any MPU support: That is probably a cloning error.

I would think that a proper solution for spanning a memory region with power-of-2 size and aligned pages might be share-able, common logic. Particular solutions like ARM sub-regions might not be so share-able.

[priyanshscpp]

Using ARMv7-M sub-regions seems like an elegant solution to minimize memory loss. Are there any known challenges or trade-offs with this approach, such as increased complexity in configuration or runtime performance impacts?

[gregory-nutt]

Are there any known challenges or trade-offs with this approach, such as increased complexity in configuration or runtime performance impacts?

There would be some effort required to develop the algorithm and apply the sub-region settings, but not insurmountable.

I would not expect any performance issues.

[xiaoxiang781216]

Using ARMv7-M sub-regions seems like an elegant solution to minimize memory loss. Are there any known challenges or trade-offs with this approach, such as increased complexity in configuration or runtime performance impacts?

we already support sub region in local branch, @crafcat7 could upstream the patch for reference.

[crafcat7]

we already support sub region in local branch, @crafcat7 could upstream the patch for reference.

We have merged the changes of MPU in #12968.
In this change, we added several new mpu APIs, such as:

1. mpu_initialize
2. mpu_dump_region
3. mpu_configure_region
4. mpu_freeregion
   Through the new APIs, we can achieve more requirements

Using ARMv7-M sub-regions seems like an elegant solution to minimize memory loss. Are there any known challenges or trade-offs with this approach, such as increased complexity in configuration or runtime performance impacts?

We can try to use the newly introduced interface, which should be a simpler way to handle sub-regions.

1. First, map the entire region to protect it
2. And then use the returned region number to adjust the region attribute.