| Age | Commit message (Collapse) | Author |
|---|
|
* Fixed the Cortex-A7 module data check to validate whole ranges
The Cortex-A7 module port received a module instance, a start address and a
byte size from the common Module Manager, then discarded the instance and the
size and asked the MMU to translate the start address alone, for reading only.
A range was therefore accepted whenever its first byte happened to be readable
by the module, so privileged dispatch code could read or write past the end of
the module's mapping, or use read-only module code as a write destination.
The check now takes the size and an access intent. The module's own data region
is answered from the manager's records, which name it exactly and cost no
translations; everything else is answered by translating every page the range
touches with the requested unprivileged access. Empty ranges, ranges whose last
byte would wrap, and ranges that leave the recorded data region partway through
are all refused, and the walk is bounded by TXM_MODULE_MANAGER_DATA_CHECK_MAX_PAGES
so one module request cannot impose unbounded work on the kernel. Translation is
only believed while the requesting module's own context is loaded.
The outside direction gets its own check rather than negating the inside one:
a range that reaches into the module only partway is inside neither answer, and
negating a whole-range check would have let it pass as a kernel object.
Other ports keep their single data check through backward-compatible fallbacks
in the common header; their preprocessed dispatch output is byte-identical.
Regression coverage runs on the host by standing a simulated page map behind the
one architecture primitive, and reaches 100% line, branch and call coverage of
the new logic. Twenty-four of its expectations fail against the previous
implementation.
Assisted-by: Claude Code (Opus 5)
* Drove the Cortex-A7 range check through a live MMU
The host test for this check stands a simulated page map behind the port's CP15
primitive, so it never executes an address translation. That leaves the part
most easily got wrong unexercised: an encoding naming the wrong operation, or a
PAR fault bit read the wrong way round, passes it without complaint.
This adds a bare-metal image that builds a short-descriptor translation table,
enables the MMU, and drives the real check through the real translations on a
real Cortex-A7 translation regime, plus a script that builds and runs it under
an emulator. Sections are mapped for unprivileged read/write, unprivileged read
only, and privileged only, with an unmapped section behind the read-only one so
that a range can be made to leave its mapping partway through.
That last case is the one the replaced check accepted, and the test asserts
both answers against the same live MMU: the current check rejects the range,
and translating only its first address accepts it.
It also confirms what the simulated map could only assume, that ATS1CUW denies
a write to a read-only mapping while ATS1CUR allows the read. The write intent
is the reason the port asks for two translations rather than one.
The script skips with a notice when the cross toolchain or the emulator is
absent, so a machine without them does not fail the build.
Assisted-by: Claude Code (Opus 5)
|
|
The control block ID that _txm_module_manager_object_deallocate clears on its way
out is read by the size-based object check, which is the one kept for dispatchers
outside this repository. Nothing exercised that path. The expectations covering
the clearing all went through object authentication, which consults the kernel's
created list and would refuse a recycled address whatever its ID said, so they
would have passed with the clearing removed.
A section drives the size-based check directly. A module plants the value of an
ID into memory it owns, gives the allocation back, and is handed the same address
again; the check accepts the planted ID before the deallocation and refuses it
afterwards, which is the difference the clearing makes.
The authentication test holds 125 expectations and passes. Removing the ID
clearing fails it. The full suite passes 107/107 in default_build_coverage with
no warnings.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
* 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) <[email protected]>
* 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) <[email protected]>
|
|
A memory-protected module names the kernel objects it wants operated on by
address, and the Module Manager decided whether a privileged service could
dereference that address by asking only whether it fell outside the module. The
object pool is outside every module, so that test was satisfied by an address
shifted into the interior of one of the module's own privileged allocations,
which denotes no object at all. The bytes such an address presents as a control
block are bytes the module put there through ordinary create and set services,
so the control block ID at the front of them could be made to read as any type
the module chose, and the _txe_ layer's ID test then agreed. A module could
therefore have the kernel read and write fields of an object that does not
exist, at an address it picked; the reported chain reaches a privileged memset
across an attacker-chosen range that way.
Authentication now answers the question the location test could not: is this the
exact address of a live kernel object of the type this service expects. It is
answered from the kernel's created list for the type, which the create and delete
services maintain, so membership establishes at once that the address is an
object start rather than an address inside an object, that the object is of this
type, and that it has not been deleted. That list is also what makes an object
the application created and shared with a module authenticable at all, since the
manager allocated no such object and has no record of its own to consult, so
sharing keeps working and needs no new registration API.
Nothing a module can influence is used to establish a type. An earlier form of
this fix accepted an address that was the exact start of one of the calling
module's own allocations of the right size and then took the type from the
control block ID, which is cheaper -- a module's allocation list is much shorter
than the system's created list for a type. The tests here refused it: a byte
pool, a mutex and a timer are all the same size on a 32-bit target, so an
allocation created as one of them and presented as another passed both the
address and the size test, leaving the ID as the only thing between the module
and a type confusion. The ID is still checked, after the created list has settled
the question, because it is the test the _txe_ services make and it is compiled
away with them under TX_DISABLE_ERROR_CHECKING. An address a module named is not
read at all until a kernel record says there is an object there.
All 58 object-using dispatchers now pass the object type rather than a control
block size, since a size cannot establish a type. Both scans are bounded by the
counts the kernel and the manager maintain beside their lists, so the cost of one
check is bounded and a list whose links have been damaged cannot make a scan run
on, and both run with interrupts disabled, which is the protection those lists
are maintained under and which adds no blocking point or priority inversion to a
kernel request. The cost is a walk of the created list for the type, paid only by
memory-protected modules; the size-based check is kept for dispatchers outside
this repository and hardened to refuse object pool interiors, which is the part
of the attack it can see without a type.
Two further changes close paths the authentication alone would leave open. Thread
reset now refuses a thread that carries no module instance: such a thread is
authentic, can be found by name and satisfies reset's own state test, and reset
reads the shell entry function out of that instance, so a null one was followed
in privileged mode. Object deallocation now clears the control block ID as it
gives memory back, so an object freed without being deleted first stops being
vouched for at the moment the manager stops owning its memory, rather than
returning to the pool still carrying a valid ID for the next allocation placed
there to present.
The 120 expectations in the new test offer every aligned interior offset of a
legitimate object as a foreign type, with that type's own ID planted at the
offset, and assert that none is accepted; they cover all eight object types
against each other, uncreated allocations, deleted objects, freed addresses that
have been handed out again, objects the application owns and memory that merely
carries a plausible ID, objects another module allocated, and the bounds on both
scans. Reverting the object checks to the permissive policy fails 89 of them;
removing the thread reset guard makes the test die with SIGSEGV inside the reset
path; removing the ID clearing in deallocation fails 2. All 99 tests pass in each
of the five configurations the tree builds with GCC 14.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
