Page MenuHome GnuPG
Create Task
Maniphest T7044

Deadlock on Windows in sdaemon
Closed, ResolvedPublic
Actions

Description

At least on Windows and thus with pc/sc we have a reliabale lockup with smartcards. Tested with a PIV card and a single reader. Reproducer is.

  • Start Kleopatra
  • Remove card
  • Insert card
  • Sign something e.g. using the clipboard.

Here gpgsm calls scd and in turn touches the reader_status file. Kleopatra wakes up due to the touched reader status and block in scd's get_card function. Trying to do a reset with gpg-connect-agent also blocks in get_card

Hypothesis: Somewhere the unlock (put_card) does not work or the card_list and the card lock deadlock.

Here is a commented log using code with some additional debug output:

x3 KBDownload

Details

Version
gpg4win 4.3.1

Related Objects

Event Timeline

• werner triaged this task as High priority.Mar 18 2024, 8:48 AM
• werner created this task.
• gniibe added a subscriber: • gniibe.Mar 19 2024, 7:33 AM

There are two locks here; (1) rw_lock for card_top (list of cards) access and (2) individual card lock.
It looks for me that:

  • don't know how/what the thread 7208.2 does
  • the thread 7208.3: KEYINFO, then PKSIGN (gets read lock for card_top, then, individual card lock)
  • the thread 7208.4: SERIALNO --all (and wait for write lock for card_top)

If there is longer log, please show me the log about the thread 7208.2.

• werner added a comment.Mar 19 2024, 10:22 AM

The reset was due to running gpg-connect-agent reset /bye. I am currently testing something elese will get back as soon as I can turn back to 2.4

• gniibe claimed this task.Nov 14 2024, 7:31 AM
• gniibe added a project: scd.

I put "scd" tag and let me claim this ticket.

There is the main loop thread, which calls scd_update_reader_status_file, it gets the rw_lock with w mode.

The sequence could be explained by the bug of T7386.

(0) thread 3 takes the rw_lock with R mode. And it processes KEYINFO command. (it loops, not using card_get/card_put)
(1) main loop thread tries to takes rw_lock with W mode, it waits for rw_lock.
(2) new connection, and the thread 4 tried to take R-lock (and then for the card lock), it waits for rw_lock.
(3) thread 3 finishes the KEYINFO command handling, releasing rw_lock. But because of the bug, only the main loop thread wakes up.
(4) main loop thread takes the rw_lock, and scd_update_reader_status_file finishes, then release the rw_lock.
(5) thread 4 keeps waiting..., despite it's now free.
(6) thread 3 receives SETDATA, then PKSIGN command. it takes rw_lock then individual card lock by card_get.
(7) thread 3 does card_get/card_put
(8) thread 4 keeps waiting...

• gniibe mentioned this in T7396: Windows: hard lockup of scdaemon.Nov 14 2024, 7:44 AM
• gniibe closed this task as Resolved.Nov 29 2024, 7:56 AM

I believe this was fixed by T7386. Or it is now no hard lock up by T7402.
So, let me close this ticket.
If any new symptom, please add information into T7396.