Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1016717

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

Show all headers | View raw

[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.

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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