Bug 240760
| Summary: | Caps lock key became a character in GELI passphrase entry after upgrading to 12.0 w/root-on-ZFS | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Ariel Millennium Thornton <arielmt> | ||||
| Component: | kern | Assignee: | Toomas Soome <tsoome> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | imp, kevans, salvadore, sigsys, tsoome | ||||
| Priority: | --- | Keywords: | regression | ||||
| Version: | 12.0-RELEASE | ||||||
| Hardware: | amd64 | ||||||
| OS: | Any | ||||||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242349 | ||||||
| Attachments: |
|
||||||
|
Description
Ariel Millennium Thornton
2019-09-23 07:10:22 UTC
Hi, Follow up questions: - Is this a separate, unencrypted bootpool setup? - geom_eli_passphrase_prompt="YES" in /boot/loader.conf? I have a separate pool called bootpool, and I assume it's unencrypted. I'm too ignorant of ZFS management to be 100% confident. According to `zpool status`, it's also ada0p3 (no .eli), and according to `zfs list`, it mounts on /bootpool. The root pool, zroot, is ada0p5.eli, and zroot/ROOT/default mounts on /. When booting with what the system thought was a bad passphrase, it was only ada0p5 it asked me for. My /boot/loader.conf file wasn't changed during the upgrade, and it has a `geom_eli_passphrase_prompt="YES"` line. New information: The caps lock key can be used, but backspace must be pressed once right after pressing caps lock. Created attachment 207941 [details]
git(1) diff against /boot/lua/password.lua
Hi,
Please try this patch against /boot/lua/password.lua.
The patch had no effect on passphrase input, both at the boot-time prompt and when asked for ada0p5's passphrase while the kernel booted up. The patch also had no effect on the boot-time display: The keypress spinner advanced with each press of caps lock. Recently SHIFT also became (at least) a character: whenever I try to insert a capital letter by pressing the SHIFT key I see the bar indicating character insertion rotating full speed and of course the password is inserted wrong. The problem is present in 12.1-STABLE r354066 but was not there in 12.1-STABLE r353430. (In reply to Lorenzo Salvadore from comment #6) Is this defect on BIOS or UEFI system? If it is UEFI, please run from loader OK prompt: chain /boot/loader_4th.efi - does it still have the defect? If this is BIOS system, does the defect appear with boot1 or loader? That is, if you enter the password and press the space when there is spinner, does boot: prompt appear? On boot: prompt, enter /boot/loader_4th and does the defect appear there? It would be helpful to know exactly where the issue does appear. (In reply to Toomas Soome from comment #7) I'm on a UEFI system. I was unable to run the test you suggested: SHIFT is broken in the ok prompt too, so that I cannot insert the needed underscore. Whenever I press SHIFT I cannot add any character to the line I'm writing and only terminating it by pressing ENTER gets the prompt working again. CAPSLOCK works as expected on the ok prompt but does not for the GELI password insertion: it inserts a dummy character as described in comment #3. (In reply to Lorenzo Salvadore from comment #8) please try this patch and please report me back the output: Index: stand/efi/libefi/efi_console.c =================================================================== --- stand/efi/libefi/efi_console.c (revision 355225) +++ stand/efi/libefi/efi_console.c (working copy) @@ -1112,6 +1112,9 @@ if (status == EFI_SUCCESS) { kss = key_data.KeyState.KeyShiftState; kp = &key_data.Key; + printf("kts: %x kss: %x scan: %x unicode: %x\n", + key_data.KeyState.KeyToggleState, kss, + kp->ScanCode, kp->UnicodeChar); if (kss & EFI_SHIFT_STATE_VALID) { /* @@ -1126,10 +1129,11 @@ kp->UnicodeChar++; } } + if (kp->ScanCode == 0 && kp->UnicodeChar == 0) + return (false); + keybuf_inschar(kp); + return (true); } - - keybuf_inschar(kp); - return (true); } return (false); } (In reply to Toomas Soome from comment #9) I tested your patch on 12.1-STABLE r355326. Here are some outputs. Feel free to ask for more. - pressing SHIFT with CAPSLOCK off: kts: c0 kss:80000001 scan: 0 unicode: 0 - pressing SHIFT with CAPSLOCK on: kts: c4 kss:80000001 scan: 0 unicode: 0 - switching CAPSLOCK from off to on: kts: 80 kss:80000000 scan: 0 unicode: 0 - switching CAPSLOCK from on to off: kts: 84 kss:80000000 scan: 0 unicode: 0 (In reply to Lorenzo Salvadore from comment #10) ok, This output is expected, but is the input working now? (In reply to Toomas Soome from comment #11) Sorry, I had forgotten to test the input itself. Yes, it works now. Thank you very much. A commit references this bug: Author: tsoome Date: Tue Dec 3 18:36:39 UTC 2019 New revision: 355347 URL: https://svnweb.freebsd.org/changeset/base/355347 Log: loader: ReadKeyStrokeEx may return partial keystrokes In some systems we can receive no scancode nor unicodechar values. PR: 240760 Reported by: Ariel Millennium Thornton MFC after: 1 week Changes: head/stand/efi/libefi/efi_console.c A commit references this bug: Author: tsoome Date: Mon Dec 9 21:10:18 UTC 2019 New revision: 355571 URL: https://svnweb.freebsd.org/changeset/base/355571 Log: MFC r355347: loader: ReadKeyStrokeEx may return partial keystrokes In some systems we can receive no scancode nor unicodechar values. PR: 240760 Reported by: Ariel Millennium Thornton Changes: _U stable/12/ stable/12/stand/efi/libefi/efi_console.c (In reply to Ariel Millennium Thornton from comment #0) Ariel, is this issue fixed for you? (In reply to Toomas Soome from comment #15) I'm afraid not. I just upgraded to 12.0-RELEASE-p12, and the issue is still present. (In reply to Ariel Millennium Thornton from comment #16) I wonder if you could test stable/12, I am not sure about what patch is included in p12... I have not been vigilant with this bug. Sorry about that. I am currently on the same PC and upgraded to FreeBSD version 12.2-RELEASE-p2, and this bug appears no longer present. I can enter the capital letters in my GELI passphrase with caps lock on again. I don't know which version or patch level the bugfix is in, but I was never able to test on STABLE, only on RELEASE. It's between these versions: 12.0-RELEASE-p12: bug was present 12.2-RELEASE-p2: bug is not present ^Triage: Assign to committer resolving and close the bug report |
