Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

MMU usage vListInsert issues

Posted by friesen on January 17, 2019

I have been working on MMU support with task stack protection for the Cortex A5, and have the MMU working as intended on my part. However, I am running into this issue, that the vListInsert(and probably more) create a list that writes into a different task space, which causes a permission fault.

~~~ pxNewListItem->pxNext = pxIterator->pxNext; pxNewListItem->pxNext->pxPrevious = pxNewListItem;//<--- fault location pxNewListItem->pxPrevious = pxIterator; pxIterator->pxNext = pxNewListItem; ~~~

It faults because pxNewListItem->pxNext->pxPrevious is in the other tasks space.

Any ideas what to do, or whether to just give this up entirely?


MMU usage vListInsert issues

Posted by rtel on January 17, 2019

I don't know how you have set up the MPU on the Cortex-A, but in the Cortex-M MPU port we run the kernel code in privileged mode, then it can access the memory allocated to unprivileged tasks.


MMU usage vListInsert issues

Posted by friesen on January 17, 2019

When does it switch? Is the kernel code started yet after you call vTaskDelay() which ends up calling vListInsert?

The Cortex A5 doesn't have an MPU, rather an MMU, which takes a bit different thinking. So the createtask allocates out of a page aligned pool, then each allocated pool is set to be protected from other asid's.

On the A port, it would appear that tasks are running in SYS mode, I'm not sure about the thinking behind that.


MMU usage vListInsert issues

Posted by rtel on January 17, 2019

I'm afraid it is not clear to me what you are trying to achieve. Our MPU (noting that you have MMU, which in the past we have used as a kind of MPU just without virtual memory) port is used to enable different tasks to run at different privilege levels, and to isolate different memory regions. A task can run unprivileged, with a switch to privilege being effected using an SVC instruction each time it calls a FreeRTOS API function. I think in all memory protected cases the OS has to run with privileges (kernel mode) otherwise you are going to get the issue you are reporting - the kernel is isolated from the memory it needs to access.


MMU usage vListInsert issues

Posted by friesen on January 17, 2019

I'm trying to achieve task memory protection.

It isn't clear to me where to insert elevation, as the task calls vtaskdelay and there isn't really a defined place to say it is no longer user mode.


MMU usage vListInsert issues

Posted by rtel on January 17, 2019

Elevation should happen prior to calling vTaskDelay(). This is normally done by having the API function not a direct C subroutine call, but an SVC call, SVC being the only way to programmatically raise privilege. We take a slightly simpler approach though by wrapping vTaskDelay() in a function called MPUvTaskDelay() that raises privilege then calls the standard vTaskDelay(). The standard vTaskDelay() must be in a memory areas that is marked as privileged execution only, and the raising of the privilege must check that the source of the SVC was one of the MPUnnn() function wrappers.


MMU usage vListInsert issues

Posted by friesen on January 18, 2019

Thank you, this is making sense now. I don't see anywhere in the present code where the source of the SVC is checked though.

So is this whole MPU thing just a leftover from someone elses project, or is this active?

I suppose MMU support is too outside of what average FreeRTOS applications need. For me, it is more about developing a complex program and reducing development time.

Anyway, I suppose it was done this way as to keep code uncluttered, but it seems it would be cleaner if it was something like this.

~~~

if config_USEMMU == 1)
define vPortResetPriviledge LowerPriviledge(xRunningPrivileged)
define vPortRaisePriviledge BaseType_t xRunningPrivileged = xPortRaisePrivilege()
else
define vPortResetPriviledge
define vPortRaisePriviledge
endif
BaseType_t xTaskCreate(	TaskFunction_t pxTaskCode,
						const char * const pcName,		/*lint !e971 Unqualified char types are allowed for strings and single characters only. */
						const configSTACK_DEPTH_TYPE usStackDepth,
						void * const pvParameters,
						UBaseType_t uxPriority,
						TaskHandle_t * const pxCreatedTask )
{
TCB_t *pxNewTCB;
BaseType_t xReturn;
vPortRaisePriviledge;
/* code */
vPortResetPriviledge;
}

~~~

For me,


MMU usage vListInsert issues

Posted by rtel on January 18, 2019

Thank you, this is making sense now. I don't see anywhere in the present code where the source of the SVC is checked though.

That may be the case in the code in SVN, which was created with safety in mind rather than security. Our Cortex-M33 code on the other hand is more security focused, so does not permit any code other than the API function to use an SVC instruction.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS v10.2.1 is available for immediate download. MIT licensed, includes 64-bit RISC-V, NXP Cortex-M33 demo, Nuvoton Cortex-M23 demo & STM32H745 dual core (AMP) demo.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Mediatek

Renesas

RISC-V

SiFIve RISC-V

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner