ARM Memory Protection functions not invoked in SWAP for ARMv6/ARMv8-M Baseline

[ioannisg]

Describe the bug
It has, unfortunately, been the case since the very beginning, for example:

• (86aff09) when integrating stack guard, or
• (1c047c9) when integrating user space support, that
  ARM swap (__pend_SV)) function does not invoke the memory protection functions for the ARMv6-M (and for the latter-added ARMv8-M Baseline) architecture.

Since then, all patches have been ignoring this misbehavior.

This is a bug, IMHO, because:

1. the ARM MPU may exist on Cortex-M0+ and Cortex-M23
2. Kconfig options for STACK Guards, Userspace depend on ARM MPU, so they can be switch-on for those processors,
3. In other places in Core ARM code, for example, in _userspace_enter() or _switch_to_main_thread(), the memory protection functions are invoked, for all architectures.

To Reproduce
Just browse the swap __pend_SV code and see that context-switch for ARMv6 does not call MPU re-programming functions.

Expected behavior
This behavior needs to be fixed; we need to make swap call mpu functions for ARMv6.

Impact
This is a critical bug, breaking User Mode for ARMv6-M and Stack Overflow Protection. I do not, know, however, if this affect any SOCs in the tree (need to be Cortex-M0+ with ARM MPU support, and I do not think that there is one). Therefore, I am adding Medium priority on this.

Additional context
Either we fix this as proposed, or not allow Memory Protection features on ARMv6-M at all.

[ioannisg]

Reducing impact to Low, since no issues were reported by the community, and we still do not have Baseline Cortex-M SOCs with MPU in the tree.

[andrewboie]

We have tests which are supposed to verify access to memory ... are the tests inadequate to catch this, or were they never run on these platforms?

[ioannisg]

@andrewboie there are no Cortex-M Baseline boards/SOCs in the tree with MPU support.

[jjmilburn]

The Nucleo G071RB from the "Supported Boards" list uses the STM32G071RB, which does have an MPU.

This MCU is Cortex M0+ based.

From the datasheet:

"The memory protection unit (MPU) is used to manage the CPU accesses to memory to
prevent one task to accidentally corrupt the memory or resources used by any other active
task.
The MPU is especially helpful for applications where some critical or certified code has to be
protected against the misbehavior of other tasks. It is usually managed by an RTOS (realtime operating system). If a program accesses a memory location that is prohibited by the
MPU, the RTOS can detect it and take action. In an RTOS environment, the kernel can
dynamically update the MPU area setting, based on the process to be executed.
The MPU is optional and can be bypassed for applications that do not need it."

I do not know if the "Supported Boards" list is included in the tree referenced here.

[andrewboie]

@andrewboie there are no Cortex-M Baseline boards/SOCs in the tree with MPU support.

@ioannisg we really need to fix that, what board have you been testing with?

[ioannisg]

@andrewboie I agree we should fix that. But we need a Baseline with MPU, and, ideally, with a sufficient number of MPU regions, e.g. 8.

@jjmilburn thanks for the info; I will take a look. And I'll need to get a board, as well.

[ioannisg]

@jjmilburn how many MPU regions does this CPU have?

[jjmilburn]

@ioannisg I believe the answer is 8. References:

ST Appnote AN4838 indicates up to 16 (although thats inclusive of cores with more capability than the M0+):

The MPU can be used to protect up to sixteen memory regions. These, in turn can have eight subregions, if the region is at least 256 bytes. The subregions are always of equal size, and can be enabled or disabled by a subregion number. Because the minimum region size is driven by the cache line length (32 bytes), 8 subregions of 32 bytes corresponds to a 256 bytes size.
The regions are numbered 0-15. In addition, there is another region called the default region with an id of -1. All the 0-15 memory regions take priority over the default region.

See this table for confirmation of the 8 regions on the Cortex M0+ (Table from the same AN4838 linked above):

Finally, programming manual PM0223 (specific to the Cortex M0+) indicates:

The MPU can divide the memory map into a number of regions, and defines the location,
size, access permissions, and memory attributes of each region. It supports:
• Independent attribute settings for each region.
• Overlapping regions.
• Export of memory attributes to the system.
The memory attributes affect the behavior of memory accesses to the region. The
Cortex-M0+ MPU defines:
• Eight separate memory regions, 0-7.
• A background region.
When memory regions overlap, a memory access is affected by the attributes of the region
with the highest number. For example, the attributes for region 7 take precedence over the
attributes of any region that overlaps region 7.
The background region has the same memory access attributes as the default memory
map, but is accessible from privileged software only.
The Cortex-M0+ MPU memory map is unified. This means instruction accesses and data
accesses have same region settings.
If a program accesses a memory location that is prohibited by the MPU, the processor
generates a HardFault exception.
In an OS environment, the kernel can update the MPU region setting dynamically based on
the process to be executed. Typically, an embedded OS uses the MPU for memory
protection.

[ioannisg]

@jjmilburn thanks for your help on this. I've got this platform and will try to finally sort out this issue.

[jjmilburn]

Thanks!