AXP-Resurection/docs/hardening-backlog.md

# Hardening backlog (non-normative)

Candidate hardening ideas for later evaluation. **Not requirements** until a row
is promoted into an active feature `spec.md` (`012` / `013` or related).

Authority order for an active feature:

1. Constitution
2. That feature's `spec.md`
3. This backlog / `docs/axp-pro-parity.md` (hints only)

Status: `candidate` | `investigate` | `accepted→spec` | `rejected` | `los-provides`

## Privacy / identifiers

| Idea | Notes | Status |
|------|-------|--------|
| SUPL IMSI/MSISDN exposure | Reduce carrier ID leakage via SUPL | candidate |
| Build.SERIAL restrictions | Identifier privacy | candidate |
| Analytics / statistics removal | Drop unused telemetry | candidate |
| Package query visibility | Tighten package visibility | candidate |
| MAC / address privacy | Wi-Fi/BT randomization policy | candidate |
| Private DNS defaults | Sensible defaults without breaking banks | candidate |
| CA-store review | Trust anchors audit | candidate |

## Userspace

| Idea | Notes | Status |
|------|-------|--------|
| hardened_malloc | Graphene/AXP portability on sunfish | candidate |
| Bionic hardening | Selective, attributable | candidate |
| JNI protections | Safer JNI boundaries | candidate |
| Stack canaries | Confirm / strengthen where applicable | candidate |
| ptrace / Yama | Restrict debugging attach | candidate |
| seccomp | Incremental filter improvements | candidate |
| noexec / nosuid / nodev mounts | Where applicable without breaking HW | candidate |
| Dynamic code / JIT restrictions | Evaluate app compatibility cost | candidate |
| Exec spawning / ASLR-related | Attack-surface reduction | candidate |

## Kernel

| Idea | Notes | Status |
|------|-------|--------|
| Historical GrapheneOS sunfish kernel patches/config | Device-specific commits **and** config known to have run on sunfish — not CONFIG-only review | candidate |
| Modern GrapheneOS kernel techniques | Evaluate equivalent/backport on sunfish 4.14; no blind cherry-picks | candidate |
| AXP/DivestOS sunfish kernel patch audit | Identify AXP-owned vs inherited vs upstream; de-duplicate against LOS | candidate |
| Applicable CVE backports | Document EOL firmware vs patchable kernel | candidate |
| CFI | Feasibility on 4.14 | candidate |
| ASLR config | Kernel/userspace related knobs | candidate |
| IPv6 privacy | Address generation / exposure | candidate |
| Debug / UART restrictions | Reduce attack surface | candidate |
| Attack-surface reduction | Drop unused drivers/configs carefully | candidate |

## Kernel hardening source policy

The kernel base remains the LineageOS 23.2-compatible sunfish kernel.

```text
                         ┌─ historical GOS sunfish
                         │
LOS23/A16 sunfish 4.14 ←─┼─ AXP own + DivestOS
      OUR BASE           │
                         ├─ modern GOS techniques
                         │
                         └─ original upstream fixes
```

**Not:** GrapheneOS Android 13 (or any old GrapheneOS) kernel tree as our base.

Candidate hardening comes from four classes:

1. **Historical GrapheneOS sunfish** — device-specific patches/configuration known
   to have run on sunfish (real commits, not only `.config`).
2. **AXP.OS / DivestOS sunfish** — audit the actual patch stack; distinguish
   AXP-owned changes from inherited changes.
3. **Modern GrapheneOS** — use current kernel hardening as a source of
   techniques/security properties; adapt/backport only where feasible on
   non-GKI Linux 4.14; do not assume current Pixel kernel patches cherry-pick
   cleanly.
4. **Original upstream** — where a GrapheneOS/AXP/Divest patch derives from AOSP,
   Android common, Linux stable, or another upstream source, prefer the
   appropriate original upstream fix when practical.

For each candidate record:

- security problem / property;
- original source and commit;
- source lineage / provenance;
- sunfish-specific or generic;
- already present in LOS 23.2?;
- already present through another patch?;
- kernel/hardware prerequisites;
- applicability to Linux 4.14;
- port/backport required;
- compatibility/regression risk;
- test result;
- final decision.

## Much later / evaluate

| Idea | Notes | Status |
|------|-------|--------|
| Per-app network control | High UX/complexity | candidate |
| Sensors permission model | Graphene-like | candidate |
| Storage Scopes-like behaviour | Compatibility cost | candidate |
| Contact Scopes-like behaviour | Compatibility cost | candidate |
| Duress PIN/password | Later | candidate |
| USB restrictions | Policy toggles | candidate |
| Exploit-protection toggles | User-facing switches | candidate |
| Modernize LOS API deprecations / Kotlin annotation targets | **Final-ROM hygiene (last steps)**, not a mid-feature gate. Measured on `005` bacon 2026-09-15 SUCCESS (~45k log lines): ~3k deprecated, ~4.5k KT-73255 annotation-target, ~8.7k “warning” hits total; **0** hard `error:`/`FAILED:` in successful run. Themes: Settings Slices `[removal]`; SystemUI KeyguardState/SceneContainer/CommunalScenes; DesktopMode desk APIs; `FingerprintManager`/`Executors`; SettingsLib `@StringRes` KT-73255. Fix **API-by-API** with attributable ports; never megapatch or `-Xlint:-deprecation` as “done”. Prefer waiting for LOS merges; only port what still warns at freeze. Own patches (`005` spoofing, vendor) must stay clean first. Evidence: `/srv/rom/artifacts/005-spoofing/20260915-bacon/bacon-log-triage.md`. | candidate |

## EOL firmware caveat (for `013`)

sunfish is EOL. The project can modify kernel/framework we build, but cannot
fabricate new proprietary vendor/modem firmware. Document clearly:

- security patches we can backport in-tree;
- old proprietary firmware/baseband/vendor images we **cannot** fix;
- do not claim hardware protections unsupported by Pixel 4a.