Run time MPU configuration

[kumarnac]

The arm_mpu_config structure is currently set as a compile time configuration.
We are faced with a requirement of setting the mpu configuration at runtime.
extern const struct arm_mpu_config mpu_config;
Looking for inputs from the community if this can be made a runtime configuration.
Thanks,
Nachiketa

[henrikbrixandersen]

Have you looked into the memory protection design principles of Zephyr? https://docs.zephyrproject.org/latest/reference/usermode/memory_domain.html Depending on your needs, you may be able use memory domains/partitions.

[kumarnac]

Thanks Henrik , we have used memory partitions and domains in our programing . However, for the mpu initialization , we have some constants derived during runtime and are set during the mpu_init (architecture specific ). This requires the extern const struct arm_mpu_config mpu_config; to be extern struct arm_mpu_config mpu_config;

[henrikbrixandersen]

Ah, now I understand your use-case better.

I suggest you raise an issue describing your use-case on GitHub (or submit a pull request, but I am not sure if making that struct non-const is the preferred solution). It's likely too late to get this supported by Zephyr v2.6.0, since the first release candidate has already been cut, but it's good to get broader attention to such special cases going forward.

[povergoing]

Just out of curiosity, why you need to change the mpu_config dynamically. As far as I know, mpu_config is just an init config and won't be used after the system booted, and the rest of the 'dynamic' work done by arch/arm/core/aarch32/mpu/arm_core_mpu.c. Are you going to use your customized mpu regions on your own SOC, like what CONFIG_CPU_HAS_CUSTOM_FIXED_SOC_MPU_REGIONS does? I may be wrong, so I agree with henrikbrixandersen that it would be much better to give more details about your use-case.

[kumarnac]

Hi

Ah, now I understand your use-case better.

I suggest you raise an issue describing your use-case on GitHub (or submit a pull request, but I am not sure if making that struct non-const is the preferred solution). It's likely too late to get this supported by Zephyr v2.6.0, since the first release candidate has already been cut, but it's good to get broader attention to such special cases going forward.

Sure Henrik , I have created a PR #35435 for a broader review and comments.

[najumon1980]

hi All,
the use case related with flexible code relocation feature of Zephyr on different memory location. The application code which need to relocate should be update with corresponding MPU attribute once relocated. So during pre-kernel initialization (soc_init), dynamically update arm_mpu_config based on relocation information

Following are few justification for this:
a) In our controller, there is no flash memory and both code/data are reside in SRAM
b) The Kernel startup code will update the SRAM region to read only, execute only, read-write etc. based on the arm_mpu_config by programming MPU
c) the arm_mpu_config is only can be access from Kernel/supervisory mode
d) Also any kernel mode program can update the MPU to change a read only region(eg: arm_mpu_config) to any other memory attribute. That mean if a kernel mode code compromised then there is no protection to system resources.

Suggestion:
use KConfig which will declared arm_mpu_config as const or not. Default it will be declared as const which serve MCU which use Flash memory. For MCU which use SRAM only can define KConfig accordingly if required to make the arm_mpu_config modifiable from kernel mode code such soc_init.