From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 52F04214C3 for ; Tue, 2 Apr 2024 23:00:17 +0200 (CEST) Received: (qmail 32118 invoked by uid 550); 2 Apr 2024 21:00:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32083 invoked from network); 2 Apr 2024 21:00:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1712091599; x=1712696399; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zbNJiCTf+VjiGP3L8C0RMtLuL3YYXRAkIe/xY5EQce8=; b=aRb9XgY5Zn0FkVtcK+Yw3Apapdh2jrzxNbqGXGvFWKmno4f0YrIbdS5AJLNMv320s9 0Qgd6wcdX+K0uGKuufxCJgJZxfNwENSIheHEsWt9sVIdVFveo9QHhimnEsS73G/NGMcQ wVEdBq09yJNiSZ5dsu+OEdfO+v1Zacr5Srq9k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712091599; x=1712696399; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zbNJiCTf+VjiGP3L8C0RMtLuL3YYXRAkIe/xY5EQce8=; b=e75j5oW1qQ/LbgRpNbgoJ6fqVJCFVVJSNdZ7JPIIA8B1VjQdQd5VM4htJv1clnI0dC jq/Rr4wJmSiSwvxYM6lQ16kczFlo/oAcitSLkvhaAqy+ResbA87MPN4+LpS71UL7CJ6T QPvwl0BWCcueeGVf9atBXLIclv6Hs31EAOmlEQG5BqUvrsYBWjPM0gve81AOVasb7UA0 w1D916TNAngkag7PQ+HRTj9liyAFWl4pqNajtTjoKTkRTBYvDekWtDRk9T74C8e0fU9w Di9MMUPY99mCdGpkND2qOU669l7NJbvPV5yOA9RHjvOpKSux5efYucdlOxFLAt+iVska kOQA== X-Gm-Message-State: AOJu0YzWuw3YSo2gxBpsc9LTXOYj6w3kIJUnhA/zxw0j7Qgf5WEuQQdC bAq9StW+c91l/l+5jv5fkCoaIbS1gr6lViWTzCAiAXXMmUVJgGw0eLHa1VTsgPIB092ZieoQaK3 ognkO4BG6V03DLg1zQ+kiper9vqKhfuXuBDOd2gHRMdh4xd3m/w== X-Google-Smtp-Source: AGHT+IGWmUIrA/M1r8Bn/vKz6eGoYxvm/xpg4tiP6K8/0OYDTMtthb51x+cj3H2wGQj3Jmndl8zoJaHUd+dMd4ksxMY= X-Received: by 2002:a17:90b:300f:b0:2a2:5a91:1d2f with SMTP id hg15-20020a17090b300f00b002a25a911d2fmr2710245pjb.4.1712091598924; Tue, 02 Apr 2024 13:59:58 -0700 (PDT) MIME-Version: 1.0 References: <20240207012247.1121273-1-mmayer@broadcom.com> In-Reply-To: From: Markus Mayer Date: Tue, 2 Apr 2024 13:59:47 -0700 Message-ID: To: Musl Mailing List Cc: Colin Cross Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH 0/1] ldso: continue searching if wrong architecture is found On Wed, 7 Feb 2024 at 10:09, Colin Cross wrote: > > On Tue, Feb 6, 2024 at 5:23=E2=80=AFPM Markus Mayer = wrote: [...] > > The problem: > > > > If LD_LIBRARY_PATH is set to a directory containing 32-bit libraries an= d > > then a 64-bit binary is invoked, the shared library loader will pick up > > the 32-bit version of a library first, because it'll look at > > LD_LIBRARY_PATH before anything else. Mapping the 32-bit library into > > the 64-bit process will fail. This much is expected. > > > > However, even though the correct library resides on the system, the > > shared library loader never attempts to look for it. The 64-bit process > > will fail to launch, even though there is no reason for the failure. Th= e > > problem only exists, because the shared library launcher doesn't look i= n > > the remaining shared library directories. > > [...] > > Continuing to search the system directories does seem to be the right > > thing to do under the circumstances described here. Also, it is what > > glibc does. [...] > > There is a previous discussion of the same issue at > https://www.openwall.com/lists/musl/2023/02/07/3. Thanks, Colin, for pointing this out. This was very helpful. We have been able to determine that Colin's patch series from February 2023 does address our issue. If I apply Colin's patches, the shared library loader will continue searching for a shared library match after unsuccessfully trying to load a 32-bit library into a 64-bit process. This behaviour is just what one would expect. Consequently, launching a 64-bit binary no longer fails just because the shared library loader happens to find the 32-bit version of a library it needs first. In light of this, does it make sense to revive Colin's series from last year and reconsider it for inclusion? If there is anything I can do to facilitate the process, please let me know. I can certainly help with testing. If Colin's series is somehow not acceptable, please let me know as well, and I will see what I can come up with to resolve the issue. Thanks, -Markus