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.
* Add croutines to the code base
* Add croutine changes to cmake, lexicon and readme
* Add croutine file to portable cmake file
* Add back more references from PR 591
* Pass top of stack to configINIT_TLS_BLOCK
Picolibc wants to allocate the per-task TLS block within the stack
segment, so it will need to modify the top of stack value. Pass the
pxTopOfStack variable to make this explicit.
Signed-off-by: Keith Packard <keithpac@amazon.com>
* Move newlib-specific definitions to separate file
This reduces the clutter in FreeRTOS.h caused by having newlib-specific
macros present there.
Signed-off-by: Keith Packard <keithpac@amazon.com>
* Make TLS code depend only on configUSE_C_RUNTIME_TLS_SUPPORT
Remove reference to configUSE_NEWLIB_REENTRANT as that only works
when using newlib. configUSE_C_RUNTIME_TLS_SUPPORT is always
set when configUSE_NEWLIB_REENTRANT is set, so using both was
redundant in that case.
Signed-off-by: Keith Packard <keithpac@amazon.com>
* portable-ARC: Adapt ARC support to use generalized TLS support
With generalized thread local storage (TLS) support present in the
core, the two ARC ports need to have the changes to the TCB mirrored
to them.
Signed-off-by: Keith Packard <keithpac@amazon.com>
* Add Thread Local Storage (TLS) support using Picolibc functions
This patch provides definitions of the general TLS support macros in
terms of the Picolibc TLS support functions.
Picolibc is normally configured to use TLS internally for all
variables that are intended to be task-local, so these changes are
necessary for picolibc to work correctly with FreeRTOS.
The picolibc helper functions rely on elements within the linker
script to arrange the TLS data in memory and define some symbols.
Applications wanting to use this mechanism will need changes in their
linker script when migrating to picolibc.
Signed-off-by: Keith Packard <keithpac@amazon.com>
---------
Signed-off-by: Keith Packard <keithpac@amazon.com>
Co-authored-by: Keith Packard <keithpac@amazon.com>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
* Adding in ability to support a library for freertos_config and a custom freertos_kernel_port (#558)
* Using single name definition for libraries everywhere. (#558)
* Supporting backwards compatibility with FREERTOS_CONFIG_FILE_DIRECTORY (#571)
* Removing compiler warnings for GNU and Clang. (#571)
* Added in documentation on how to consume from a main project. Added default PORT selection for native POSIX and MINGW platforms.
* Only adding freertos_config if it exists. Removing auto generation of it from a FREERTOS_CONFIG_FILE_DIRECTORY.
* Fixing clang and gnu compiler warnings.
* Adding in project information and how to compile for GNU/clang
* Fixing compiler issue with unused variable - no need to declare variable.
* Adding in compile warnings for linux builds that kernel is okay with using.
* Fixing more extra-semi-stmt clang warnings.
* Moving definition of hooks into header files if features are enabled.
* Fixing formatting with uncrustify.
* Fixing merge conflicts with main merge.
* Fixing compiler errors due to merge issues and formatting.
* Fixing Line feeds.
* Adding 'portNORETURN' into portmacros.h. Other Updates based on PR request
* Further clean-up of clang and clang-tidy issues.
* Removing compiler specific pragmas from common c files.
* Fixing missing lexicon entry and uncrustify formatting changes.
* Resolving merge issue multiple defnitions of proto for prvIdleTask
* Fixing formatting issues that are not covered by uncrustify. Use clang-tidy instead if you want this level of control.
* More uncrustify formatting issues.
* Fixing extra bracket in #if statement.
---------
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
The PR #597 introduced a new config option configTICK_TYPE_WIDTH_IN_BITS
which can be defined to one of the following:
* TICK_TYPE_WIDTH_16_BITS - Tick type is 16 bit wide.
* TICK_TYPE_WIDTH_32_BITS - Tick type is 32 bit wide.
* TICK_TYPE_WIDTH_64_BITS - Tick type is 64 bit wide.
Earlier we supported 16 and 32 bit width for tick type which was
controlled using the config option configUSE_16_BIT_TICKS. The PR
tried to maintain backward compatibility by honoring
configUSE_16_BIT_TICKS. The backward compatibility did not work as
expected though, as the macro configTICK_TYPE_WIDTH_IN_BITS was used
before it was defined. This PR addresses it by ensuring that the macro
configTICK_TYPE_WIDTH_IN_BITS is defined before it is used.
Testing
1. configUSE_16_BIT_TICKS is defined to 0.
Source (function xTaskIncrementTick in tasks.c):
```
const TickType_t xConstTickCount = xTickCount + ( TickType_t ) 1;
```
Assembly:
```
109e: 4b50 ldr r3, [pc, #320] ; (11e0 <xTaskIncrementTick+0x150>)
10a0: f8d3 4134 ldr.w r4, [r3, #308] ; 0x134
10a4: 3401 adds r4, #1
10a6: f8c3 4134 str.w r4, [r3, #308] ; 0x134
```
It is clear from assembly that the tick type is 32 bit.
2. configUSE_16_BIT_TICKS is defined to 1.
Source (function xTaskIncrementTick in tasks.c):
```
const TickType_t xConstTickCount = xTickCount + ( TickType_t ) 1;
```
Assembly:
```
10e2: 4b53 ldr r3, [pc, #332] ; (1230 <xTaskIncrementTick+0x15c>)
10e4: f8b3 4134 ldrh.w r4, [r3, #308] ; 0x134
10e8: b2a4 uxth r4, r4
10ea: 3401 adds r4, #1
10ec: b2a4 uxth r4, r4
10ee: f8a3 4134 strh.w r4, [r3, #308] ; 0x134
```
It is clear from assembly that the tick type is 16 bit.
3. configTICK_TYPE_WIDTH_IN_BITS is defined to TICK_TYPE_WIDTH_16_BITS.
Source (function xTaskIncrementTick in tasks.c):
```
const TickType_t xConstTickCount = xTickCount + ( TickType_t ) 1;
```
Assembly:
```
10e2: 4b53 ldr r3, [pc, #332] ; (1230 <xTaskIncrementTick+0x15c>)
10e4: f8b3 4134 ldrh.w r4, [r3, #308] ; 0x134
10e8: b2a4 uxth r4, r4
10ea: 3401 adds r4, #1
10ec: b2a4 uxth r4, r4
10ee: f8a3 4134 strh.w r4, [r3, #308] ; 0x134
```
It is clear from assembly that the tick type is 16 bit.
4. configTICK_TYPE_WIDTH_IN_BITS is defined to TICK_TYPE_WIDTH_32_BITS.
Source (function xTaskIncrementTick in tasks.c):
```
const TickType_t xConstTickCount = xTickCount + ( TickType_t ) 1;
```
Assembly:
```
109e: 4b50 ldr r3, [pc, #320] ; (11e0 <xTaskIncrementTick+0x150>)
10a0: f8d3 4134 ldr.w r4, [r3, #308] ; 0x134
10a4: 3401 adds r4, #1
10a6: f8c3 4134 str.w r4, [r3, #308] ; 0x134
```
It is clear from assembly that the tick type is 32 bit.
5. configTICK_TYPE_WIDTH_IN_BITS is defined to TICK_TYPE_WIDTH_64_BITS.
```
#error configTICK_TYPE_WIDTH_IN_BITS set to unsupported tick type width.
```
The testing was done for GCC/ARM_CM3 port which does not support 64 bit
tick type.
6. Neither configUSE_16_BIT_TICKS nor configTICK_TYPE_WIDTH_IN_BITS
defined.
```
#error Missing definition: One of configUSE_16_BIT_TICKS and
configTICK_TYPE_WIDTH_IN_BITS must be defined in FreeRTOSConfig.h.
See the Configuration section of the FreeRTOS API documentation for
details.
```
7. Both configUSE_16_BIT_TICKS and configTICK_TYPE_WIDTH_IN_BITS defined.
```
#error Only one of configUSE_16_BIT_TICKS and
configTICK_TYPE_WIDTH_IN_BITS must be defined in FreeRTOSConfig.h.
See the Configuration section of the FreeRTOS API documentation for
details.
```
Related issue - https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/628
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Generalize Thread Local Storage (TLS) support
FreeRTOS's Thread Local Storage (TLS) support used variables and
functions from newlib, thereby making the TLS support specific to
newlib. This commit generalizes the TLS support so that it can be used
with other c-runtime libraries also. The default behavior for newlib
support is still kept same for backward compatibility.
The application writer would need to set configUSE_C_RUNTIME_TLS_SUPPORT
to 1 in their FreeRTOSConfig.h and define the following macros to
support TLS for a c-runtime library:
1. configTLS_BLOCK_TYPE - Type used to define the TLS block in TCB.
2. configINIT_TLS_BLOCK( xTLSBlock ) - Allocate and initialize memory
block for the task's TLS Block.
3. configSET_TLS_BLOCK( xTLSBlock ) - Switch C-Runtime's TLS Block to
point to xTLSBlock.
4. configDEINIT_TLS_BLOCK( xTLSBlock ) - Free up the memory allocated
for the task's TLS Block.
The following is an example to support TLS for picolibc:
#define configUSE_C_RUNTIME_TLS_SUPPORT 1
#define configTLS_BLOCK_TYPE void*
#define configINIT_TLS_BLOCK( xTLSBlock ) _init_tls( xTLSBlock )
#define configSET_TLS_BLOCK( xTLSBlock ) _set_tls( xTLSBlock )
#define configDEINIT_TLS_BLOCK( xTLSBlock )
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 supposrt for ARM CM55
* Fix file header
* Remove duplicate code
* Refactor portmacro.h
1. portmacro.h is re-factored into 2 parts - portmacrocommon.h which is
common to all ARMv8-M ports and portmacro.h which is different for
different compiler and architecture. This enables us to provide
Cortex-M55 ports without code duplication.
2. Update copy_files.py so that it copies Cortex-M55 ports correctly -
all files except portmacro.h are used from Cortex-M33 ports.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Co-authored-by: Gaurav Aggarwal <aggarg@amazon.com>
* Add configUSE_MINI_LIST_ITEM configuration option to enable the MiniListItem_t type.
When configUSE_MINI_LIST_ITEM == 0:
MiniListItem_t and ListItem_t are both typedefs of struct xLIST_ITEM.
When configUSE_MINI_LIST_ITEM == 1 (the default in projdefs.h):
MiniListItem_t is a typedef of struct xMINI_LIST_ITEM, which contains 3 fewer fields than a struct xLIST_ITEM.
This configuration saves approximately sizeof(TickType_t) + 2 * sizeof( void * ) bytes of ram, however it also violates strict aliasing rules which some compilers depend on for optimization.
configUSE_MINI_LIST_ITEM defaults to 1 when not defined.
* Add pp_indent_brace option to uncrustify config
Improves compliance with the FreeRTOS code style guide:
https://www.freertos.org/FreeRTOS-Coding-Standard-and-Style-Guide.html
* uncrustify with github workflows
* Fix find expression
* Add uncrustify configuration file
* Uncrustify some files
* uncrustify some more files
* uncrustify more files
* Fix whitespace at end of lines
Co-authored-by: Cobus van Eeden <35851496+cobusve@users.noreply.github.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.
configSTACK_ALLOCATION_FROM_SEPARATE_HEAP was added recently in
https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/267. This macro was
used in portable.h before its default value was defined, resulting in a
warning when built with -Wundef. This changes moves the default value
definition for configSTACK_ALLOCATION_FROM_SEPARATE_HEAP to portable.h
to ensure that it is defined before first use.
portUSING_MPU_WRAPPERS check in mpu_wrappers.h was updated in
https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/285. The new check
results in a warning when built with -Wundef because
portUSING_MPU_WRAPPERS is not defined yet. This changes adds the default
value definition for portUSING_MPU_WRAPPERS to portable.h to ensure that
it is defined before first use.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
The change adds support for allocating task stacks from separate heap.
When configSTACK_ALLOCATION_FROM_SEPARATE_HEAP is defined as 1 in
FreeRTOSConfig.h, task stacks are allocated and freed using
pvPortMallocStack and vPortFreeStack functions. This allows the
application writer to provide a separate allocator for task stacks.
When configSTACK_ALLOCATION_FROM_SEPARATE_HEAP is defined as 0, task
stacks are allocated and freed using FreeRTOS heap functions
pvPortMalloc and vPortFree.
For backward compatibility, configSTACK_ALLOCATION_FROM_SEPARATE_HEAP
defaults to 0.
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>
* * Renamed trace point in prvNotifyQueueSetContainer() so it isn't a duplicate of the trace point in xQueueGenericSend()
* * Fixed backwards compatibility.
Co-authored-by: Erik Tamlin <erik.tamlin@percepio.com>
Description
Before this change each task had a single direct to task notification value and state as described here: https://www.FreeRTOS.org/RTOS-task-notifications.html. After this change each task has an array of task notifications, so more than one task notification value and state per task. The new FreeRTOSConfig.h compile time constant configTASK_NOTIFICATION_ARRAY_ENTRIES sets the number of indexes in the array.
Each notification within the array operates independently - a task can only block on one notification within the array at a time and will not be unblocked by a notification sent to any other array index.
Task notifications were introduced as a light weight method for peripheral drivers to pass data and events to tasks without the need for an intermediary object such as a semaphore - for example, to unblock a task from an ISR when the operation of a peripheral completed. That use case only requires a single notification value. Their popularity and resultant expanded use cases have since made the single value a limitation - especially as FreeRTOS stream and message buffers themselves use the notification mechanism. This change resolves that limitation. Stream and message buffers still use the task notification at array index 0, but now application writers can avoid any conflict that might have with their own use of task notifications by using notifications at array indexes other than 0.
The pre-existing task notification API functions work in a backward compatible way by always using the task notification at array index 0. For each such function there is now an equivalent that is postfixed "Indexed" and takes an additional parameter to specify which index within the array it should operate upon. For example, xTaskNotify() is the original that only operates on array index 0. xTaskNotifyIndexed() is the new function that can operate on any array index.
Test Steps
The update is tested using the Win32 demo (PR to be created in the FreeRTOS/FreeRTOS github repo), which has been updated to build and run a new test file FreeRTOS/Demo/Common/Minimal/TaskNotifyArray.c. The tests in that file are in addition to, not a replacement for those in FreeRTOS/Demo/Common/Minimal/TaskNotify.c.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
kar-rahul-aws
chinglee-iot
Aniruddha Kanhere
Keith Packard
phelter
Gaurav-Aggarwal-AWS
Dusan Cervenka
Paul Bartell
tcpluess
Monika Singh
Paul Bartell
RichardBarry
Ravishankar Bhagavandas
alfred gedeon
Pramith K V
nazar01
Cobus van Eeden
David Chalco
David Chalco
alfred gedeon
Alfred Gedeon
eriktamlin
cykro82
syntroniks
Yuhui.Zheng