| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
paths
The dynamic watcher reported zero reads and zero writes in [0x21500,0x21B78]
across a full boot, 3 TA loads and 6 ring commands. Getting to the point where
that zero could be believed took fixing two controls that failed in opposite
directions.
Broken control #1 retracted a correct result. It injected `ldr r1,[r0]` with
r0 = 0x21500 and checked the hook fired; post-boot it did not, and I concluded
the MMU had made the watcher blind and declared the result void. Instrumenting
the probe with an unfiltered hook showed no memory access AT ALL post-boot, not
a translated one: the injected instruction never executed, because once the MMU
is configured there is no mapping for the scratch page. The control was
measuring code injection, not observability. A control that fails for a reason
unrelated to the claim is worse than no control -- it retracts correct results
while looking rigorous.
Broken control #2 was the hook range, again: the replacement control looked for
traffic above the window and found none, because the hook was registered with
end=0x22000 so those addresses could never be delivered. Third instance of that
same truncation this session.
Corrected, the controls pass: 15,438,193 reads in a known-busy range from 197
PCs (liveness), and 20 pages below the window plus 1 above, highest 0x3d000
(spanning coverage). Firmware reads land across 21 pages of that region; a read
at 0x21500 would have appeared exactly as those do. It never happens.
This is strictly better than the static scan and immune to its base+offset blind
spot, since at run time the address exists whether or not it appears whole in
the image. The six unresolved indexable bases are answered on these paths: none
reaches the window. Register updated from provisional back to bounded-low, now
resting on dynamic evidence.
Residual limits unchanged and restated in both docs: exercised paths only, the
boot ROM is not emulated, and the emulator backs the window with plain RAM, so a
hardware consumer is invisible here by construction. That last one is why the
rating is bounded-low and not none.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The static consumer scan is blind to base+offset addressing, which is how
register blocks are normally reached. Asking the question dynamically removes
that blind spot, so this harness traps every read/write in [0x21500,0x21B78]
across a full boot, three TA loads and six ring commands.
It reports zero reads and zero writes. That result is void, and the harness says
so and exits 1 rather than publishing it.
Two mandatory controls; the second caught the problem:
1. liveness -- the same hook saw 15,438,193 reads in a known-busy range (sOS
globals) from 197 PCs, so the hook itself works.
2. in-range -- a deliberately executed `ldr r1,[r0]` with r0 = 0x21500 must be
observed. It was not.
Isolated it with same-instruction, same-address, two machine states:
BEFORE boot : hook fired = True
AFTER boot : hook fired = False
After boot the MMU is configured, so window accesses are emitted at translated
addresses while the watcher watches 0x21500 as though identity-mapped. A real
consumer would be invisible to it.
Worth stating plainly: this is the third independent method to fail on this one
question -- the static scan (blind to base+offset), its positive control (taken
from a different firmware build), and now the dynamic watcher (wrong address
space). Each failed in a way that produced a confident, clean-looking answer.
The consumer question for Route C's window is genuinely open.
Next attempt must resolve the post-boot VA->PA mapping and watch the translated
addresses instead of assuming identity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Asked how "only one consumer" was established, and the honest answer is that it
was not. Recording the correction rather than defending the number.
The scan saw only addresses appearing whole -- 32-bit literals and MOVW/MOVT
immediates -- across two images. Register blocks are normally accessed as base +
immediate offset, where the full address never appears in the image at all, so
the detector is structurally blind to the exact access pattern this window's
nature would predict.
Tested for that rather than speculating. Scanning for values usable as a base
with a 12-bit offset finds six candidates, one of which covers the entire
window:
sOS 0x021000 (covers the WHOLE window) at FA 0x168ca
SYS_DRV 0x020d04, 0x020d1c, 0x020d5c, 0x020e30, 0x020f49
Trying to resolve the sOS candidate produced a region that does not decode as
code at the offset the scan assumed, which further means the scan's address
model for sOS is itself unverified.
Two other weaknesses stated plainly: the control set was effectively N=1, since
one of the two positive controls failed and its build-mismatch explanation is
evidence-backed but post-hoc; and coverage was 2 images, excluding the boot ROM,
earlier bootloader stages and every TA.
So "firmware references 3 of 415 dwords" must be read as "3 whole-address
references in 2 images, with 6 unresolved indexable bases and an unverified
address model". The bounded-low impact rating rested on that count and is
downgraded to provisional in the register. The capability itself is unaffected
and remains confirmed on hardware.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow-up to identifying the window as PSP-internal physical space. Scanned sOS
and SYS_DRV for literals and MOVW/MOVT immediates landing in [0x21500,0x21B78]:
0x215C0 <- bl_main+0x12 and +0x1a (sOS bootloader) the boot-stage register
0x21B40 <- literal at 0xE100AC in SYS_DRV handler's own fixup
0x21B50 <- literal at 0xE100A8 in SYS_DRV handler's own fixup
3 of 415, and two of those three are the handler's own special cases, which
VULN-LOADIPFW-UNSIGNED-REGWRITE.md already documents as getting firmware-chosen
values rather than the host's. The only address firmware genuinely uses is
0x215C0, and its user is the bootloader's bl_main, which runs before SYS_DRV
exists.
Control correction worth recording. The scan's first positive control was
0x2161C, because the vuln doc records bl_set_boot_stage writing it. The scan did
not find it -- and that is not a broken scan: in OUR build bl_set_boot_stage is
28 bytes at FA 0x159E0 and references neither address. The doc's description
came from a different firmware version, the same mismatch that made the v53
symbol map unusable for the TSU subsystem. The working cross-check is
0x21B40/0x21B50, independently documented and found.
So the register entry moves from "capability real, impact unestablished" to
"capability real, impact bounded-low", with the standing caveat that consumers
in hardware or in code we do not hold cannot be excluded by scanning the images
we have. That caveat is why it is bounded-low rather than none.
|
|
|
VULN-LOADIPFW-UNSIGNED-REGWRITE.md has carried "capability real, impact
unestablished" because nobody could say what [0x21500,0x21B78] is, and the VCN
hypothesis was refuted on hardware. Settled it from the firmware instead.
Mechanism: Route C's writes go through SVC 0x7C, which resolves addresses via
sOS's vawin_map_fixed (FA 0x3D8C). That splits the argument into
(addr >> 16) & 0xFFF0 -- a VA-window register -- and addr & 0xFFFFF, a 20-bit
offset. So the address is a PSP-INTERNAL PHYSICAL address mapped a megabyte at a
time, not a host SMN address. That is why every attempt to read 0x21xxx over the
host SMN aperture mirrored.
Access control: vawin_map_fixed gates on sos_check_va_window_request (FA 0x6D20).
Called directly in the emulator with controls:
Route C 0x21500, 0x21B78 -> 0 ALLOWED
protected 0x3700000/0x3780000 -> 0xa rejected
protected 0x3900000 -> 0xa rejected
just below/above range 1 -> 0 allowed
addr+size overflow -> 0xa rejected
The controls establish the protection is real, its boundaries are exactly
[0x3700000,0x3800000) and [0x3900000,0x3A00000), and the overflow guard fires.
It simply does not cover 0x21xxx.
The window holds at least the bootloader's own boot-stage registers --
bl_set_boot_stage writes 0x215C0 and 0x2161C through the same mechanism.
So the rating moves from "unidentified" to "PSP-internal physical space,
unprotected by the VA-window access control, containing bootloader boot-stage
state". Impact is still not established: what the other registers in those 1656
bytes do remains unknown, and the original "nothing reads them" scan covered
only the images we hold. Next question recorded and narrowed accordingly.
|
