ARM: Userspace: should we have default system app partitions?

[ioannisg]

Is your enhancement proposal related to a problem? Please describe.
Since we have depreciated APP_SHARED_MEM, when we build with CONFIG_USERSPACE, it seems to me that there are, by default, two partitions generated:

• z_libc_partition
• z-malloc_partition

In addition to that, when we run a test in user mode, there is also

• ztest_mem_partition
  generated by the program.

As a result, in the kernel tests with User mode / Stack Protection, we have, in total 5 MPU regions reserved by the system (the 3 partitions, one for the thread stack, and one for the stack guard).

Now, there are platforms, such as nRF52810 which require 4 partitions for the background FLASH and SRAM, because the flash and SRAM do not have power-of-two sizes.

Consequently, the tests ASSERT because the total number of hardware regions is 8 (Cortex-M3, Cortex-M4).

Describe the solution you'd like
I would like to be able to run the kernel tests in these platforms, if possible.

Describe alternatives you've considered
Would it be possible to have the two system partitions (libc, malloc) defined conditionally, i.e. with some Kconfig symbol? And then we would enable this by default or not in the tests suites.

Also, do we document that CONFIG_USERSPACE requires minimum 3 partitions in ARMv7-M builds (the two system parts and the thread stack)? It would be nice to tell the developer how many regions are required for enabling user mode support.

Finally: if no action will be taken - how can we filter out these platforms from running the kernel tests on user mode?

[ioannisg]

FYI @agross-linaro.

@carlescufi I add this as a bug for nRF52810 - because it looks to me we cannot make a nRF52810 build with USERSPACE and HW_STACK_PROTECTION enabled. And I would assume a user would like to have that option in this platform, too.

[andrewboie]

I'm wondering if we can reduce the number of partitions being used on these devices with only 8 partitions, by removing those partitions which are not strictly required to implement userspace, we have some which are intended to catch supervisor mode bugs.

• We could disable the MPU stack guards and free a region. They are not required for userspace as they only guard against supervisor mode stack overflows
• We could remove the boot SRAM regions and set the background mapping to allow supervisor mode to read/write anywhere it wants.

This would free 2-3 regions which would make memory domains far more usable on these devices.

[andrewboie]

Would it be possible to have the two system partitions (libc, malloc) defined conditionally, i.e. with some Kconfig symbol? And then we would enable this by default or not in the tests suites.

The partition definitions by themselves don't hurt anything. It's more a question of, what partitions do we add by default to ztest's memory domain?
We could conditionally add the malloc arena since lots of embedded apps never use malloc.
Disabling the libc domain will probably cause lots of newlib APIs to blow up.

[andrewboie]

PR #13924 should help with this some.
We will not be programming the libc and malloc partitions if there is nothing in them, which happens if minimal libc is in use, stack canaries are not enabled, and there is no malloc heap. Before, due to the placeholders, they were taking up MPU slots.

Not a final fix by means, still considering this.

[ioannisg]

We could conditionally add the malloc arena since lots of embedded apps never use malloc.

This is good enough. It will leave out 0 app mem partitions for the user, in nRF52810 builds, but at least the tests that enable USERSPACE but do not actively use partitions, will be able to execute.

[andrewboie]

#13924 now only adds the malloc and libc partitions if they exist based on kernel configuration.