> Otherwise— if unsigned code runs before updates— the unsigned code will have been modified by the attacker, it will execute a kernel exploit, and the exploit will undermine the update process— not just DOS it but make it look successful while keeping the machine compromised.
Not if the update process is sane. The unsigned code connects to the Internet, downloads the signed update, and stores it somewhere the boot code can access. You then reboot into a known-good state, and the signed and validated boot code checks the signature on the update and, if the signature is valid, applies it. The kernel never has write access to the secure boot parameters, so a kernel exploit can't undermine the update process beyond blocking the update.
To address that case, when the last valid update becomes too old the system can refuse to boot in secure mode, which should be fairly noticeable. A less drastic measure would be for the secure code to simply report the release date of the last update on startup, though that requires you to trust your display path.