Page MenuHome GnuPG
Create Task
Maniphest T7396

Windows: hard lockup of scdaemon
Open, HighPublic
Actions

Description

Hard lockup of scdaemon is observed.
"Hard" means that gpgconf --kill scdeamon cannot kill the process, but manual killing is required.

If it's not "hard", that is, the case where gpgconf --kill scdaemon can kill the process, it's considered fixed by T7386 (see T7378 and T7044).

This situation can be artificially created (even on POSIX machine), see T7323. Note that this situation is only under extreme scenario.

If it's clear that the lockup is due to the output non-consumption of client, please put information on T7323.
Otherwise, for other cases, please put information here.

If the log of Kleo (like the one in T7378) is available, it helps debugging.

Related Objects
Search...

Event Timeline

• gniibe triaged this task as High priority.Thu, Nov 14, 7:39 AM
• gniibe created this task.
• gniibe updated the task description. (Show Details)Thu, Nov 14, 7:44 AM
• gniibe added projects: scd, Windows.
• gniibe mentioned this in T7323: scdaemon hangs up (when output from scdaemon is not consumed by gpg-agent).Mon, Nov 18, 3:09 AM
• gniibe added a subtask: T7400: Netkey 3.0 card slow detection.
• gniibe added a subscriber: • ebo.Mon, Nov 18, 3:40 AM

As of 2024-11-18, my hypothesis is:

  • there are some sort of race conditions between PC/SC + card reader (or its driver) + smartcard + scdaemon on Windows, at least at initial use after boot
  • because of this, SCardConnect of PC/SC call wrongly fails (somehow confirmed by @ebo's experiments + @gniibe's speculation), or wrongly never returns (@gniibe's guess, side info: its slowness is observed in T7400).

If there is a case of SCardConnect never returns, it's true that scdaemon results hard lockup.
With the hard lockup of scdaemon, gpg -K or gpgsm -K also hangs, because KEYINFO command never returns.
gpgconf --kill scdaemon never gets success.

(For experienced users', this kind of behavior (used to be)/is common with smartcards and its card readers. They know it's not that reliable in some situations actually. And they just kill-and-reset all related programs around smartcard manually as a normal breathing.)

We need to accept/prepare the situation of SCardConnect never returns because of other factors (PC/SC + card reader (or its driver) + smartcard).
While it is not common any more with modern token implementation, the issue might still exist with some card/card reder/its driver. It could be more likely in 32-bit old proprietary driver.

• gniibe added a comment.EditedMon, Nov 18, 3:49 AM

Hard lockup should be avoided. In particular, following conditions should meet:

  • gpgconf --kill scdaemon can kill scdaemon
  • KEYINFO requests can be answered for other connections of scdaemon

If so, Kleo will be OK even with the problem.

Besides,

  • by other connections, even if one USB connection of one card reader behaves badly/wrongly, it would be good for scdaemon to keep working correctly for other existing use of good card reader
  • timeout of SCardConnect could be supported by scdaemon, it must not be fatal (with SCardConnect never returns)
• gniibe changed the status of subtask T7402: No hard lockup when SCardConnect never returns from Open to Testing.Mon, Nov 18, 6:30 AM
• gniibe updated the task description. (Show Details)Mon, Nov 18, 10:11 AM