1. devel@lists.zephyrproject.org

Re: Memory protection and picolibc global state

Boie, Andrew P
 

Hi Keith,

Sorry, just saw this. There are some k_mem_partitions defined which can help with this, z_malloc_partition and z_libc_partition.

z_malloc_partition is for the malloc() arena, which is global.
z_libc_partition is for any other globals associated with the libc.

These are defined in include/sys/libc-hooks.h along with the further comments.

This situation is not ideal. We would eventually like separate libc library globals and malloc arenas on a per memory domain basis (not per thread). This is, to put it mildly, tricky to do when all you have is an MPU. There's a issue here about it: https://github.com/zephyrproject-rtos/zephyr/issues/25891 the last comment has my current thinking on this problem.

HTH,
Andrew

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Keith Packard via lists.zephyrproject.org
Sent: Saturday, September 19, 2020 2:06 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Memory protection and picolibc global state


I'm continuing to develop picolibc (https://github.com/picolibc) support for
Zephyr under this PR:

https://github.com/zephyrproject-rtos/zephyr/pull/26545

I'm running the sanity checks under qemu on mps2_an521 which uses the
ARM MPU. On this board, the default memory protection configuration
seems to place all libc globals in a region which is protected against
application access. That includes globals used in managing the malloc heap,
and so application calls to malloc end up generating a MPU fault.

I can fix this in at least a couple of possible ways:

1) Create per-thread malloc heaps and track malloc per-thread.

2) Figure out how to change protection for libc globals

3) Replace the picolibc malloc implementation with a Zephyr custom
implementation.

--
-keith
Join devel@lists.zephyrproject.org to automatically receive all group messages.