From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 9A1DB387545B for ; Wed, 26 Jun 2024 21:56:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9A1DB387545B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9A1DB387545B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::630 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719439001; cv=none; b=HmBeAaAenevf50r+3nwzk3VmneicXVRgyd1r4SmTplopqoNqQjr3IEMA8QSUV7asdWQcYK+SpgXT22WMBCGRuW+/+3QaoYDzpO4Miva0MDEVsBqpNq5LO0204R0gUU06VcQOCbY49Siajj8Fy9PlXooAxevmMtq2qVhpUwDLHos= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719439001; c=relaxed/simple; bh=434dobhHViRubz/xGdeAvDYuYrRzu4tQdUS/t+omTRs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=WtbOKbTsX47Hh1YTM6dWeppfhNU6xBdi5bFtNrx5GG1jOxmpbhs1fSOPgzTs0KAOxrc7e70VCQ166s6lqyzPVHgjibOIHfe82rr8ch2VN/eNrWAWAQckb7wxuCbqSEPM3wqbkspGrsqrVP8v4x+N4BfosJxWVPcoPbEBONgP5lM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1f47f07aceaso56095585ad.0 for ; Wed, 26 Jun 2024 14:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1719438996; x=1720043796; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=KaVKDhAvkNPPWInkMOxVhmd106euQJGftNO86UGn8k0=; b=ZJu4x5bu6wVgPuW2SSWXYioJ6dQf/hoY9kFsUuZom6BBFETdGXENC2GshmSrFOjA/j sDruzUZBGzQpUeGWa2ZlaQOehRLEE2UnQHPbAPZe659JK5bdLL7G97IIjfTUWjmCyNa8 u/6HrMcbKfCbIw1gdLC+rg4r++bXeey5SIXRImAAZbGbMj10p2DsgwyfL1b5QLi5zagZ 9Y9roshZ1aDs6fbLdslK6I1yb/fWpX9UFzUUGkJHwvsfb7PVhcfaTGrwUYMs/yg7H8IP Ee5PqbnuBs602uST8Zeztn2RaOhj2FVZcA6zVt1sE9hlCWCMgyrPdARAsAGqxtxrU4sm Vrhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719438996; x=1720043796; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KaVKDhAvkNPPWInkMOxVhmd106euQJGftNO86UGn8k0=; b=bgEvuqZiTGh4b5G968CYWjRFNoE4vroTRVQXhKgth09+mdNn3FaCntNyRmLHKrH3vi 0nmwEe1HpizbqabNcpCmyrvOF81/aK2sDRvynavKtmbimBfkjqUpQoNt5LECC1nHoe98 yQvaF/yEbTWxg+sVelo+Cw3gXPF8siDrNlBZ+iPHeE6ZFN+VheWwxYKV8ixmoZDOgi1b wrSX9GfA+peQYDWLTM0OPoAWIeXUpVHkVELZ6j62+TqMZV+goYpeWDJQP7fdP4719Awq 1HsKTFBal8fbMSNdh0fC1NYEgGc9zDk2VTu7HqAyojp7Tf5Lp4MAF5W+ZjaU/Yj/xbLs dvXw== X-Gm-Message-State: AOJu0Yw6gQ7Zt1J49Mx4rKfhdDkQpTRXVzudJIC7g6qH0V1YB/5Y6VHB xCAGDG/sh0y60+Z8cvsbl5gnF9+uV3ng/WopMrywKgaAQCODXyCiezELm7WgAgo= X-Google-Smtp-Source: AGHT+IGmgJ57ad3DhoydCgTMJQvydrycjedfyas6IkJriwXffbCDLUite32p3x8x4Rifm7jDMk+vxQ== X-Received: by 2002:a17:903:187:b0:1f3:b55:e247 with SMTP id d9443c01a7336-1fa15937b3bmr120902975ad.55.1719438996423; Wed, 26 Jun 2024 14:56:36 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:e1e5:1dfb:a750:9574:3865? ([2804:1b3:a7c1:e1e5:1dfb:a750:9574:3865]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f9eb3c5fdesm104665815ad.164.2024.06.26.14.56.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Jun 2024 14:56:35 -0700 (PDT) Message-ID: <97a92907-e1f4-4ea4-88bc-e14d3f7cc1ed@linaro.org> Date: Wed, 26 Jun 2024 18:56:32 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 3/5] elf: Add support to memory sealing To: Mike Hommey Cc: libc-alpha@sourceware.org, "H.J. Lu" , Fangrui Song References: <20240611153220.165430-1-adhemerval.zanella@linaro.org> <20240611153220.165430-4-adhemerval.zanella@linaro.org> <20240621050904.23y4cyfi5zt3jvid@glandium.org> <65e0af46-d8aa-44b0-a01e-c299158345c1@linaro.org> <20240625231849.hxm3zduu5wxnu6pf@glandium.org> <31c263e7-ba37-434f-a483-bbcc493b5461@linaro.org> <20240626195840.mzmd73eed7uo3lxo@glandium.org> <7d8e6ff6-3bb5-462d-8dbb-3587ebdd404b@linaro.org> <20240626213926.pasrubmzfytzjv47@glandium.org> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <20240626213926.pasrubmzfytzjv47@glandium.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 26/06/24 18:39, Mike Hommey wrote: > On Wed, Jun 26, 2024 at 06:20:22PM -0300, Adhemerval Zanella Netto wrote: >> >> >> On 26/06/24 16:58, Mike Hommey wrote: >>> On Wed, Jun 26, 2024 at 08:58:30AM -0300, Adhemerval Zanella Netto wrote: >>>> >>>> >>>> On 25/06/24 20:18, Mike Hommey wrote: >>>>> Thanks for your answer. Just an additional comment below. >>>>> >>>>> On Tue, Jun 25, 2024 at 06:07:23PM -0300, Adhemerval Zanella Netto wrote: >>>>>> There was a recent question about the the need of GLIBC_ABI_DT_RELR on >>>>>> libc-help maillist [1] and the main reason, as Florian has said, is to >>>>>> avoid hard to debug crashes with binaries/libraries built with DT_RELR >>>>>> on glibc versions that do not support DT_RELR. >>>>> >>>>> That's a valid reason for the linker to add the version dependency, not >>>>> for ld.so to enforce it. But it's too late to relax it anyways. >>>> >>>> Old glibc will just ignore the DT_RELR, meaning that relocation won't apply >>>> and the binary will misbehave after loading time. We are moving away of >>>> such failures mode because such issues are really hard to debug, you have >>>> to know both dynamic linker and ELF internals to understand why your library >>>> that you built with a recent binutils works on a recent glibc but fails on >>>> an older one. >>> >>> The point is, if you built your binary with a recent binutils, it >>> already won't run on an old glibc because of the version dependency. >>> That will happen whether or not the newer glibc barks when the version >>> dependency is not there. >> >> The version dependency is only added if you explicitly use DT_RELR, >> which is an optional feature, otherwise the version tags will be ones >> from the glibc version is building against. Different PT_GNU_RELRO, which >> is also optional and added a opt-in hardening, specifying DT_RELR and r >> unning on old loader will cause runtime inconsistency. > > I'm not talking about PT_GNU_RELRO here. My point is, if you build your > binary with a recent binutils and opt-in to DT_RELR, the linker is going > to add the GLIBC_ABI_DT_RELR dependency. If you have a binary using > DT_RELR without a GLIBC_ABI_DT_RELR dependency, it was not produced by a > recent binutils. Currently, the only way to end up in a situation where > you don't have the version depenendency is to either use an old lld > flag, or edit ELF headers manually, and in both cases, you'd be asking > for it. The ld.so check is unnecessary. > > But as I said already, it's already too late, it doesn't matter anymore. But DT_RELR was added on glibc before binutils support with the precondition that GLIBC_ABI_DT_RELR should be added, as per contract. H.J implemented it on x86 Fangrui adapted it on lld side. A binary with DT_RELR without GLIBC_ABI_DT_RELR was never supported, you could have created with some lld version *before* supported was added on glibc. The GLIBC_ABI_DT_RELR dependency was added exactly to avoid the very hack you are trying to do: building a binary that might eventually trigger runtime inconsistency depending of the glibc version you ran it.