fabi/xenia-rs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(audit): mark P3 PPCBUGs applied; append P3 progress section

Browse Source 
P3 phase merged at f3ebaba. Update audit-findings.md status fields and
append the P3 progress section to audit-report-2026-04-29.md, including
the new PPCBUG-700 discovery (VMX128 register accessor canary-compliance).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
MechaCat02
2026-05-02 11:28:38 +02:00
parent f3ebaba5c9
commit f424132a5b
2 changed files with 35 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
audit-findings.md
View File

@@ -517,7 +517,7 @@ and severely thin test coverage (PPCBUG-055).
### PPCBUG-053 — CTR zero-test uses 64-bit compare; should use 32-bit in `bcx`/`bclrx`
- **Severity**: MEDIUM (effectively HIGH given unfixed PPCBUG-001..031 GPR pollution)
- **Status**: open
- **Status**: applied (3d8e2ce, 2026-05-02)
- **Locations**: `interpreter.rs:849` (`bcx` `ctr_ok`), `interpreter.rs:879` (`bclrx` `ctr_ok`)
- **Symptom**: `ctx.ctr != 0` compares all 64 bits. In 32-bit ABI the CTR is logically 32-bit.
Canary explicitly truncates to 32 bits: `ctr = f.Truncate(ctr, INT32_TYPE)`. When CTR upper
@@ -541,7 +541,7 @@ and severely thin test coverage (PPCBUG-055).
### PPCBUG-054 — `mtspr CTR` writeback not truncated to 32 bits
- **Severity**: MEDIUM
- **Status**: open
- **Status**: applied (3d8e2ce, 2026-05-02)
- **Location**: `interpreter.rs:1411`
- **Symptom**: `crate::context::spr::CTR => ctx.ctr = val` writes the full 64-bit GPR to CTR.
Acts as a firewall gap: any upstream 64-bit GPR pollution flows directly into CTR, where it
@@ -2602,7 +2602,7 @@ entries in decode_op6.
### PPCBUG-424 — vmaddfp128: operand swap — computes VA×VB+VD instead of VA×VD+VB
- **Severity**: HIGH
- **Status**: open
- **Status**: applied (52ece4b, 2026-05-02)
- **Location**: `interpreter.rs:1771` (`r[i] = ai.mul_add(bi, di)`)
- **Symptom**: Canary (ppc_emit_altivec.cc:806-809) documents `(VD) <- (VA × VD) + VB` and
routes as `MulAdd(VA, VD, VB)`. Xenia-rs reads VA, VB, VD then computes
@@ -2614,7 +2614,7 @@ entries in decode_op6.
### PPCBUG-425 — vmaddcfp128: operand swap — computes VD×VB+VA instead of VA×VD+VB
- **Severity**: HIGH
- **Status**: open
- **Status**: applied (52ece4b, 2026-05-02)
- **Location**: `interpreter.rs:4065` (`r[i] = di.mul_add(bi, ai)`)
- **Symptom**: Canary (ppc_emit_altivec.cc:819) documents `(VD) <- (VA × VD) + VB`.
Xenia-rs computes `VD × VB + VA`. Both the first multiplicand and the addend are wrong.
@@ -2850,7 +2850,7 @@ gap). **3 LOW** test-coverage gaps.
### PPCBUG-510 — `stvewx128` stores all 16 bytes instead of one word; 12-byte memory corruption (HIGH)
- **Severity**: HIGH
- **Status**: open
- **Status**: applied (cedee3c, 2026-05-02)
- **Location**: interpreter.rs:2776-2781
- **Symptom**: Uses `& !0xF` (16-byte alignment) then stores all 16 bytes of the vector.
ISA semantics: word-align EA, extract the word lane `(EA & 0xF) >> 2`, store 4 bytes only.
@@ -3240,7 +3240,7 @@ has the wrong extraction. The disassembler was written independently and got the
### PPCBUG-640 — `fmt_bc`: pure `bdnz`/`bdz` emits `bdnzge`/`bdzge` (spurious condition suffix) (HIGH)
- **Severity**: HIGH
- **Status**: open
- **Status**: applied (d4f6ea7, 2026-05-02)
- **Location**: `disasm.rs:829-834`
- **Symptom**: For `bcx` with BO=16 (`bdnz`: decrement CTR, branch if CTR≠0, CR ignored):
- `decr = (16 & 4) == 0` = true
@@ -3363,7 +3363,7 @@ has the wrong extraction. The disassembler was written independently and got the
### PPCBUG-649 — Golden fixture for `lwsync` pins wrong output (no ext_mnemonic) (LOW)
- **Severity**: LOW (test coverage gap)
- **Status**: open
- **Status**: applied (2be25bd, 2026-05-02)
- **Location**: `tests/golden/extended_mnemonics.json`, entry "lwsync"
- **Symptom**: Fixture has `mnemonic: "sync"` and no `ext_mnemonic`. After PPCBUG-088/641
fix, expected output is `mnemonic: "sync"`, `ext_mnemonic: "lwsync"`. Current fixture
@@ -3372,7 +3372,7 @@ has the wrong extraction. The disassembler was written independently and got the
### PPCBUG-650 — Golden fixtures for `bdnz`/`bdz` pin wrong extended mnemonic (LOW)
- **Severity**: LOW (companion to PPCBUG-640)
- **Status**: open
- **Status**: applied (d4f6ea7, 2026-05-02)
- **Location**: `tests/golden/extended_mnemonics.json`, rows "bdnz 0x82000040" and "bdz 0x82000040"
- **Symptom**: Both rows have `ext_mnemonic: "bdnzge"` and `ext_mnemonic: "bdzge"`.
After PPCBUG-640 fix, correct values are `"bdnz"` and `"bdz"`.