docs: add TPM + Secure Boot planned fix for magicman keyboard issue

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/magicman-keyboard-luks.md

@@ -97,11 +97,59 @@ when udev re-processes devices) re-enables the keyboard.
 - Checked BIOS settings — no relevant keyboard/PS/2 options available
 - `fwupdmgr get-updates` shows no newer BIOS version available
 
-## Potential Future Fixes
+## Planned Fix: TPM + Secure Boot Auto-Unlock
+
+### Approach
+
+Use TPM2-based LUKS unlock with Secure Boot to bypass the keyboard requirement entirely.
+
+- **lanzaboote** — replaces systemd-boot, produces signed Unified Kernel Images (UKIs)
+  that bundle kernel + initrd + cmdline into a single signed EFI binary
+- **Secure Boot** — ensures only signed code can boot, prevents tampering with boot chain
+- **TPM2 unlock** — `systemd-cryptenroll` binds LUKS key to TPM PCR 7 (Secure Boot policy)
+- **Passphrase kept as fallback** — if TPM/Secure Boot state changes, unlock with USB keyboard + password
+
+### Why PCR 7 Only
+
+Binding to PCR 7 alone means kernel/initrd updates (frequent on nixos-unstable) do NOT
+require re-enrollment. PCR 7 only changes when Secure Boot keys or policy change.
+
+Cmdline tampering is prevented by lanzaboote's UKI approach — the cmdline is embedded in
+the signed binary and cannot be edited at the bootloader.
+
+### Setup Steps
+
+1. Install `sbctl` and create Secure Boot signing keys
+2. Put BIOS into Secure Boot "Setup Mode" and enroll custom keys (include Microsoft keys for fwupd)
+3. Enable lanzaboote in NixOS config (replaces systemd-boot)
+4. Rebuild, verify Secure Boot works
+5. Enroll TPM with `systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7`
+
+After setup, `nixos-rebuild switch/boot` works as usual — lanzaboote automatically signs
+each new generation.
+
+### Security Considerations
+
+**Protected against:**
+- Offline disk read (pull SSD, boot USB)
+- Boot chain tampering (unsigned code won't boot)
+- Cmdline editing (locked into signed UKI)
+
+**Remaining attack surface:**
+- Stolen while suspended — disk is decrypted in RAM, only screen lock protects.
+  Consider hibernate instead of suspend (hibernate locks LUKS since RAM is powered off).
+- Network services — system is fully running after boot, exposed services are reachable
+- DMA attacks via Thunderbolt/PCIe — mitigated by IOMMU (should be on by default)
+- Cold boot attacks — exotic, requires freezing RAM
+
+For a stolen-laptop scenario this is solid. The biggest practical risk is theft while
+the laptop is suspended.
+
+### Other Considered Alternatives
 
 - **BIOS update from Lenovo** fixing the PS/2 controller init sequence
-- **Kernel patch** to handle the failed enable more gracefully (e.g., not sending deactivate before enable)
+- **Kernel patch** to handle the failed enable more gracefully
-- **TPM-based LUKS unlock** to bypass the keyboard requirement entirely (trade-off: weaker theft protection unless combined with PIN)
+- **TPM + PIN** — not viable due to the same PS/2 keyboard issue at the PIN prompt
 
 ## Current Workaround