Mpu_wrappers.h not using priviledged functions for kernel as default?

Kernel
1

Hi there,
just moving towards MPU usage with FreeRTOS.
As I am new to the whole MPU-world (not new to FreeRTOS btw), I am digging through all the files to get my linkerscript adopted and I found something that I can’t understand:

If I check in mpu_wrappers.h how the defines are mapped, I see per default that it looks like

/* Remove the privileged function macro, but keep the PRIVILEGED_DATA
 * macro so applications can place data in privileged access sections
 * (useful when using statically allocated objects). */
        #define PRIVILEGED_FUNCTION
        #define PRIVILEGED_DATA    __attribute__( ( section( "privileged_data" ) ) )
        #define FREERTOS_SYSTEM_CALL

Why would the kernel code not be mapped like it is done when one uses own wrappers?

    #else /* MPU_WRAPPERS_INCLUDED_FROM_API_FILE */

/* Ensure API functions go in the privileged execution section. */
        #define PRIVILEGED_FUNCTION     __attribute__( ( section( "privileged_functions" ) ) )
        #define PRIVILEGED_DATA         __attribute__( ( section( "privileged_data" ) ) )
        #define FREERTOS_SYSTEM_CALL    __attribute__( ( section( "freertos_system_calls" ) ) )

    #endif /* MPU_WRAPPERS_INCLUDED_FROM_API_FILE */

Or is the reason, that when using mpu_wrappers.h in default way, because of the wrapping, the protected functions are not visible to my non-priviledged task anyway, so there is no real need to hide them from unpriviledged tasks?

If my guess is right, does this mean, that I need the MPU primarily to protect RAM areas (and in my case, some IOs dedicated to certain tasks) ?

2

Not able to look at the file right now, but suspect this is because function names get remapped to the “MPU_” versions, but the name of the data does not get remapped so the attribute remains.

3

Is your question specifically about the definitions of PRIVILEGED_FUNCTION, PRIVILEGED_DATA and FREERTOS_SYSTEM_CALL being different for application files and FreeRTOS source files?

If I understood your question correctly, PRIVILEGED_FUNCTION and FREERTOS_SYSTEM_CALL macros are used to decorate function declarations to place FreeRTOS code in separate Flash sections (and then an MPU region is used to protect these from unprivileged access). These decorators are not needed when FreeRTOS headers are included by the application files. An example is: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/include/task.h#L345

PRIVILEGED_DATA is used to decorate FreeRTOS internal data to place it in separate RAM section (and then an MPU region is used to protect these from unprivileged access). The reason for leaving this defined for application code is explained in the comment:

/* Remove the privileged function macro, but keep the PRIVILEGED_DATA
 * macro so applications can place data in privileged access sections
 * (useful when using statically allocated objects). */

An example is: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/tasks.c#L338

You can use MPU to protect whatever memory space you like as long as it satisfies the hardware requirements of alignments and size. An unprivileged task, created using xTaskCreateRestricted, has access to only its stack by default - You can grant it access to three additional memory regions at the time of creation: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/include/task.h#L137.

Thanks.

4

Today I worked myself more through the code. It was a misunderstanding on my side. I misinterpreted the use of MPU_WRAPPERS_INCLUDED_FROM_API_FILE.
Now things are clear. The flags switches the apping of MPU-related API calls depending on from where the header is included and makes the sections attributes visible in the way they are needed depending on the file the header was included from. :white_check_mark: