From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id OGBrM89d1GGgIgEAgWs5BA (envelope-from ) for ; Tue, 04 Jan 2022 15:46:39 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id MPYDMM9d1GHEXgEAauVa8A (envelope-from ) for ; Tue, 04 Jan 2022 15:46:39 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 80A0E391A7 for ; Tue, 4 Jan 2022 15:46:39 +0100 (CET) Received: from localhost ([::1]:52982 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n4l5C-0007sK-Gi for larch@yhetil.org; Tue, 04 Jan 2022 09:46:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4l4c-0007rF-5j for bug-guix@gnu.org; Tue, 04 Jan 2022 09:46:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:53878) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n4l4b-0002PU-Sa for bug-guix@gnu.org; Tue, 04 Jan 2022 09:46:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n4l4b-00035k-L8 for bug-guix@gnu.org; Tue, 04 Jan 2022 09:46:01 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#53005: cryptsetup-static aborts opening LUKS2 volume with Argon2i PBKDF References: <87v8yz1sae.fsf@simonsouth.net> In-Reply-To: <87v8yz1sae.fsf@simonsouth.net> Resent-From: Simon South Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 04 Jan 2022 14:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53005 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 53005@debbugs.gnu.org Received: via spool by 53005-submit@debbugs.gnu.org id=B53005.164130750211784 (code B ref 53005); Tue, 04 Jan 2022 14:46:01 +0000 Received: (at 53005) by debbugs.gnu.org; 4 Jan 2022 14:45:02 +0000 Received: from localhost ([127.0.0.1]:37191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4l3d-00033g-FZ for submit@debbugs.gnu.org; Tue, 04 Jan 2022 09:45:02 -0500 Received: from mailout.easymail.ca ([64.68.200.34]:34982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4l3b-00033S-9X for 53005@debbugs.gnu.org; Tue, 04 Jan 2022 09:45:00 -0500 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 82A8C415B6 for <53005@debbugs.gnu.org>; Tue, 4 Jan 2022 14:44:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at emo02-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo02-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUltsVj00FPE for <53005@debbugs.gnu.org>; Tue, 4 Jan 2022 14:44:53 +0000 (UTC) Received: from mars (23-233-96-244.cpe.pppoe.ca [23.233.96.244]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 3C6BA41329 for <53005@debbugs.gnu.org>; Tue, 4 Jan 2022 14:44:53 +0000 (UTC) From: Simon South Date: Tue, 04 Jan 2022 09:44:52 -0500 Message-ID: <87sfu31rx7.fsf@simonsouth.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641307599; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post; bh=+Movss8K8lymSR2AZ+nwZrdeBEESH8rbiHTNed/gmus=; b=X52xjHKqq2urYpzxJPikej3RsySrfNspwATyFFwpgiY0LeUzYVyWqAIi4fE0POCDeHejs9 siMQKLeIJyIzQMWDbd+g3WSO+tzA3+3eW67pv5xFr5YJ/y5JEuGV90WOr8C9FhLKtXdiPy z78iMsK4Mk65wW9AEjvLy+eGiA1BA9A+FVWLM74dH2w2Z7z8TO8vE32/DLa5gvXBFWBXwn gSzyviTEOdlx1v/aFWqosIWag/Cu7j4s1XSsxjG/k66RQ5H48WjVKNtKs+Jjb51chI2u+q 95z2Fivoa6y4mdfIwTBSvoyYsjjy2OBD5oWYdt1ueQ2jFEf2GkEnCLDRHFNCBw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641307599; a=rsa-sha256; cv=none; b=Wb32UnFHA/ySDiooHF04Ap5h2GeXkJ9Qr5KL+tmNdTJtjlilhVNxFI5LOv4fFiBdskXp9R iF/l6ruHXd0iaGutmKeqm24SElrep+he/35l0Hrtz3YeLj+Rof0FmqgGbDa1insZaPwcCm pcQHJ8LoGvJbEFmZ10KIFH79i1yoDM/qDvQoMrVdy20WGSvu6uAll96OtoRiUnEkha7O7x FzsBVOL1RvFnQhQf9uU5pne+ZabtWU9oDsIO4WThD2YXmJg2e2zM5Hz+EWA3D9sJAt/kRq hHuF0MUXIOAwFy3P2YXydi1zNHcg5oMSrC0KA2PWBOjog6b5E1K10xYb+wPA8g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.89 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 80A0E391A7 X-Spam-Score: -3.89 X-Migadu-Scanner: scn0.migadu.com X-TUID: gZkL11isE/Cv This seems to be caused by the symbol "__pthread_key_create" being absent from cryptsetup's symbol table during linking, even though it is meant to be exported explicitly by glibc. The fundamental issue is that cryptsetup's Argon2i implementation (and thus cryptsetup itself) is multithreaded, but libgcc[0], a low-level runtime library used by the compiler, is unaware of this fact. Consequently libgcc's stack-unwinding code skips the use of a mutex that would normally synchronize data access among multiple threads, allowing a race condition to develop when two or more threads try to exit simultaneously. One thread will fail to locate its frame-descriptor entry, causing NULL to be returned by libgcc's _Unwind_Find_FDE() function (libgcc/unwind-dw2-fde.c:1029), leading to an assertion failing (in uw_init_context_1() at libgcc/unwind-dw2.c:1593) and abort() being called, terminating the process. The underlying failure is indicated in a comment in gcc's code, at libgcc/gthr-posix.h:215. libgcc uses the presence of specific symbols in a program's symbol table to infer whether or not the program is multithreaded: For a program to be multi-threaded the only thing that it certainly must be using is pthread_create. However, there may be other libraries that intercept pthread_create with their own definitions to wrap pthreads functionality for some purpose. In those cases, pthread_create being defined might not necessarily mean that libpthread is actually linked in. For the GNU C library, we can use a known internal name. This is always available in the ABI, but no other library would define it. That is ideal, since any public pthread function might be intercepted just as pthread_create might be. __pthread_key_create is an "internal" implementation symbol, but it is part of the public exported ABI. Also, it's among the symbols that the static libpthread.a always links in whenever pthread_create is used, so there is no danger of a false negative result in any statically-linked, multi-threaded program. It seems the final sentence is no longer true, at least in recent versions of Guix. Building the "cryptsetup-static" package with "#:strip-binaries? #f" and dumping the resulting binary's symbol table with "objdump -t" shows "pthread_create" is present but not "__pthread_key_create". This seems to be why libgcc's __gthread_active_p() always returns false, turning wrapper functions like __gthread_mutex_lock() into no-ops and effectively disabling the use of the mutex in _Unwind_Find_FDE(). The question then is why this symbol either is no longer being exported by glibc or is being dropped at some point during cryptsetup's compilation. (Other packages may be affected as well: Even the regular, dynamically-linked cryptsetup shows this problem, but avoids a crash by not invoking libgcc's stack-unwinding routines.) I'll keep working on this but having gotten this far, I'm hoping someone else has some insight. [0] https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html -- Simon South simon@simonsouth.net