When utilizing the bootlock_password feature of loader.conf(5) (see check-password.4th(8) for additional details) introduced in FreeBSD 9.2-RELEASE, if you set a password that exceeds 16 characters in length, the system cannot be booted since check-password.4th does a comparison between the full contents of $bootlock_password and the 16-byte-max user input. check-password.4th should instead truncate the loader.conf(5) variable contents to the maximum allowable length prior to comparison against user-input. This would allow a system to boot if the user is knowledgable of the input limit while the loader.conf setting exceeds maximum user-input -- the alternative being that you absolutely must use a LiveCD to recover from the situation of innocuously setting a value that is greater than 16 characters in length. NB: An enhancement coming soon will increase the maximum length to 255 characters which will make it less likely that folks will hit this -- but despite that, the solution of making a truncated comparison will alleviate the situation of making an unbootable system unintentionally.
A commit references this bug: Author: dteske Date: Mon Mar 23 16:31:28 UTC 2015 New revision: 280383 URL: https://svnweb.freebsd.org/changeset/base/280383 Log: Prevent password/bootlock_password features of loader.conf(5) from locking out everyone in the case of setting a password longer than the maximum (currently 16 characters). Now the required password is truncated to the maximum input that can be read from the user. PR: kern/198760 MFC after: 3 days MFH: stable/10 stable/9 Changes: head/sys/boot/forth/check-password.4th
As previously mentioned: Upping the input limit from 16 to 255 https://svnweb.freebsd.org/changeset/base/280384
Will close after MFC or related commits: https://svnweb.freebsd.org/changeset/base/280383 https://svnweb.freebsd.org/changeset/base/280384 X-MFC-to: stable/10 stable/9 (for both r280383 and r280384)
To originators/assignees of this PR: A commit to the tree references this PR, however the PR is still in a non-closed state. Please review this PR and close as appropriate, or if closing the PR requires a merge to stable/10, please let re@ know as soon as possible. Thank you. Glen
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Merged to stable/10 3 years ago (svn r281843) stable/9 is still affected and the PR originally filed against 9.2-RELEASE. However, there won't be a new release on stable/9 as far as I'm aware of. Closing as fixed. If anyone is likely to upgrade they will probably upgrade past stable/9