Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1016300 > unrolled thread
| Started by | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| First post | 2020-07-03 13:00 +0200 |
| Last post | 2020-07-06 19:20 +0200 |
| Articles | 13 — 2 participants |
Back to article view | Back to linux.debian.bugs.dist
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Vincent Lefevre <vincent@vinc17.net> - 2020-07-03 13:00 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Guilhem Moulin <guilhem@debian.org> - 2020-07-03 16:20 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Vincent Lefevre <vincent@vinc17.net> - 2020-07-04 00:30 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Guilhem Moulin <guilhem@debian.org> - 2020-07-04 00:40 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Vincent Lefevre <vincent@vinc17.net> - 2020-07-04 01:00 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Guilhem Moulin <guilhem@debian.org> - 2020-07-04 01:10 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Vincent Lefevre <vincent@vinc17.net> - 2020-07-05 12:20 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Guilhem Moulin <guilhem@debian.org> - 2020-07-05 16:40 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Vincent Lefevre <vincent@vinc17.net> - 2020-07-06 01:00 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Guilhem Moulin <guilhem@debian.org> - 2020-07-06 01:10 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Vincent Lefevre <vincent@vinc17.net> - 2020-07-06 02:00 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Guilhem Moulin <guilhem@debian.org> - 2020-07-06 02:40 +0200
Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase Vincent Lefevre <vincent@vinc17.net> - 2020-07-06 19:20 +0200
| From | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| Date | 2020-07-03 13:00 +0200 |
| Subject | Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase |
| Message-ID | <AorAd-2Lr-1@gated-at.bofh.it> |
Package: cryptsetup Version: 2:2.3.3-1 Severity: important I don't know really where the problem comes from, but it now takes one minute to unlock the disk of my laptop with a passphrase. Well, I'm not sure whether this comes from cryptsetup or something that comes just after it, but at least the fact that cryptsetup doesn't output any confirmation message doesn't help. Until June 30, this was always immediate, and nothing changed on my system. My laptop no longer has an Ethernet cable plugged in, so that this might make the difference (but this was working fine several months ago). Note that I've always had e1000e in /etc/initramfs-tools/modules. -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-5.7.0-1-amd64 root=/dev/mapper/zira--vg-root ro quiet -- /etc/crypttab sda5_crypt UUID=ef627f6a-4469-42c8-9b15-f26477969e7b none luks -- /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/zira--vg-root / ext4 errors=remount-ro 0 1 # /boot was on /dev/sda1 during installation UUID=7b3de7fd-236a-47f6-bb85-64831a06ca1f /boot ext2 defaults 0 2 /dev/mapper/zira--vg-swap_1 none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/sdb /media/mem auto user,noauto,noatime 0 0 /dev/sdb1 /media/mem auto user,noauto,noatime 0 0 -- lsmod Module Size Used by ctr 16384 2 ccm 20480 6 rfcomm 90112 4 ipt_REJECT 16384 3679 nf_reject_ipv4 16384 1 ipt_REJECT xt_multiport 20480 2 nft_compat 20480 3681 nft_counter 16384 3683 nf_tables 229376 11047 nft_compat,nft_counter nfnetlink 16384 2 nft_compat,nf_tables psnap 16384 0 cpufreq_conservative 16384 0 llc 16384 1 psnap cmac 16384 1 cpufreq_userspace 20480 0 cpufreq_powersave 20480 0 bnep 28672 2 intel_rapl_msr 20480 0 intel_rapl_common 32768 1 intel_rapl_msr iwlmvm 319488 0 btusb 57344 0 btrtl 24576 1 btusb btbcm 20480 1 btusb mac80211 905216 1 iwlmvm btintel 32768 1 btusb mei_wdt 16384 0 binfmt_misc 24576 1 libarc4 16384 1 mac80211 snd_hda_codec_realtek 131072 1 bluetooth 688128 31 btrtl,btintel,btbcm,bnep,btusb,rfcomm snd_hda_codec_hdmi 73728 1 snd_hda_codec_generic 94208 1 snd_hda_codec_realtek x86_pkg_temp_thermal 20480 0 intel_powerclamp 20480 0 ledtrig_audio 16384 2 snd_hda_codec_generic,snd_hda_codec_realtek iwlwifi 274432 1 iwlmvm coretemp 20480 0 uvcvideo 114688 0 snd_hda_intel 57344 5 snd_intel_dspcfg 24576 1 snd_hda_intel snd_hda_codec 163840 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek videobuf2_vmalloc 20480 1 uvcvideo videobuf2_memops 20480 1 videobuf2_vmalloc snd_hda_core 106496 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek intel_cstate 16384 0 drbg 28672 1 videobuf2_v4l2 28672 1 uvcvideo cfg80211 872448 3 iwlmvm,iwlwifi,mac80211 snd_hwdep 16384 1 snd_hda_codec ansi_cprng 16384 0 intel_uncore 163840 0 videobuf2_common 57344 2 videobuf2_v4l2,uvcvideo hp_wmi 16384 0 intel_rapl_perf 16384 0 snd_pcm 131072 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core videodev 266240 3 videobuf2_v4l2,uvcvideo,videobuf2_common joydev 28672 0 snd_timer 45056 1 snd_pcm iTCO_wdt 16384 0 mei_me 45056 1 serio_raw 20480 0 iTCO_vendor_support 16384 1 iTCO_wdt snd 106496 18 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm sparse_keymap 16384 1 hp_wmi tpm_infineon 20480 0 ecdh_generic 16384 2 bluetooth ecc 36864 1 ecdh_generic mxm_wmi 16384 0 pcspkr 16384 0 wmi_bmof 16384 0 sg 36864 0 mc 57344 4 videodev,videobuf2_v4l2,uvcvideo,videobuf2_common watchdog 28672 2 iTCO_wdt,mei_wdt rfkill 28672 6 hp_wmi,bluetooth,cfg80211 mei 122880 3 mei_wdt,mei_me soundcore 16384 1 snd ie31200_edac 16384 0 evdev 28672 28 tpm_tis 16384 0 tpm_tis_core 28672 1 tpm_tis tpm 73728 3 tpm_tis,tpm_infineon,tpm_tis_core hp_accel 28672 0 lis3lv02d 28672 1 hp_accel rng_core 16384 1 tpm button 24576 0 hp_wireless 16384 0 ac 16384 0 nvidia_drm 53248 1 drm_kms_helper 249856 1 nvidia_drm cec 61440 1 drm_kms_helper nvidia_modeset 1056768 3 nvidia_drm nvidia 15835136 156 nvidia_modeset ipmi_devintf 20480 0 ipmi_msghandler 73728 2 ipmi_devintf,nvidia parport_pc 28672 1 ppdev 24576 0 drm 606208 4 drm_kms_helper,nvidia_drm lp 20480 0 parport 61440 3 parport_pc,lp,ppdev ip_tables 32768 0 x_tables 53248 4 nft_compat,xt_multiport,ipt_REJECT,ip_tables autofs4 53248 2 ext4 778240 2 crc16 16384 2 bluetooth,ext4 mbcache 16384 1 ext4 jbd2 139264 1 ext4 crc32c_generic 16384 0 dm_crypt 49152 1 dm_mod 159744 9 dm_crypt sd_mod 57344 3 sr_mod 28672 0 cdrom 73728 1 sr_mod t10_pi 16384 1 sd_mod crc_t10dif 20480 1 t10_pi crct10dif_generic 16384 0 crct10dif_pclmul 16384 1 crct10dif_common 16384 3 crct10dif_generic,crc_t10dif,crct10dif_pclmul crc32_pclmul 16384 0 crc32c_intel 24576 2 ghash_clmulni_intel 16384 0 rtsx_pci_sdmmc 32768 0 mmc_core 184320 1 rtsx_pci_sdmmc xhci_pci 20480 0 xhci_hcd 290816 1 xhci_pci aesni_intel 368640 7 ahci 40960 2 libaes 16384 2 bluetooth,aesni_intel libahci 45056 1 ahci crypto_simd 16384 1 aesni_intel libata 286720 2 libahci,ahci cryptd 24576 3 crypto_simd,ghash_clmulni_intel glue_helper 16384 1 aesni_intel ehci_pci 20480 0 ehci_hcd 98304 1 ehci_pci psmouse 180224 0 e1000e 290816 0 scsi_mod 258048 4 sd_mod,libata,sg,sr_mod usbcore 315392 6 xhci_hcd,ehci_pci,uvcvideo,ehci_hcd,btusb,xhci_pci rtsx_pci 90112 1 rtsx_pci_sdmmc i2c_i801 32768 0 lpc_ich 28672 0 ptp 28672 1 e1000e mfd_core 20480 2 rtsx_pci,lpc_ich pps_core 24576 1 ptp usb_common 16384 4 xhci_hcd,usbcore,uvcvideo,ehci_hcd battery 20480 0 video 53248 0 wmi 36864 3 hp_wmi,wmi_bmof,mxm_wmi -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cryptsetup depends on: ii cryptsetup-bin 2:2.3.3-1 ii debconf [debconf-2.0] 1.5.74 ii dmsetup 2:1.02.167-1+b1 ii libc6 2.30-8 Versions of packages cryptsetup recommends: ii cryptsetup-initramfs 2:2.3.3-1 pn cryptsetup-run <none> Versions of packages cryptsetup suggests: ii dosfstools 4.1-2 pn keyutils <none> ii liblocale-gettext-perl 1.07-4 -- debconf information: cryptsetup/prerm_active_mappings: true -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [next] | [standalone]
| From | Guilhem Moulin <guilhem@debian.org> |
|---|---|
| Date | 2020-07-03 16:20 +0200 |
| Message-ID | <AouHM-4Qr-7@gated-at.bofh.it> |
| In reply to | #1016300 |
[Multipart message — attachments visible in raw view] — view raw
Control: reassign -1 cryptsetup-initramfs 2:2.3.3-1 Control: tag -1 + moreinfo On Fri, 03 Jul 2020 at 12:53:17 +0200, Vincent Lefevre wrote: > I don't know really where the problem comes from, but it now takes > one minute to unlock the disk of my laptop with a passphrase. Well, > I'm not sure whether this comes from cryptsetup or something that > comes just after it, but at least the fact that cryptsetup doesn't > output any confirmation message doesn't help. See https://wiki.debian.org/InitramfsDebug#Saving_debug_information to get debug output. For further detailed debug output you can append `-x` to the shebang line of the boot script causing the delay. See e.g., https://cryptsetup-team.pages.debian.net/cryptsetup/README.debug.html . > Until June 30, this was always immediate, and nothing changed > on my system. 2:2.3.3-1 landed into sid resp. testing on June 04 resp. June 09. > My laptop no longer has an Ethernet cable plugged in, so that this > might make the difference. […] Note that I've always had > > e1000e > > in /etc/initramfs-tools/modules. This is irrelevant as far as the cryptsetup-initramfs boot scripts are concerned. -- Guilhem.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| Date | 2020-07-04 00:30 +0200 |
| Message-ID | <AoClY-1cU-17@gated-at.bofh.it> |
| In reply to | #1016319 |
[Multipart message — attachments visible in raw view] — view raw
On 2020-07-03 16:12:49 +0200, Guilhem Moulin wrote: > On Fri, 03 Jul 2020 at 12:53:17 +0200, Vincent Lefevre wrote: > > I don't know really where the problem comes from, but it now takes > > one minute to unlock the disk of my laptop with a passphrase. Well, > > I'm not sure whether this comes from cryptsetup or something that > > comes just after it, but at least the fact that cryptsetup doesn't > > output any confirmation message doesn't help. > > See https://wiki.debian.org/InitramfsDebug#Saving_debug_information to > get debug output. For further detailed debug output you can append `-x` > to the shebang line of the boot script causing the delay. See e.g., > https://cryptsetup-team.pages.debian.net/cryptsetup/README.debug.html . I've attached the initramfs.debug file. But I don't know what is blocking. The unlocking should have been completed before the following lines appear (since at this time I had entered the passphrase on the console). IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP IP-Config: no response after 6 secs - giving up IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP IP-Config: no response after 9 secs - giving up IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP IP-Config: no response after 16 secs - giving up IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP IP-Config: no response after 25 secs - giving up Note that /usr/share/doc/dropbear-initramfs/README.initramfs says at the end: This is non-blocking for the startup process, so when you are at the console you won't have to wait for the SSHd to complete its startup. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Guilhem Moulin <guilhem@debian.org> |
|---|---|
| Date | 2020-07-04 00:40 +0200 |
| Message-ID | <AoCvE-1g4-19@gated-at.bofh.it> |
| In reply to | #1016406 |
[Multipart message — attachments visible in raw view] — view raw
Control: reassign -1 dropbear-initramfs 2020.79-1 Control: retitle -1 dropbear-initramfs: init-bottom blocks for 1 minute when there is no link Control: severity -1 normal On Sat, 04 Jul 2020 at 00:18:59 +0200, Vincent Lefevre wrote: > Note that /usr/share/doc/dropbear-initramfs/README.initramfs > says at the end: > > This is non-blocking for the startup process, so when you are at the > console you won't have to wait for the SSHd to complete its startup. I happen to maintain dropbear-initramfs and wrote that :-) While the init-premount script is non-blocking, the init-bottom is blocking. This is a side effect of the #943459, but I'm not sure it's possible to have it both ways. Need to do some tests to see where the link is detected. -- Guilhem.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| Date | 2020-07-04 01:00 +0200 |
| Message-ID | <AoCOZ-1nB-3@gated-at.bofh.it> |
| In reply to | #1016411 |
On 2020-07-04 00:30:04 +0200, Guilhem Moulin wrote:
> On Sat, 04 Jul 2020 at 00:18:59 +0200, Vincent Lefevre wrote:
> > Note that /usr/share/doc/dropbear-initramfs/README.initramfs
> > says at the end:
> >
> > This is non-blocking for the startup process, so when you are at the
> > console you won't have to wait for the SSHd to complete its startup.
>
> I happen to maintain dropbear-initramfs and wrote that :-)
>
> While the init-premount script is non-blocking, the init-bottom is
> blocking. This is a side effect of the #943459, but I'm not sure it's
> possible to have it both ways. Need to do some tests to see where the
> link is detected.
I suppose that's
wait_for_dropbear() {
local pid exe timer=60
pid="$(cat "$PIDFILE" 2>/dev/null)" || return 1
# when configure_networking() is run asynchronously dropbear might
# not have started yet; ipconfig doesn't react to SIGTERM so we wait
# for the network stack to be configured (and dropbear to start)
# rather than terminating the shell and its children
while [ $timer -gt 0 ] && exe="$(readlink -f "/proc/$pid/exe" 2>/dev/null)"; do
if [ "$exe" = "$EXE" ]; then
echo "$pid"
return 0
fi
sleep 1
timer=$(( timer - 1))
done
return 1
}
Couldn't it also check whether the user has typed the passphrase,
and quit in this case? (I assume that the information is available
somewhere or can be made available.)
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Guilhem Moulin <guilhem@debian.org> |
|---|---|
| Date | 2020-07-04 01:10 +0200 |
| Message-ID | <AoCYG-1Gi-5@gated-at.bofh.it> |
| In reply to | #1016414 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, 04 Jul 2020 at 00:54:53 +0200, Vincent Lefevre wrote:
> I suppose that's
>
> wait_for_dropbear() {
> […]
> }
>
> Couldn't it also check whether the user has typed the passphrase,
> and quit in this case?
That would introduce back the race condition described in #943459.
configure_networking() runs in the background and might still be running
at init-bottom stage, after the user has unlocked all drives from the
console. Also dropbear-initramfs isn't only used for remote unlocking
and I don't want to tie the two with adhoc hacks.
--
Guilhem.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| Date | 2020-07-05 12:20 +0200 |
| Message-ID | <Ap9UC-5KM-3@gated-at.bofh.it> |
| In reply to | #1016417 |
On 2020-07-04 01:07:15 +0200, Guilhem Moulin wrote:
> On Sat, 04 Jul 2020 at 00:54:53 +0200, Vincent Lefevre wrote:
> > I suppose that's
> >
> > wait_for_dropbear() {
> > […]
> > }
> >
> > Couldn't it also check whether the user has typed the passphrase,
> > and quit in this case?
>
> That would introduce back the race condition described in #943459.
I don't think so, as this would be equivalent to the current code when
it reaches the 60-second timeout, except that the wait_for_dropbear()
function will return earlier (with return value 1). Thus this would be
no worse than the current code.
> configure_networking() runs in the background and might still be running
> at init-bottom stage, after the user has unlocked all drives from the
> console. Also dropbear-initramfs isn't only used for remote unlocking
> and I don't want to tie the two with adhoc hacks.
It could be a generic abort condition for all init-bottom cases.
For instance, if a file /run/initramfs/init-bottom-terminate is
created, then all the init-bottom scripts should terminate ASAP.
Alternatively, wait_for_dropbear() could run a user-provided
script (if it exists) as an additional "while" condition.
And for that, cryptsetup-initramfs should have a way to signal
that the disks have been unlocked.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Guilhem Moulin <guilhem@debian.org> |
|---|---|
| Date | 2020-07-05 16:40 +0200 |
| Message-ID | <ApdYe-86M-13@gated-at.bofh.it> |
| In reply to | #1016565 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 05 Jul 2020 at 12:08:41 +0200, Vincent Lefevre wrote: > On 2020-07-04 01:07:15 +0200, Guilhem Moulin wrote: >> That would introduce back the race condition described in #943459. > > I don't think so, as this would be equivalent to the current code when > it reaches the 60-second timeout, except that the wait_for_dropbear() > function will return earlier (with return value 1). The raison d'être of wait_for_dropbear() is to avoid handing the execution over to init(1) with a running ipconfig process or unclean network stack. This is what the race condition described in #943459 is about. wait_for_dropbear() somewhat of a hack, but ipconfig doesn't seem to react to SIGTERM and I couldn't do better at the time. If wait_for_dropbear() were to have an abort mechanism that didn't wait for ipconfig to settle or give up, then we would reintroduce the race condition. > Thus this would be no worse than the current code. Consider a slow DHCP setup where ipconfig gets a lease after 45s or so. While it's running you unlock drives so the boot process can proceed. If the execution is handed over to init(1) right away, without waiting for ipconfig to settle or give up (nor for dropbear to start), then ipconfig and dropbear will race with the network stack resp. SSHd of the main system. This might yield a static IP being overwritten by DHCP, like in #943459, and/or OpenSSH failing to start because dropbear listens on 22/tcp already. -- Guilhem.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| Date | 2020-07-06 01:00 +0200 |
| Message-ID | <AplM5-4t1-1@gated-at.bofh.it> |
| In reply to | #1016614 |
On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote: > On Sun, 05 Jul 2020 at 12:08:41 +0200, Vincent Lefevre wrote: > > On 2020-07-04 01:07:15 +0200, Guilhem Moulin wrote: > >> That would introduce back the race condition described in #943459. > > > > I don't think so, as this would be equivalent to the current code when > > it reaches the 60-second timeout, except that the wait_for_dropbear() > > function will return earlier (with return value 1). > > The raison d'être of wait_for_dropbear() is to avoid handing the > execution over to init(1) with a running ipconfig process or unclean > network stack. This is what the race condition described in #943459 is > about. wait_for_dropbear() somewhat of a hack, but ipconfig doesn't > seem to react to SIGTERM and I couldn't do better at the time. How about SIGKILL, then? > If wait_for_dropbear() were to have an abort mechanism that didn't wait > for ipconfig to settle or give up, then we would reintroduce the race > condition. > > > Thus this would be no worse than the current code. > > Consider a slow DHCP setup where ipconfig gets a lease after 45s or so. With a temporary DHCP server failure, it can be more than the current timeout of 60 seconds. > While it's running you unlock drives so the boot process can proceed. > If the execution is handed over to init(1) right away, without waiting > for ipconfig to settle or give up (nor for dropbear to start), then > ipconfig and dropbear will race with the network stack resp. SSHd of the > main system. This might yield a static IP being overwritten by DHCP, > like in #943459, and/or OpenSSH failing to start because dropbear > listens on 22/tcp already. The user has more knowledge than initramfs. For instance, he knows whether the link is present. And he generally knows the typical time he has to wait for the DHCP server (unless a major problem occurs with the server, in which case he may have to wait any time). So it's better to leave the control to the user. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Guilhem Moulin <guilhem@debian.org> |
|---|---|
| Date | 2020-07-06 01:10 +0200 |
| Message-ID | <AplVM-4LC-7@gated-at.bofh.it> |
| In reply to | #1016703 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote: > On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote: >> The raison d'être of wait_for_dropbear() is to avoid handing the >> execution over to init(1) with a running ipconfig process or unclean >> network stack. This is what the race condition described in #943459 is >> about. wait_for_dropbear() somewhat of a hack, but ipconfig doesn't >> seem to react to SIGTERM and I couldn't do better at the time. > > How about SIGKILL, then? No. >> Consider a slow DHCP setup where ipconfig gets a lease after 45s or so. > > With a temporary DHCP server failure, it can be more than the current > timeout of 60 seconds. Of course. Like most thresholds this is at attempt at finding a reasonable default, not something that covers all cases… >> While it's running you unlock drives so the boot process can proceed. >> If the execution is handed over to init(1) right away, without waiting >> for ipconfig to settle or give up (nor for dropbear to start), then >> ipconfig and dropbear will race with the network stack resp. SSHd of the >> main system. This might yield a static IP being overwritten by DHCP, >> like in #943459, and/or OpenSSH failing to start because dropbear >> listens on 22/tcp already. > > The user has more knowledge than initramfs. For instance, he knows > whether the link is present. And he generally knows the typical > time he has to wait for the DHCP server (unless a major problem > occurs with the server, in which case he may have to wait any time). > So it's better to leave the control to the user. I could certainly make the timeout configurable, but that's be an option hardcoded in the initramfs (or the kernel command line) so probably not ideal to manually flip occasionally when the users knows there is no link present. -- Guilhem.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| Date | 2020-07-06 02:00 +0200 |
| Message-ID | <ApmIa-51j-7@gated-at.bofh.it> |
| In reply to | #1016707 |
On 2020-07-06 01:06:58 +0200, Guilhem Moulin wrote: > On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote: > > On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote: > >> The raison d'être of wait_for_dropbear() is to avoid handing the > >> execution over to init(1) with a running ipconfig process or unclean > >> network stack. This is what the race condition described in #943459 is > >> about. wait_for_dropbear() somewhat of a hack, but ipconfig doesn't > >> seem to react to SIGTERM and I couldn't do better at the time. > > > > How about SIGKILL, then? > > No. Why no? > > The user has more knowledge than initramfs. For instance, he knows > > whether the link is present. And he generally knows the typical > > time he has to wait for the DHCP server (unless a major problem > > occurs with the server, in which case he may have to wait any time). > > So it's better to leave the control to the user. > > I could certainly make the timeout configurable, but that's be an option > hardcoded in the initramfs (or the kernel command line) so probably not > ideal to manually flip occasionally when the users knows there is no > link present. If you let the user run a script that controls the timeout, that would be better. For instance, a typical setting when dropbear is used to unlock the disk(s) would be to set the timeout so that the following conditions are *both* satisfied: 1. Some lower bound has been reached (say 10 seconds). 2. The passphrase has been validated. This makes sense because in this case, it is useless to abort wait_for_dropbear() while the passphrase has not been validated yet. Then there are 2 cases: 1. The user is in front of his machine. He also knows whether he should get an answer from the DHCP server. Then, depending on the context and the messages from the DHCP client that appear on the screen, he can validate his passphrase ASAP (e.g. because there is no link, so that there cannot be an answer from a DHCP server) or wait for the DHCP server to answer (the user may be the admin of the DHCP server, e.g. for a machine at home, so that he will know what to do). 2. The user is not in front of his machine, which may be far away. The only solution is to unlock the disk(s) via SSH. Since the user cannot type the passphrase, there will never be a timeout (due to condition 2), which is exactly what the user wants. Note that with these rules, condition 1 is even normally useless. It may only be useful to avoid a mistake from the user, or if the user has confidence that it will always work in practice (if the chosen value is large enough), so that the user would validate his passphrase ASAP. BTW, I've just noticed that the timeout introduces a second annoying regression: If there is a temporary issue with the DHCP server just after the machine has been restarted, so that the timeout is reached, the user will not be able to unlock the disk until he can go back in front of his machine! My proposal would solve this issue. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Guilhem Moulin <guilhem@debian.org> |
|---|---|
| Date | 2020-07-06 02:40 +0200 |
| Message-ID | <ApnkR-5G3-7@gated-at.bofh.it> |
| In reply to | #1016712 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, 06 Jul 2020 at 01:48:45 +0200, Vincent Lefevre wrote: > On 2020-07-06 01:06:58 +0200, Guilhem Moulin wrote: >> On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote: >>> On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote: >>>> The raison d'être of wait_for_dropbear() is to avoid handing the >>>> execution over to init(1) with a running ipconfig process or unclean >>>> network stack. This is what the race condition described in #943459 is >>>> about. wait_for_dropbear() somewhat of a hack, but ipconfig doesn't >>>> seem to react to SIGTERM and I couldn't do better at the time. >>> >>> How about SIGKILL, then? >> >> No. > > Why no? Not gonna send SIGKILL processes not under my control. Bad practice. It might leave all sort crap behind, I need a documented abort mechanism. >>> The user has more knowledge than initramfs. For instance, he knows >>> whether the link is present. And he generally knows the typical >>> time he has to wait for the DHCP server (unless a major problem >>> occurs with the server, in which case he may have to wait any time). >>> So it's better to leave the control to the user. >> >> I could certainly make the timeout configurable, but that's be an option >> hardcoded in the initramfs (or the kernel command line) so probably not >> ideal to manually flip occasionally when the users knows there is no >> link present. > > If you let the user run a script that controls the timeout, that > would be better. For instance, a typical setting when dropbear is > used to unlock the disk(s) would be to set the timeout so that the > following conditions are *both* satisfied: > > 1. Some lower bound has been reached (say 10 seconds). > > 2. The passphrase has been validated. > > This makes sense because in this case, it is useless to abort > wait_for_dropbear() while the passphrase has not been validated > yet. wait_for_dropbear() runs at init-bottom stage, so after dm-crypt devices have been mapped (if cryptsetup-initramfs is installed and the crypttab is not empty, that is). So you're essentially asking to set the timeout to 10s. > BTW, I've just noticed that the timeout introduces a second annoying > regression: If there is a temporary issue with the DHCP server just > after the machine has been restarted, so that the timeout is reached, > the user will not be able to unlock the disk until he can go back in > front of his machine! You mean the timeout from configure_networking() it init-premout stage? That's not a regression from 2020.79-1, didn't touch the premount script for many years. Yes configure_networking() might fail and leave the system without network, however dropbear-initramfs is not the place to fix this. configure_networking() comes from initramfs-tools, and AFAICT the same problem arises for NFS mounts. > My proposal would solve this issue. Then I probably didn't understand the issue you're describing. -- Guilhem.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| Date | 2020-07-06 19:20 +0200 |
| Message-ID | <ApCWC-6Vz-13@gated-at.bofh.it> |
| In reply to | #1016717 |
On 2020-07-06 02:34:56 +0200, Guilhem Moulin wrote: > On Mon, 06 Jul 2020 at 01:48:45 +0200, Vincent Lefevre wrote: > > If you let the user run a script that controls the timeout, that > > would be better. For instance, a typical setting when dropbear is > > used to unlock the disk(s) would be to set the timeout so that the > > following conditions are *both* satisfied: > > > > 1. Some lower bound has been reached (say 10 seconds). > > > > 2. The passphrase has been validated. > > > > This makes sense because in this case, it is useless to abort > > wait_for_dropbear() while the passphrase has not been validated > > yet. > > wait_for_dropbear() runs at init-bottom stage, so after dm-crypt devices > have been mapped (if cryptsetup-initramfs is installed and the crypttab > is not empty, that is). So you're essentially asking to set the timeout > to 10s. OK, so that's even simpler. A configurable timeout would be sufficient. > > BTW, I've just noticed that the timeout introduces a second annoying > > regression: If there is a temporary issue with the DHCP server just > > after the machine has been restarted, so that the timeout is reached, > > the user will not be able to unlock the disk until he can go back in > > front of his machine! > > You mean the timeout from configure_networking() it init-premout stage? [...] Please forget that. I meant wait_for_dropbear(), but since it runs after dm-crypt devices have been mapped, there is no issue. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.bugs.dist
csiph-web