Documented how the Module Manager authenticates the kernel objects a module names

[fdesbiens]

Documentation for the Module Manager change that accompanies a private security advisory. The code change is under separate review.

Why

The "Module Manager pointer validation" section describes how a port answers for a range of memory. That is the right answer to the question a buffer poses, and not an answer to the question a kernel object poses: a range check establishes that privileged code may touch some memory, not that the memory is the object the service was asked to operate on.

For a kernel object that distinction is the whole point. 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 satisfies a range check while denoting no object at all — and the bytes it presents as a control block, ID included, are bytes the module placed there through ordinary create and set services.

What this adds

A "Kernel object validation" subsection stating the rule objects are held to:

• the address must be the exact address of a live object of the type the service expects;
• authentication is answered from the kernel's created list for that type;
• an address inside an object, an allocation not yet created, a deleted object and a mismatched type are all refused;
• a type is never taken from the object itself, since distinct object types of equal size exist;
• an address a module names is not read until a kernel record says there is an object there.

It also records:

• that the same rule is what allows an application-owned object to be shared with a module, that such an object is authenticated exactly as a module's own is, that no separate registration is needed, and that it must have been created;
• that identity, type and liveness are settled but authorisation is not, so an application sharing objects decides that question for itself;
• what authentication costs — a bounded walk of the created list for the type, with interrupts disabled, no blocking point, no priority inversion, paid only by modules built with TXM_MODULE_MEMORY_PROTECTION;
• the two service behaviours that follow: tx_thread_reset returns TX_NOT_DONE for a thread that is not a module thread, and txm_module_object_deallocate clears the control block ID of the memory it gives back.

Verification

Built with Antora and the rendered threadx-modules chapter 3 page checked: the new subsection appears in place before "Cortex-A7 MMU ports", and the API names render as intended.