ARMv8-M: memory protection implementation

[ioannisg]

ARM MPU for ARMv8-M

1. There are architectural changes in ARMv8-M.

   • Now, the size of a region can be fully flexible, i.e. does not need to be a power of 2.
   • A region can start from any address (32-byte aligned) and end at any address.
   • As a result, the regions are, now, not allowed to overlap

2. There are register API changes

   • Some registers are the same
     i. TYPE
     ii. CTRL
     iii. RNR
   • Some registers are different
     i. RBAR: Contains the Base Address (present in ARMv7), does not contain REGION and VALID (present in ARMv7), and contains attributes (not present in ARMv7)
   • Some registers are new
     i. RLAR
   • Some register do not exist
     i. RASR

3. The possible permission-configuration options are limited in ARMv8
   a. the Privileged-RW/Unprivileged-RO does not exist
   b. the No-Access does not exist

---

• Ensure that the ARM_MPU driver uses CMSIS directly, instead of defining own macros and HAL register APIs.

• Adapt the ARM_MPU driver (HAL access), so it works both for ARMv7-M and ARMv8-M architectures. Ideally, we need to have 2ARM MPU drivers, with common (internal) APIs.

• Ensure that only one of the source files is used in the build, depending on the supported MPU variant.

• Refactor the ARM MPU internal API (e.g. macros for region/attribute definitions), so it can work with both architectures.

• MPU configuration for memory caching for ARMv8-M

• Ensure that the architectural differences of the 2 different MPU versions are taken into consideration when performing runtime MPU configurations in Zephyr

• Ensure that active MPU regions never overlap with each other

• Migrate the MPU driver to the new logging system

• Update samples and tests in the tree to be able to run for ARMv8-M (e.g. available access permissions configuration)

[ioannisg]

@carlescufi @agross-linaro

[ioannisg]

Some more detailed comments regarding the architectural changes we need:

• In ARMv8-M, MPU regions cannot overlap. This means that we cannot define, configure, and enable the background regions (e.g SRAM0, SRAM1, ...) upon MPU initialization during system boot, and then enable other regions (e.g. STACK_GUARDS) on top of them.

  • We can still define partition regions during system boot, provided that the regions will not overlap with other MPU regions that may be configured & enabled at a later point.
  • The above could be the case for the region definition for the Flash partition; the flash region access rights are "immutable" during device lifetime, so we do not expect to have additional region definitions within Flash area. (Is this correct, @andrewboie @agross-linaro ?)
    • So, the requirement, here (for things to work), is never to add additional Flash regions. Can we live with that?
  • However, the above case cannot work for SRAM, though, because, in general, we do define additional MPU partitions for User-space and Stack-guarding.

• However: for SRAM, we do not seem to need the background partition ("SRAMx" regions), since the related permissions allow for privileged R/W - unprivileged NA, which is exactly what the default map gives when setting the PRIVDEFENA bit. So, I wonder @andrewboie , @agross-linaro : could we just get rid of these?

• On the other hand, we do need to ensure that all later-defined RAM MPU regions (APP REGION, STACK GUARD REGION and THREAD_USER_REGION) do not with regions other than the background one ("SRAMx"), which I hope we can remove?

• Privileged R/W, Unprivileged R/O is not a permitted configuration in ARMv8-m. This configuration is, now, used for the background flash partition when MPU allows flash writes. The options are:

  • either change the current configuration to Privileged/Unprivileged R/W, or
  • have different configurations (for MPU allow flash writes) for ARMv6/7 and ARMv8 MCUs

[andrewboie]

We need to consider the execute bit as well. Current policy has XIP systems in mind.

Currently, at least with the arm_mpu, the "background" map is RWX for supervisor and no access to user.
We configure SRAM_* to be RW for supervisor and no access for user, execute bit disabled.
We configure FLASH_* to be RX for both supervisor and user, except if the config flash write thing is turned on in which case supervisor get RWX to flash.

Since we can't have overlapping regions in SRAM, is there a way to disable execution in the background map for ARMv8? And then just enable execution for the flash region?

Also keep in mind that the MPU is also used to set cacheablility settings for at least arm_mpu, but armv8 may be different.

[ioannisg]

@andrewboie, thanks for your feedback

Since we can't have overlapping regions in SRAM, is there a way to disable execution in the background map for ARMv8? And then just enable execution for the flash region?

As far as I know the only way to do these, is to define explicit MPU regions. But then, for SRAM this region would overlap with dynamically configured regions, e.g. for User-space, Stack-Guards etc.

For Flash, we can define RX for both user and supervisor, I believe, since we do not expect to dynamically configure any regions.

[ioannisg]

Pull-request for the driver implementation: #8785.

[ioannisg]

Pull-request for migration into the new logging system: #9361

[ioannisg]

The non-overlapping MPU regions' issue is handler in #8907

[ioannisg]

Pull-request for non-overlapping MPU regions: #11346