0

Using Module and ModuleManager with ThreadX in a MPU-enabled platform is "default_module_start" considered part of ModuleManager and can call Tx APIs even though, it is in the app_module.c? E.G tx_thread_create works in default_module_start but doesn't work in the modules threads and throughs an exception;

Another question why is the ModuleManager is not just using the Tx APIs to handle threats for example, instead it uses custom functions that doesn't call Tx APIs at all

Hamdim
  • 19
  • 6

1 Answers1

1

Function demo_module_start is part of a module (this function is in sample_threadx_module.c). It runs in the module context. This function gets called by txm_module_thread_shell_entry.c when a module is started.

Modules run in unprivileged mode, but they call ThreadX APIs (a.k.a. kernel functions). In order to execute ThreadX APIs, the module uses the SVC instruction (for ARM processors) to get into supervisor (privileged) mode. Thus, in the module library, all of the kernel calls are just simple calls that pass the function parameters to the kernel, and the actual ThreadX function is executed in kernel (privileged) mode.

Let me know if this answers your questions or if you have more questions.

Edit:

You can call TX APIs from module threads. By default, they trap into the kernel via the SVC instruction. If you want to call TX APIs directly from a module (i.e. without trapping), the module needs to be in privileged mode execution, which you can configure by modifying the module properties in the preamble of the module (e.g. see https://github.com/azure-rtos/threadx/blob/master/ports_module/cortex_m7/gnu/example_build/txm_module_preamble.S - change the properties from 0x00000007 to 0x00000000).

Creating a module thread is a bit different than creating a normal thread. The manager puts the TXM_MODULE_THREAD_ENTRY_INFO into the module thread stack, allocates a kernel stack for the thread, builds the module thread stack (which has a different return mode than a normal thread).

The manager can have whatever priority you want to assign it. Most if not all of our module manager examples assign a priority of 1 (https://github.com/azure-rtos/threadx/blob/master/ports_module/cortex_m7/gnu/example_build/sample_threadx_module_manager.c).

ScottAzureRTOS
  • 166
  • 5
  • Thank you for the clarification, my question is why ***can't*** I call Tx APIs from "modules threads entries" (through a fault handler, memory violation) but I can call them in "default_module_start". Q2: why is the ModuleManager not just using the Tx APIs to handle threats, instead it uses custom functions that don't call Tx APIs at all(e.g txm_module_manager_thread_create)? what will be the difference between these two threads? Why is the ModuleManager has a priority(4) lower than the modules when the MM is the one managing them and it is privileged – Hamdim Aug 12 '22 at 04:47
  • Thank you for the clarification, I could call Tx APIs in "demo_module_start", however calling TX APIs like tx_thread_create in "module threads" throws a memory violation exception. I thought Tx APIs should not be called at all in the module context and my Q is what's the point of no-direct execution of Tx APIs in the module, if the result is the same, or it's for the developer to define a flow control after the trap to authorize and unauthorized certain TX API calls? or it's just working as a whole; authorize all TX APIs or omit them all by setting the module properties? – Hamdim Aug 16 '22 at 13:33
  • I don't understand your question. You can call tx_thread_create in a module thread. Note that you need to call txm_module_object_allocate in order to allocate a thread control block before calling create. – ScottAzureRTOS Aug 17 '22 at 17:37
  • What is the security purpose of disallowing modules to not call directly Tx APIs, while the result of using txm_module_* and tx_* are the same? – Hamdim Aug 18 '22 at 10:41
  • 1
    Consider a module as untrusted, 3rd-party code, like a Unix process making system calls. The kernel needs to make sure the module is passing valid pointers and not manipulating object control blocks like threads, semaphores, etc. – ScottAzureRTOS Aug 18 '22 at 17:03