Skip to content

common: guard ecdh() against HSM fd being non-blocking - #9402

Draft
daywalker90 wants to merge 2 commits into
ElementsProject:masterfrom
daywalker90:fix-websocket-macos
Draft

common: guard ecdh() against HSM fd being non-blocking#9402
daywalker90 wants to merge 2 commits into
ElementsProject:masterfrom
daywalker90:fix-websocket-macos

Conversation

@daywalker90

Copy link
Copy Markdown
Collaborator

Fixes: #9323

On macOS under load, connectd intermittently dies with
"STATUS_FAIL_HSM_IO: No hsmd ECDH response".  hsmd logs that it received
WIRE_HSMD_ECDH_REQ, yet connectd's synchronous wire_sync_read() returns
NULL.  The only way that read fails after hsmd answered is an EAGAIN from
an O_NONBLOCK HSM fd.

The HSM fd is one end of a socketpair sent hsmd -> lightningd -> connectd
via SCM_RIGHTS; the other end lives in hsmd's io loop, whose io_new_conn()
sets O_NONBLOCK (io.c:io_new_conn -> io_fd_block(fd, false)).  On macOS the
flag follows the shared open file description across SCM_RIGHTS, so it can
be flipped on after the one-shot setup-time io_fd_block(hsm_fd, true) added
in the previous fix, re-introducing the EAGAIN.  Ubuntu is unaffected
because its fd semantics keep the descriptions independent.

Fix ecdh() itself so it does not depend on the fd flag state: re-assert
blocking at the start of every synchronous exchange, and if a non-blocking
read still returns EAGAIN, poll for the response and retry instead of
failing the daemon.  This also hardens channeld, which uses the same
ecdh()/ecdh_hsmd_setup() path.

Changelog-Fixed: connectd: fix intermittent "No hsmd ECDH response" crash on macOS under load (issue ElementsProject#9060).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CI flake test_websocket on macos

1 participant