Frédéric Desbiens
2930618cfe
* Refused to give back the memory of a live kernel object A module allocates the control blocks of its kernel objects from the Module Manager's object pool and can ask for that memory back by address. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. Nothing on those paths consults a control block ID, so nothing about the memory having been freed stops the kernel from using it -- a created list walk reads a name pointer out of it and follows that pointer, a create or delete of another object of the same type writes through the created links in it, the scheduler switches the stack pointer to the word at offset 8 of it and pops a saved processor state, and timer expiration calls the function pointer in it. Meanwhile the byte pool is free to hand those same bytes to the next allocation, so what the kernel goes on reading as a control block becomes whatever the next owner of the memory puts there, through ordinary create services. The manager now refuses to release memory that holds an object which is still created, and returns TX_DELETE_ERROR without touching the allocation, the object or the memory. Deleting the object first is what makes its memory releasable, which is the sequence the delete dispatchers already follow and the one module authors are told to follow. The question is answered from the kernel's created lists, not from the control block. A control block ID is not evidence that an object is there: an allocation that was never created can be carrying the value of an ID, and refusing on that would strand memory a module is entitled to have back. Deallocation is also given an address and nothing else, so unlike a typed service it cannot be told which list to search, and each of the eight lists is searched in turn. The search is not narrowed by the size of the allocation, because that would be sound only if every object had been created through a size-checked path, and a module running without memory protection creates objects through no such path -- a queue at the start of a thread-sized allocation is a case the tests here cover. Each list is searched in its own interrupts-disabled window, bounded by the count the kernel keeps beside it, so the longest window is the length of one type's list and a list whose links have been damaged cannot make the search run on. The whole search is one pass over the objects the system has created, paid once per object deallocation. Storage that is not an object is released exactly as before, which is what keeps cleanup after a create that failed or was abandoned working, and what makes the release each delete dispatcher performs after a successful delete go through. The address the request arrives with is now checked before the manager's private header in front of it is read, rather than partly after. The size of the allocation comes from that header, so there is nothing to validate a size against until the header has been read, and the previous order established only where the header started: a header that began inside the pool and ended past it had its size word read from outside the pool. That check has moved out of the dispatcher into _txm_module_manager_param_check_object_for_deallocation, alongside the other parameter checks the dispatch table uses and where a test can reach it, and it now also refuses a size that would carry the end of the allocation past the top of the address space instead of wrapping it, since a wrapped end compares as though the allocation were inside the pool. The 301 expectations in the new test drive all eight object types through allocate, create, a refused deallocation, delete, and a deallocation that succeeds, and assert after the refusal that nothing reached the pool, that the allocation is still on the module's list at the head of it, that the control block still carries its ID and that the object is still live. They cover storage that was never created, storage carrying nothing but a plausible ID for each of the eight types, an object at the start of an oversized allocation, every aligned interior offset of a live object with that object's own ID planted at it, an application-owned object outside the pool, another module's allocations both live and raw, releasing the head of a list of several and releasing the same address twice, a type that has no created list, the bounds on the search against a list longer than its count and against a count larger than its list for every type, the boundary addresses at both ends of the pool, a crafted size, and an object pool that was never created. Removing the refusal fails 43 of them; removing the size wrap guard fails one. Line and branch coverage of the three new functions and of the changed _txm_module_manager_object_deallocate is 100%, with one exception that is test scaffolding rather than product code: the host shim's stand-in for TX_RESTORE has an underflow guard, and the test asserts that branch is never taken. All 99 tests pass in each of the five configurations the tree builds with GCC 14. Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com> * Removed the object deallocation bounds check superseded by the search _txm_module_manager_param_check_object_for_deallocation() bounded the private header in front of a caller's address before the deallocator read it. The deallocator no longer reads that header: it finds the allocation by searching the module's own allocation list, which never dereferences the address, so the bounds check now guards a read that does not happen. The function, its prototype, its macro and its one call site in the txm_module_object_deallocate dispatcher are removed, along with the twelve expectations that covered it and three declarations left unused by their removal. The search proves more than the check did: the bounds test established only that the header lay inside the object pool, while the search establishes that the address is the exact start of one of this module's allocations. The live object deallocation test holds 289 expectations and passes. Reverting the live-object guard still fails 51 of them, the same 51 as before the deletion, so nothing the removed expectations covered was load-bearing. The full suite passes 108/108 in default_build_coverage, with no warnings. Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>
Eclipse ThreadX RTOS
This advanced real-time operating system (RTOS) is designed specifically for deeply embedded applications. Among the multiple benefits it provides are advanced scheduling facilities, message passing, interrupt management, and messaging services. Eclipse ThreadX RTOS has many advanced features, including picokernel architecture, preemption threshold, event chaining, and a rich set of system services.
Here are the key features and modules of ThreadX:
Getting Started
Eclipse ThreadX has been integrated to the semiconductor's SDKs and development environment. You can develop using the tools of choice from STMicroelectronics, NXP, Renesas and Microchip.
We also provide getting started guide and samples using development boards from semiconductors you can build and test with.
See Overview of Eclipse ThreadX RTOS for the high-level overview.
Repository Structure and Usage
Directory layout
.
├── cmake # CMakelist files for building the project
├── common # Core ThreadX files
├── common_modules # Core ThreadX module files
├── common_smp # Core ThreadX SMP files
├── docs # Documentation supplements
├── ports # Architecture and compiler specific files. See below for directory breakdown
│ ├── cortex_m7
│ │ ├── iar # Example IAR compiler sample project
│ │ │ ├── example build # IAR workspace and sample project files
│ │ │ ├── inc # tx_port.h for this architecture
│ │ │ └── src # Source files for this architecture
│ │ ├── ac6 # Example ac6/Keil sample project
│ │ ├── gnu # Example gnu sample project
│ │ └── ...
│ └── ...
├── ports_modules # Architecture and compiler specific files for threadX modules
├── ports_smp # Architecture and compiler specific files for threadX SMP
├── samples # demo_threadx.c
└── utility # Test cases and utilities
Branches & Releases
The master branch has the most recent code with all new features and bug fixes. It does not represent the latest General Availability (GA) release of the library. Each official release (preview or GA) will be tagged to mark the commit and push it into the Github releases tab, e.g. v6.2-rel.
When you see xx-xx-xxxx, 6.x or x.x in function header, this means the file is not officially released yet. They will be updated in the next release. See example below.
/**************************************************************************/
/* */
/* FUNCTION RELEASE */
/* */
/* _tx_initialize_low_level Cortex-M23/GNU */
/* 6.x */
/* AUTHOR */
/* */
/* Scott Larson, Microsoft Corporation */
/* */
/* DESCRIPTION */
/* */
/* This function is responsible for any low-level processor */
/* initialization, including setting up interrupt vectors, setting */
/* up a periodic timer interrupt source, saving the system stack */
/* pointer for use in ISR processing later, and finding the first */
/* available RAM memory address for tx_application_define. */
/* */
/* INPUT */
/* */
/* None */
/* */
/* OUTPUT */
/* */
/* None */
/* */
/* CALLS */
/* */
/* None */
/* */
/* CALLED BY */
/* */
/* _tx_initialize_kernel_enter ThreadX entry function */
/* */
/* RELEASE HISTORY */
/* */
/* DATE NAME DESCRIPTION */
/* */
/* 09-30-2020 Scott Larson Initial Version 6.1 */
/* xx-xx-xxxx Scott Larson Include tx_user.h, */
/* resulting in version 6.x */
/* */
/**************************************************************************/
Supported Architecture Ports
ThreadX
arc_em cortex_a12 cortex_m0 cortex_r4
arc_hs cortex_a15 cortex_m23 cortex_r5
arm11 cortex_a17 cortex_m3 cortex_r7
arm9 cortex_a34 cortex_m33
c667x cortex_a35 cortex_m4
linux cortex_a5 cortex_m55
risc-v32 cortex_a53 cortex_m7
rxv1 cortex_a55 cortex_m85
rxv2 cortex_a57
rxv3 cortex_a5x
win32 cortex_a65
xtensa cortex_a65ae
cortex_a7
cortex_a72
cortex_a73
cortex_a75
cortex_a76
cortex_a76ae
cortex_a77
cortex_a8
cortex_a9
ThreadX Modules
Eclipse ThreadX Modules component provides an infrastructure for applications to dynamically load modules that are built separately from the resident portion of the application.
cortex_a35
cortex_a35_smp
cortex_a7
cortex_m0+
cortex_m23
cortex_m3
cortex_m33
cortex_m4
cortex_m7
cortex_r4
rxv2
ThreadX SMP
Eclipse ThreadX SMP is a high-performance real-time SMP kernel designed specifically for embedded applications.
arc_hs_smp
cortex_a34_smp
cortex_a35_smp
cortex_a53_smp
cortex_a55_smp
cortex_a57_smp
cortex_a5x_smp
cortex_a5_smp
cortex_a65ae_smp
cortex_a65_smp
cortex_a72_smp
cortex_a73_smp
cortex_a75_smp
cortex_a76ae_smp
cortex_a76_smp
cortex_a77_smp
cortex_a78_smp
cortex_a7_smp
cortex_a9_smp
linux
Adaptation layer for ThreadX
ThreadX is an advanced real-time operating system (RTOS) designed specifically for deeply embedded applications. To help ease application migration to ThreadX RTOS, Eclipse ThreadX provides adaption layers for various legacy RTOS APIs (FreeRTOS, POSIX, OSEK, etc.).
Component dependencies
The main components of ThreadX RTOS are each provided in their own repository, but there are dependencies between them, as shown in the following graph. This is important to understand when setting up your builds.
You will have to take the dependency graph above into account when building anything other than ThreadX itself.
Building and using the library
Instruction for building the ThreadX as static library using Arm GNU Toolchain and CMake. If you are using toolchain and IDE from semiconductor, you might follow its own instructions to use ThreadX RTOS components as explained in the Getting Started section.
-
Install the following tools:
- CMake version 3.0 or later
- Arm GNU Toolchain for arm-none-eabi
- Ninja
-
Cloning the repo
$ git clone https://github.com/eclipse-threadx/threadx.git -
Define the features and addons you need in
tx_user.hand build together with the component source code. You can refer totx_user_sample.has an example. -
Building as a static library
Each component of ThreadX RTOS comes with a composable CMake-based build system that supports many different MCUs and host systems. Integrating any of these components into your device app code is as simple as adding a git submodule and then including it in your build using the CMake
add_subdirectory().While the typical usage pattern is to include ThreadX into your device code source tree to be built & linked with your code, you can compile this project as a standalone static library to confirm your build is set up correctly.
An example of building the library for Cortex-M4:
$ cmake -Bbuild -GNinja -DCMAKE_TOOLCHAIN_FILE=cmake/cortex_m4.cmake . $ cmake --build ./build
Licensing
License terms for using Eclipse ThreadX are defined in the LICENSE.txt file of this repo. Please refer to this file for all definitive licensing information for all content, incl. the history of this repo.
Resources
The following are references to additional ThreadX RTOS resources:
- Product introduction: https://github.com/eclipse-threadx/rtos-docs
- Product issues and bugs, or feature requests: https://github.com/eclipse-threadx/threadx/issues
- TraceX Installer: https://aka.ms/azrtos-tracex-installer
You can also check previous questions or ask new ones on StackOverflow using the threadx-rtos and threadx tags.
Security
Eclipse ThreadX provides OEMs with components to secure communication and to create code and data isolation using underlying MCU/MPU hardware protection mechanisms. It is ultimately the responsibility of the device builder to ensure the device fully meets the evolving security requirements associated with its specific use case.
Contribution
Please follow the instructions provided in the CONTRIBUTING.md for the corresponding repository.