Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1016614
| From | Guilhem Moulin <guilhem@debian.org> |
|---|---|
| Newsgroups | linux.debian.bugs.dist |
| Subject | Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase |
| Date | 2020-07-05 16:40 +0200 |
| Message-ID | <ApdYe-86M-13@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <AoCOZ-1nB-3@gated-at.bofh.it> <AoCYG-1Gi-5@gated-at.bofh.it> <Ap9UC-5KM-3@gated-at.bofh.it> <AorAd-2Lr-1@gated-at.bofh.it> <Ap9UC-5KM-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[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.
Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web