Memory Protection Unit (MPU) Enhancements
This commit introduces a new MPU wrapper that places additional
restrictions on unprivileged tasks. The following is the list of changes
introduced with the new MPU wrapper:
1. Opaque and indirectly verifiable integers for kernel object handles:
All the kernel object handles (for example, queue handles) are now
opaque integers. Previously object handles were raw pointers.
2. Saving the task context in Task Control Block (TCB): When a task is
swapped out by the scheduler, the task's context is now saved in its
TCB. Previously the task's context was saved on its stack.
3. Execute system calls on a separate privileged only stack: FreeRTOS
system calls, which execute with elevated privilege, now use a
separate privileged only stack. Previously system calls used the
calling task's stack. The application writer can control the size of
the system call stack using new configSYSTEM_CALL_STACK_SIZE config
macro.
4. Memory bounds checks: FreeRTOS system calls which accept a pointer
and de-reference it, now verify that the calling task has required
permissions to access the memory location referenced by the pointer.
5. System call restrictions: The following system calls are no longer
available to unprivileged tasks:
- vQueueDelete
- xQueueCreateMutex
- xQueueCreateMutexStatic
- xQueueCreateCountingSemaphore
- xQueueCreateCountingSemaphoreStatic
- xQueueGenericCreate
- xQueueGenericCreateStatic
- xQueueCreateSet
- xQueueRemoveFromSet
- xQueueGenericReset
- xTaskCreate
- xTaskCreateStatic
- vTaskDelete
- vTaskPrioritySet
- vTaskSuspendAll
- xTaskResumeAll
- xTaskGetHandle
- xTaskCallApplicationTaskHook
- vTaskList
- vTaskGetRunTimeStats
- xTaskCatchUpTicks
- xEventGroupCreate
- xEventGroupCreateStatic
- vEventGroupDelete
- xStreamBufferGenericCreate
- xStreamBufferGenericCreateStatic
- vStreamBufferDelete
- xStreamBufferReset
Also, an unprivileged task can no longer use vTaskSuspend to suspend
any task other than itself.
We thank the following people for their inputs in these enhancements:
- David Reiss of Meta Platforms, Inc.
- Lan Luo, Xinhui Shao, Yumeng Wei, Zixia Liu, Huaiyu Yan and Zhen Ling
of School of Computer Science and Engineering, Southeast University,
China.
- Xinwen Fu of Department of Computer Science, University of
Massachusetts Lowell, USA.
- Yuequi Chen, Zicheng Wang, Minghao Lin of University of Colorado
Boulder, USA.
It was possible for an unprivileged task to invoke any function with
privilege by passing it as a parameter to MPU_xTaskCreate,
MPU_xTaskCreateStatic, MPU_xTimerCreate, MPU_xTimerCreateStatic, or
MPU_xTimerPendFunctionCall.
This commit ensures that MPU_xTaskCreate and MPU_xTaskCreateStatic can
only create unprivileged tasks. It also removes the following APIs:
1. MPU_xTimerCreate
2. MPU_xTimerCreateStatic
3. MPU_xTimerPendFunctionCall
We thank Huazhong University of Science and Technology for reporting
this issue.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
It was possible for a third party that had already independently gained
the ability to execute injected code to achieve further privilege
escalation by branching directly inside a FreeRTOS MPU API wrapper
function with a manually crafted stack frame. This commit removes the
local stack variable `xRunningPrivileged` so that a manually crafted
stack frame cannot be used for privilege escalation by branching
directly inside a FreeRTOS MPU API wrapper.
We thank Certibit Consulting, LLC, Huazhong University of Science and
Technology and the SecLab team at Northeastern University for reporting
this issue.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Let each stream/message can use its own sbSEND_COMPLETED
In FreeRTOS.h, set the default value of configUSE_SB_COMPLETED_CALLBACK
to zero, and add additional space for the function pointer when
the buffer created statically.
In stream_buffer.c, modify the macro of sbSEND_COMPLETED which let
the stream buffer to use its own implementation, and then add an
pointer to the stream buffer's structure, and modify the
implementation of the buffer creating and initializing
Co-authored-by: eddie9712 <qw1562435@gmail.com>
* Add a guard around mpu_wrappers.c
This avoid linker errors when this file is accidently compiled in
projects using non-MPU ports.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Fix formatting check
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
The secure side context management code now checks that the secure
context being saved or restored belongs to the task being switched-out
or switched-in respectively.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Introduce configRUN_TIME_COUNTER_TYPE which enables developers to define the type used to hold run time statistic counters. Defaults to uint32_t for backward compatibility. #define configRUN_TIME_COUNTER_TYPE to a type (for example, uint64_t) in FreeRTOSConfig.h to override the default.
Introduce ulTaskGetIdleRunTimePercent() to complement the pre-existing ulTaskGetIdleRunTimeCounter(). Whereas the pre-existing function returns the raw run time counter value, the new function returns the percentage of the entire run time consumed by the idle task. Note the amount of idle time is only a good measure of the slack time in a system if there are no other tasks executing at the idle priority, tickless
idle is not used, and configIDLE_SHOULD_YIELD is set to 0.
* Add ultaskgetidleruntimepercent to lexicon.txt.
* Update History file.
Add the MPU version of ulTaskGetIdleRunTimePercent().
* Update include/FreeRTOS.h to correct comment as per aggarg@ suggestion.
* Fix alignment in mpu_wrappers.h.
Commit changes to mpu_prototypes.h which were missed from the original commit.
This change removes the FreeRTOS System Calls (aka MPU wrappers) for the
following kernel APIs:
- xTaskCreateRestricted
- xTaskCreateRestrictedStatic
- vTaskAllocateMPURegions
A system call allows an unprivileged task to execute a kernel API which
is otherwise accessible to privileged software only. The above 3 APIs
can create a new task with a different MPU configuration or alter the
MPU configuration of an existing task. This an be (mis)used by an
unprivileged task to grant itself access to a region which it does not
have access to.
Removing the system calls for these APIs ensures that an unprivileged
task cannot execute this APIs. If an unprivileged task attempts to
execute any of these API, it will result in a Memory Fault.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
This PR:
Changes the INCLUDE_vTaskDelayUntil compile time constant to INCLUDE_xTaskDelayUntil.
Updates FreeRTOS.h to ensure backward compatibility for projects that already have INCLUDE_vTaskDelayUntil defined.
Updates the MPU prototypes, wrapper and implementation to use the updated xTaskDelayUntil() function.
Tests to be checked into the FreeRTOS/FreeRTOS repository after this PR.
* Style: Change FreeRTOS websites in comments
* Style: Change freertos to FreeRTOS in comments
* Style: Remove broken link
Co-authored-by: Alfred Gedeon <gedeonag@amazon.com>
The expected behaviour of portIS_PRIVILEGED is:
- return 0 if the processor is not running privileged.
- return 1 if the processor is running privileged.
Some TI ports do not return 1 when the processor is running privileged
causing the following check to fail: if( xRunningPrivileged != pdTRUE )
This commit change the check to: if( xRunningPrivileged == pdFALSE ). It
ensures that the check is successful even on the ports which return incorrect
value from portIS_PRIVILEGED when the processor is running privileged.
See https://forums.freertos.org/t/kernel-bug-nested-mpu-wrapper-calls-generate-an-exception/10391
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
These definitions were not useful because the corresponding mapping was
removed from mpu_wrappers.h earlier.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
kar-rahul-aws
Paul Bartell
Gaurav Aggarwal
Ravishankar Bhagavandas
Gaurav-Aggarwal-AWS
RichardBarry
Cobus van Eeden
David Chalco
Joseph Julicher
David Chalco
alfred gedeon
Alfred Gedeon
Yuhui.Zheng