CONFIG_AUTOBOOT_KEYED: the fix for the "Hit any key" prompt

The mitigation for the interruptable-autoboot exposure is not just increasing the countdown timer: a scripted attacker with a serial cable and a printf '\r' loop defeats any countdown length. The real fix is switching from "any keypress" to "specific key sequence" via U-Boot Kconfig.

The relevant options:

• `CONFIG_AUTOBOOT_KEYED=y`: enable keyed autoboot interrupt. When set, U-Boot ignores random keypresses and only checks for a specific stop-string.
• `CONFIG_AUTOBOOT_STOP_STR="..."`: the exact string that must be typed at the console within the countdown window to stop autoboot. A typical vendor build uses something non-trivial like "MyVendor2024" or a hex sequence.
• `CONFIG_AUTOBOOT_DELAY_STR="..."` (optional pair): a preamble string that must precede the stop string. Raises the bar further against random-input attacks.

With both set, the attacker has to type the exact stop-string (and optional delay-string) in sequence within the countdown, in the correct order, without an intervening keystroke breaking the buffer. That's effectively impossible without knowing the strings.

A stronger option is CONFIG_BOOTDELAY=-2, which disables the autoboot prompt entirely: no interruption possible. This is the right choice for shipped consumer devices where operators never need shell access.

Trap for the defender: many vendor builds set CONFIG_BOOTDELAY=-2 but then re-enable a hidden shell via a separate mechanism: a bootmenu triggered by a 4-byte magic string on the serial input, a specific key combination held during power-on, or a private variable in NVRAM. If you're auditing a device that shows bootdelay=-2 behavior on the console, still probe for these vendor backdoors before declaring the device secure against UART-shell attacks.

The interruptable-autoboot blog post walks through the full attack path and mitigation options with 20 real captures from the sample corpus.