eternaltyro / cryptsetup

Since Google code is shuttering...
http://code.google.com/p/cryptsetup
GNU General Public License v2.0
0 stars 0 forks source link

Unreliable Keyboard Response During Keyscript Execution #152

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Setup keyscript with anything that echos keypresses (like keyscript below)
2. Point to keyscript in /etc/crypttab (SEE /ETC/CRYPTTAB BELOW)
3. Update-initramfs -u and restart (/boot partition mounted from a USB drive)

What is the expected output? What do you see instead?
The first script execution should work smoothly.  However, on subsequent 
executions from a soft reboot or cold restart (e.g. if you restart via 
CTRL+ALT+DEL during the script), keyboard response is no longer granted.  Also, 
sometimes during the first execution, keyresponse is echoed every other stroke, 
and sometimes every other other stroke.  The keyscript provided is only to test 
keyboard response reliability here for ease.  My actual keyscript is different.

What version of the product are you using? On what operating system?
OS - UBUNTU 12.04
CRYPTSETUP - 1.4.1

Please provide any additional information below.
Purpose: keyboard response is needed to input passphrase which unlocks a luks 
encrypted volume on a USB keydrive (removable in order to prevent "maid attack" 
to prevent someone from simply substituting a toyed boot partition to capture 
passphrase on next reentry)).  Unlocking the luks encrypted volume then allows 
pass of a keyfile to HDD luks volume holding OS in a lvm logical volume (would 
like both passphrase and physically removable keyfile with boot partition 
required to unlock system encryption). I have gotten everything to work so far 
except for the reliability in the keyboard response. Your help, advice, or any 
toeing would be greatly appreciated as I have been struggling with the 
reliability resolution for about a week.

CONFIGURATIONS:

Computer:
Toshiba Satellite Laptop L775-S7248

`uname -a`:
Linux ZaFu 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:15:33 UTC 
2013 i686 i686 i386 GNU/Linux

/etc/initramfs-tools/modules:
aes-i586
dm-crypt
dm-mod
sha256
sd_mod
scsi_mod
usb-storage
ehci_pci
usb_core
usb_common
xhci_hcd
uhci_hcd
ehci_hcd
ohci_hcd
usbhid
hid_generic

/etc/crypttab:
pvcrypt                 /dev/sda2       key.iso         
luks,keyscript=/usr/local/sbin/cpboot

KEYSCRIPT:

#!/bin/sh
#  sleep used to give time to shift to "console" (?) screen to view stderr
#+ since keyboard will be taken over by script 
sleep 5
password=
echo "TYPE:" >&2
while true; do
        stty -icanon -echo
        char=`dd bs=1 count=1 2>/dev/null`
        stty icanon echo
        case $char in
        '') break ;;
        *)echo -n '*' >&2 ;;
        esac
        password=$password$char
done

echo $password

Original issue reported on code.google.com by surfe...@gmail.com on 20 Mar 2013 at 7:56

GoogleCodeExporter commented 9 years ago
Handling od /etc/crypttab is not part of upstream cryptsetup (it is processed 
either by initcripts or systemd generator helper - depends on distro).
(And this init sequence should ensure that keyborard is ready before reading 
input. If you see it here I think the same problem must be in base distro 
scripts.)

So please report this to distro bugzilla (launchpad for Ubuntu), I cannot do 
anything here - the code running keyscript is not part of upstream codebase.

Anyway - if you have USB keyboard, I saw similar problem several times. Perhaps 
adding some usb related modules into initramfs (to force usb init early) and 
few seconds sleep (which is already there :-) could help...
Also maybe try to add udev settle command (udevadm settle) which ensures it is 
not running in parallel with device initialization.

Original comment by gmazyl...@gmail.com on 20 Mar 2013 at 5:33

GoogleCodeExporter commented 9 years ago
Thanks for the response :)  I saw the USB keyboard issue as well, but don't
think my native keyboard is usb connected (hmm...), but added a lot of usb
and usb hid modules anyway, which didn't work. I will go bug bugzilla then
and try the udevadm settle.  Happy hacking!

Original comment by surfe...@gmail.com on 21 Mar 2013 at 1:02