# Magicman: PS/2 Keyboard Broken at LUKS Prompt After BIOS Update

## Issue

After updating the ThinkPad L14 Gen 4 (21H2S3US00) BIOS to version R24ET51W (1.34)
via `fwupdmgr`, the built-in laptop keyboard no longer works during the LUKS disk
encryption password prompt. An external USB keyboard must be used to unlock the disk.
The laptop keyboard works normally after boot.

## Machine Details

- **Model**: Lenovo ThinkPad L14 Gen 4 (21H2S3US00)
- **BIOS**: R24ET51W (1.34), dated 2025-10-31
- **EC**: R24HT33W
- **Date**: 2026-03-06

### What fwupdmgr Installed

- System Firmware: 0.1.12 → 0.1.34
- UEFI dbx: 20230301 → 20250902
- KEK CA: 2011 → 2023

## Symptoms

- Laptop keyboard does not respond at the LUKS password prompt (neither systemd nor scripted initrd)
- USB keyboard works fine at the LUKS prompt
- Laptop keyboard works immediately after boot (at greetd login)
- Text typed on the laptop keyboard during LUKS prompt sometimes partially appears
  at the greetd username field after boot, indicating the keyboard hardware IS generating
  scancodes that get buffered and flushed later

## Kernel Errors

Every boot shows these errors from the atkbd driver:

```
atkbd serio0: Failed to deactivate keyboard on isa0060/serio0
atkbd serio0: Failed to enable keyboard on isa0060/serio0
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
```

The keyboard device IS registered despite the errors, and the `kbd` input handler
binds to it (`Handlers=sysrq kbd leds event6`).

## Root Cause Analysis

The BIOS update changed the PS/2 controller (i8042) initialization behavior. The atkbd
driver sends a deactivate command (0xF5) during init, which likely succeeds at disabling
the keyboard even though the ACK times out. The subsequent enable command (0xF4) also
times out without re-enabling it. The keyboard stays disabled at the hardware level —
it queues keypresses in its small internal buffer (~16 keys) but doesn't send scancodes
to the host until something re-enables it during full boot. This is NOT a timing issue —
leaving the system at the LUKS prompt for several minutes does not fix the keyboard.
Something specific that happens later in the boot process (likely during switch-root
when udev re-processes devices) re-enables the keyboard.

## What Was Tried

### Kernel Parameters (none helped)

- `i8042.dumbkbd` — skip keyboard reset during i8042 probe
- `i8042.nopnp` — don't use PNP to discover controllers
- `i8042.reset` — force i8042 controller reset
- `i8042.nomux` — don't probe for MUX
- `atkbd.reset` — reset keyboard during atkbd init
- `console=tty1` — explicitly route console I/O to tty1
- Various combinations of the above

### Initrd Module Loading

- Added `i8042`, `atkbd`, `thinkpad_acpi` to `boot.initrd.kernelModules`
- `thinkpad_acpi` loads the EC driver early, but didn't help

### Initrd Services

- Created `keyboard-reconnect` systemd service that runs before `systemd-cryptsetup@root.service`
- Tried `echo reconnect > /sys/bus/serio/devices/serio0/drvctl` — reconnect also fails
- Tried full module reload: `rmmod atkbd; rmmod i8042; sleep N; modprobe i8042; modprobe atkbd`
  - Tested with sleep 2 and sleep 8
  - The reload creates a new serio device (serio2) but initialization fails identically

### Plymouth

- Disabled Plymouth (`boot.plymouth.enable = false`) — no effect
- Tested `plymouth.enable=0` on kernel command line — no effect
- Confirmed password agent falls back to `systemd-tty-ask-password-agent` on `/dev/tty1`

### Scripted Initrd

- Switched from systemd initrd to scripted initrd (`boot.initrd.systemd.enable = false`)
- Uses a completely different password prompt mechanism (shell `read`)
- Same result — keyboard still doesn't work

### BIOS

- Checked BIOS settings — no relevant keyboard/PS/2 options available
- `fwupdmgr get-updates` shows no newer BIOS version available

## 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
- **TPM + PIN** — not viable due to the same PS/2 keyboard issue at the PIN prompt

## Current Workaround

Use an external USB keyboard to enter the LUKS password at boot.