Recent discussion in IRC suggests that there's no timeout. If the computer is unattended when the prompt appears, or if the user is interrupted before completing entry of the passphrase/password, then the prompt may be endless: * with a risk of 'burn' to some types of display. I suggest a timeout of five minutes, after which the computer should automatically shut down. (The period that applies with FileVault 2 on OS X is probably five minutes.)
From IRC: > which modern types of screen actually burn anyway? Screen types aside, for a moment: an endless prompt may be undesirable in other situations. A notebook drawing power from a battery, for example.
Making some notes: sys/geom/eli.c:g_eli_taste(...):ln1147, calls cngets(...) to retrieve passphrase. sys/kern/kern_cons.c:cngets(...):ln423, implementation of cngets(...) Will probably need an alternate implementation of cngets() which does timekeeping to implement this feature request. Will do more research on this soon. I suggest the exact time to wait to be defined in a loader tunable, and that the default setting should probably be around 10 minutes. Enough to grab a cup of coffee/tea/other between powering on and entering passphrase, and little enough to not drain battery too much. I don't have an opinion whether the feature as a whole should be enabled by default.
I'm sorry to be repeatedly negative here, but I really don't think the case is made here strongly enough. Do we do anything by default at the login screen too? I think this is a POLA violation, and the nonexistent risk of screen burn (actually takes years anyway on a CRT) and battery drain just don't justify this for me. Please ensure this is off by default if implemented.
It is unfortunate that in the legacy boot case, the password prompt runs the CPU at 100% doing nothing but waiting for you to type the passphrase, but there isn't much that can be done about it. UEFI support is coming soon, and maybe that'll be gentler on your battery.