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
Added various ...GetStaticBuffer() functions to get the buffers of statically
created objects.
---------
Co-authored-by: Paul Bartell <pbartell@amazon.com>
Co-authored-by: Nikhil Kamath <110539926+amazonKamath@users.noreply.github.com>
Co-authored-by: Gaurav Aggarwal <aggarg@amazon.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>
* 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
Add a cap to the queue locks
cRxLock and cTxLock members of the queue data structure count the
number items received and sent to the queue while the queue was locked.
These are later used to unblock tasks waiting on the queue when the
queue is unlocked. The data type of these members is int8_t and this can
trigger overflow check assert if an ISR continuously reads/writes to the
queue in a loop as reported in this issue: https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/419.
Note due to the length of the operation is it not recommended to write to
the queue that many times from an ISR - stream buffers are a better option,
or alternatively, defer the operation to a task by just having the ISR send a
direct to task notification to unblock the task.
This PR caps the values of the cRxLock and cTxLock to the number of tasks in
the system because we cannot unblocks more tasks than there are in the system.
Note that the same assert could still be triggered is the application creates more
than 127 tasks.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Indent contents of a taskENTER_CRITICAL/taskEXIT_CRITICAL block.
Move a few configASSERT() statements out of a path where they would always be triggered to prevent "condition is always true" compiler warnings.
* Replace configASSERT() positions due to unintended semantic change from the version where asserts were at the top of the file.
Co-authored-by: RichardBarry <richardbarry.c@gmail.com>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
* 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>
* Replace configASSERT( pcQueueName ) in vQueueAddToRegistry with a NULL pointer check.
FixesFreeRTOS/FreeRTOS-Kernel#311
* Make NULL checks consistent.
Overwrite an existing entry for a given xQueue handle when vQueueAddToRegistry is called with an xQueue handle of a queue that is already in the QueueRegistry.
* Add an LCOV_BRANCH exception for the check that sizeof( StaticQueue_t ) == sizeof( Queue_t )
* Add LCOV_BRANCH coverage exception for a configASSERT on pxQueueSetContainer with a condition that is unreachable.
* Add configASSERTs to alert when invalid parameters are passed into Queue Registry related functions.
* Assert that the semaphore handle passed into xQueueGetMutexHolder is not NULL.
* Correct some typos in queue.c
* Update lexicon.txt
* Style: make freertos.org = FreeRTOS.org also add https
* Style: Fix freertos into FreeRTOS
* Style: Fix freertos into FreeRTOS
Co-authored-by: Alfred Gedeon <gedeonag@amazon.com>
* 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>
* Added protection for xQueueGenericCreate
* prevent eventual invalid state change from int8 overflow
* Append period at end of comment. To be consistent with file.
* check operand, not destination
* parantheses -- to not show assumptive precendence
* Per request, less dependence on stdint by defining and checking against queueINT8_MAX instead
* * 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.