Chapter 3 - Module Manager requirements

A range check answers whether privileged code may touch some memory. It cannot answer whether the memory is the object a service was asked to operate on, and for a kernel object that is the question that matters. The Module Manager’s object pool lies outside every module, so an address pointing into the middle of one of a module’s own privileged allocations is outside the module and would pass a range check while denoting no object at all. The bytes at such an address are bytes the module placed there through ordinary create and set services, including the control block ID at the front of them, so the ID alone establishes nothing.

Every service that takes a kernel object therefore authenticates it separately, and the rule is exact:

A rejected object causes the service to return TXM_MODULE_INVALID_MEMORY.

The same rule is what allows an object the application created to be shared with a module. Such an object is not in the Module Manager’s object pool and the manager has no record of its own to consult, so the kernel created list stands in place of one. An application object found by txm_module_object_pointer_get is authenticated exactly as a module’s own object is, and needs no separate registration. It must have been created: a control block the application has declared but not yet created is not yet an object.

What object authentication settles is identity, type and liveness. It does not settle whether the requesting module is authorised to operate on an authentic object that belongs to somewhere else. An application that shares objects between modules, or between itself and a module, decides that question for itself.

Authenticating an object costs a walk of the created list for its type, bounded by the count the kernel maintains beside that list, and the walk runs with interrupts disabled because that is the protection the list is maintained under. It introduces no blocking point and no priority inversion into a kernel request. Only modules built with TXM_MODULE_MEMORY_PROTECTION pay it.

Two services behave differently as a consequence:

Being allowed to use a kernel object is not the same as being allowed to destroy it, and the Module Manager asks the two questions separately.

A module may pass any object outside its own memory to an ordinary service. That is what makes sharing work: txm_module_object_pointer_get_extended searches the system’s created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a queue, take a semaphore or get a mutex that belongs to someone else.

Deleting an object is the inverse of creating one, and it asks what creating one asks. A memory-protected module may delete a kernel object only if the object is one it allocated for itself from the Module Manager’s object pool, at the exact address the manager returned to it, and the allocation was made for an object of that type’s control block size. A module that names an object the application owns, an object another module owns, or an address that is not the start of one of its own allocations, gets TXM_MODULE_INVALID_MEMORY from the tx*delete service.

The refusal happens before the kernel is asked to delete anything, which is the part that matters: the object stays created, nothing waiting on it is resumed with TX_DELETED, the created count for its type does not change, and the caller’s own objects are untouched. There is no state to undo, because none was changed.

The rule also governs the memory. The address a module hands back is looked up in that module’s own allocation list rather than by reading the manager’s private header from in front of it, so an address the manager never gave that module — including one nowhere near the object pool — is refused without any privileged read of the words in front of it.

Two of the eight object types are already unreachable by name for a memory-protected module: txm_module_object_pointer_get_extended refuses TXM_BLOCK_POOL_OBJECT and TXM_BYTE_POOL_OBJECT with TXM_MODULE_INVALID, so such a module can only name a block pool or byte pool it created itself or was given a pointer to by other means.

Modules loaded without memory protection are not subject to this check, as they are not subject to the other pointer checks in the dispatch layer. txm_module_manager_stop is likewise unaffected: it deletes the objects a module created through the Module Manager’s own internal path rather than through a module request, so unloading a module still cleans up everything it created.

Memory a module obtains from the Module Manager’s object pool carries a private header immediately in front of the address the module is given, recording which module the allocation belongs to and how large it is. An address a module asks to have deallocated is therefore accepted only if it lies far enough inside the pool for that whole header to be in front of it, and if the allocation the header describes also ends inside the pool; anything else returns TXM_MODULE_INVALID_MEMORY, and the header is not read to reach that answer.

The Module Manager will not release memory that holds a live kernel object. Giving an object’s memory back is not the same as deleting the object: the object would stay on the created list for its type, a thread would stay schedulable, and an active timer would stay on the timer list, while the pool went on to hand the same bytes to another allocation. txm_module_object_deallocate returns TX_DELETE_ERROR for such a request and changes nothing. Memory holding no live object — storage allocated for an object that was never created, or one that has since been deleted — is released as usual, which is how the dispatch layer releases an object’s memory for the module after a successful tx*delete.

Whether an object is live is answered from the kernel’s own created lists rather than from the control block, because 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 objects of different types share a size.

On the Cortex-A7 MMU ports the module’s own data region is answered from the Module Manager’s records, which name it exactly. Shared and external memory has no such record, so the port asks the MMU to translate every page the range touches, using an unprivileged read or an unprivileged write according to what the service will do with it.

Because a module chooses the size it passes, the number of pages a single request can ask the port to translate is bounded. TXM_MODULE_MANAGER_DATA_CHECK_MAX_PAGES sets that bound and defaults to 1024, which allows a 4 MB range. A range spanning more pages than this is rejected. An application that passes larger shared-memory ranges to ThreadX services can define a larger value before including txm_module_port.h.

The check is only meaningful while the requesting module’s translation context is the one loaded in the processor, which is the case for a module’s own kernel requests. If the contexts do not match, the port reports the range as neither inside nor outside the module, and the service fails rather than acting on an answer that describes some other address space.