Bug 242349 - keymap support before disk decryption
Summary: keymap support before disk decryption
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.1-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-02 04:39 UTC by Christer Edwards
Modified: 2019-12-10 07:48 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christer Edwards 2019-12-02 04:39:31 UTC
Alternate keyboard layouts need to be loaded prior to disk decryption if encryption enabled.

During installation (12.1-RELEASE) I select the us.dvorak.kbd layout, which is enabled in the rc.conf (keymap="us.dvorak.kbd") as expected. I also enabled disk encryption, which unlocks with a passphrase at boot.

The problem is each time the machine bots the kernel reverts the keymap and I am required to unlock disk encryption using the US qwerty layout.

-----

The only solution I found was to build a custom kernel and define the following:

options        ATKBD_DFLT_KEYMAP
makeoptions    ATKBD_DFLT_KEYMAP=us.dvorak
Comment 1 Olivier Cochard freebsd_committer 2019-12-02 22:59:49 UTC
Another method to fix this layout limitation for installation done with bsdinstall:
If user selects another layout than QWERTY (BIOS default), instruct bsdinstall to switch to use QWERTY layout just during the GELI password input screen.
=> The user will enter twice its password, but in fact because the layout was not the user defined but QWERTY, the real entered password will be the one corresponding the QWERTY layout.
So during the bootloader GELI password phase (that will use BIOS default QWERTY), the sequence of keys entered by the user will still match the 'QWERTY' password used during bsdinstall.
Comment 2 Christer Edwards 2019-12-03 19:38:39 UTC
Update: I just build a kernel with these options on 13-CURRENT:

device         atkbd
options        ATKBD_DFLT_KEYMAP
makeoptions    ATKBD_DFLT_KEYMAP=us.dvorak.kbd

These instructions don't seem to have any affect.
Comment 3 Loïc Bartoletti freebsd_committer 2019-12-04 14:26:05 UTC
(In reply to Olivier Cochard from comment #1)
Is this method will work for every type of keyboard? Especially laptop and password with special character? Just asking.
Comment 4 Ed Maste freebsd_committer 2019-12-04 15:32:45 UTC
(In reply to Loïc Bartoletti from comment #3)
> Is this method will work for every type of keyboard? Especially laptop and password with special character? Just asking.

I believe it should. It is possible that this scheme could result in weaker passwords (e.g. a keypress used in the password could from a character to a control key); I'm not sure how likely that is in practice. This wouldn't affect us.dvorak.kbd at least, I believe.
Comment 5 Christer Edwards 2019-12-04 15:41:09 UTC
Admittedly I'm less familiar with the FreeBSD kernel but that feels like a workaround...

Is there no capability similar to Linux initrd? To bootstrap key modules very early?
Comment 6 Ed Maste freebsd_committer 2019-12-05 00:47:44 UTC
(In reply to Christer Edwards from comment #5)
Indeed, this approach would be a bit of a workaround. We can and do load modules early, but keyboard maps aren't modules.

It would be possible to boot with a md root a la linux initrd and do keymap configuration from there, but is a rather more significant change, and still wouldn't handle the case where we collect the password/phrase from the loader.