|
|
processor's own accesses, and unvalidated
Sweeping all sixteen dwords of the ring frame found that one kills the processor, and that
offset is not reserved: it holds the virtual-memory identifier and the frame type. Any
non-zero identifier wedges the processor, a seventh host-triggerable trigger needing a
power cycle, while the frame type is ignored entirely.
The interrupt log during the attempt shows memory-controller protection faults tagged with
the host-supplied identifier, at the processor's own command buffer address, so the value
is propagated into the processor's own memory accesses as the translation context with
nothing validating it and death rather than an error status as the failure mode.
What was not achieved is stated plainly: configuring the hub's context one with the same
root page table and flushing its lookaside buffer does not make the non-zero identifier
work, so either a different hub or context set is used or more setup is required, and a
controlled access under a host-chosen context was not demonstrated. A first version of
that experiment measured before and after inside one boot and its verdict is recorded as
void, because one attempt kills the processor so the later control inherited a dead one.
The concerning shape is a virtualized configuration, where a frame field naming the
translation context and honoured unchecked by trusted firmware is a confused deputy; that
is labelled a hypothesis, since the virtualized mode is not available here.
|
