From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10080.outbound.protection.outlook.com [40.107.1.80]) by sourceware.org (Postfix) with ESMTPS id D3A47385842E for ; Fri, 15 Oct 2021 12:09:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D3A47385842E Received: from AM6PR04CA0065.eurprd04.prod.outlook.com (2603:10a6:20b:f0::42) by VI1PR08MB3325.eurprd08.prod.outlook.com (2603:10a6:803:3e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.17; Fri, 15 Oct 2021 12:09:28 +0000 Received: from VE1EUR03FT036.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:f0:cafe::31) by AM6PR04CA0065.outlook.office365.com (2603:10a6:20b:f0::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16 via Frontend Transport; Fri, 15 Oct 2021 12:09:28 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; sourceware.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;sourceware.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT036.mail.protection.outlook.com (10.152.19.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.15 via Frontend Transport; Fri, 15 Oct 2021 12:09:27 +0000 Received: ("Tessian outbound 8e26f7114b75:v103"); Fri, 15 Oct 2021 12:09:27 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 1f05e37dff1e36e6 X-CR-MTA-TID: 64aa7808 Received: from 8d9d2e8b1b61.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A8888DDE-67F3-4457-AB48-78BD46B73B30.1; Fri, 15 Oct 2021 12:09:20 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 8d9d2e8b1b61.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 15 Oct 2021 12:09:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W4eiFpEWjLO9dmYseui9JXvJL/OzicCzS6THO0Hx8SM2WZYkLTsJnagmgJ82OOuE5MZ7qT9Ekw0AmFcHMdDJZeKuY+UFe1I5QPRhrHl4D/UpADcp1VjyvwiKFZO4Iu64Jyc1+BSIlqs+3HEADFOB2wVfzP9IN/9nq/3F3k6QC+9euqeIFZmEZLl4xFRq0HdvPBitHni87ScGrH8vJcBaGqLW0ic98QBgCueEAOBCHfGaKpShjkaYJ/kXY04yGS5Riwn3a9vVtNqOMqp29FHIdZzGK7guHa/RcnJFKGJzXetFIjARtjd64BAP3FRT6Bap0QxaV3Tv0m6KXwtvQGb6Sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Oiql9xpLX6k+VbWQ7+dWtWpP11yo2WQuCaiRUfUboW8=; b=IgfEDdJECXwYgnID7RN3PB22VqgzWalaYwqSvQvb8ANPOr9kcUdPhnciGV+jg5JMA1PqikRAIDMH1bGVimreof2jQwliV2o7xl2W8HoOLK67fRr+wHAUtHzcRpznMVDVMpRBzpGl8nMTaxXhGCIBzypYOukILER1qx9OiY0zWwOS/4k/U0GFgh18s9Dx8jTAb0LnFR9m1etY1CKNANd7pwzA0uWxXtpXe/b2aBtMbH4coZzloK0vDwwNhjs3j6fD8NJW4NIrVaLZm1F97tBxC/qgaeoAEUUImz01U5nscdKcQee8q4yug/0XRxXNrT6Lv2Qx1PcJBYt5iXNkpbkjfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none Authentication-Results-Original: denx.de; dkim=none (message not signed) header.d=none;denx.de; dmarc=none action=none header.from=arm.com; Received: from DB9PR08MB7179.eurprd08.prod.outlook.com (2603:10a6:10:2cc::19) by DU2PR08MB7240.eurprd08.prod.outlook.com (2603:10a6:10:2d3::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16; Fri, 15 Oct 2021 12:09:17 +0000 Received: from DB9PR08MB7179.eurprd08.prod.outlook.com ([fe80::2900:7140:8ac4:6846]) by DB9PR08MB7179.eurprd08.prod.outlook.com ([fe80::2900:7140:8ac4:6846%6]) with mapi id 15.20.4608.016; Fri, 15 Oct 2021 12:09:17 +0000 Date: Fri, 15 Oct 2021 13:09:15 +0100 From: Szabolcs Nagy To: Lukasz Majewski Cc: Adhemerval Zanella , Fangrui Song , Florian Weimer , Joseph Myers , Carlos O'Donell , Andreas Schwab , libc-alpha Subject: Re: [PATCH v2] dl: Use "adr" assembler command to get proper load address on ARM Message-ID: <20211015120915.GD1982710@arm.com> References: <20210907131616.23472-1-lukma@denx.de> <20211015075417.29931-1-lukma@denx.de> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211015075417.29931-1-lukma@denx.de> X-ClientProxiedBy: LO4P265CA0033.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ae::6) To DB9PR08MB7179.eurprd08.prod.outlook.com (2603:10a6:10:2cc::19) MIME-Version: 1.0 Received: from arm.com (217.140.106.52) by LO4P265CA0033.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ae::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.15 via Frontend Transport; Fri, 15 Oct 2021 12:09:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dd511936-e32c-45ee-4f3a-08d98fd4a305 X-MS-TrafficTypeDiagnostic: DU2PR08MB7240:|VI1PR08MB3325: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:4714;OLM:4714; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: jX/7974GoXKpZRRIpPxJ7KL3Ik762AzxI7Mxzx4xbyWs0D0pbhLL5j8ThOXsSSo/lCQlO/ekYuqOwWETys4EhlzeseGuxpNm9JD7V3FFkvjjbNgYBduU5Rwwl/PAowe5PoGVC9TCV86EzliL4kSv81t9GFG7ipoI7Audy8k+TnfbryU4167d7Os4CTSMShc79ahWudo5PD+TprEIrf2LK3GMXgr13FHfuJvURONq3iApyfQipkKMFALEA9+S9s9SoFa5VGfETqscsaPnsxcR+PDtU6RTl9qz2v5il2BrYh9oMkFR9slLFSb3jQQKs5TCDa3c2lSAh0Hy89VmWcCr9hFwmsN/7c/l5tOIT6jh6dw7+QK+k0mLgSClGW7ar8qJf+qk3JwbibkqAROh2cohi1oX6e2s03k0Oq4lzwEzejZohhaqCHeAYj6DDeIz18gVMqpsbH5hbrHvwrCFF++3YbJJf2PR2EeigDqKDAapDlhzUP26CnGy4bGIg27BGOoHTGlG/TUSB6a6WgAocA4BuElZ8a7qSLoIhtoRc6PfMSBq4ecBw1+pjwFF2/wZemF6ATUN6f2Pd77KwLLOHGPBsiGvfi8ajivcbfkI6Apml9BQxXz/T97SgRnFJGYaN1T3yutIqf7sDotcn45PB3iH8CHl/FAFJyzXUjXR4oUtgXz4TdjYkSUiCuNbmPUNzbhsV5b/oA4hYlY4ozhjy2lKPQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR08MB7179.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(956004)(1076003)(26005)(38100700002)(36756003)(52116002)(2616005)(44832011)(54906003)(186003)(38350700002)(83380400001)(8676002)(4326008)(66946007)(66556008)(5660300002)(66476007)(316002)(8936002)(7696005)(8886007)(55016002)(86362001)(33656002)(508600001)(6916009)(2906002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR08MB7240 Original-Authentication-Results: denx.de; dkim=none (message not signed) header.d=none;denx.de; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT036.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 674a7286-b754-4cb1-a77f-08d98fd49c72 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0hJGAWREr57G1zZtLXRDUH2AT31p37G/UOTu6UjKrn411xd/I7S8mbyazSBtCTZzRlBegkUuN3nyOMJNAN4/i/Vgvh+2NY2Oezag00vNxQHzll8qL/wgSfRrOD3/uQbxnPJtkYEvKNtRXcDYBJ111F+S4wFW+XWUcvcdh1jYSwoiA8zw0qlj9ERbtzBMvKe5Iwic5cZMn6RSsNfA9D7k6cGk7Qf0QrbVEPFqj341nyhl6j4K50rlJo0nXNQVRl0Y07VejoarTeXuEFX7gc1S9RfA+Vwfw0rYhUBzJR6tLwF453tcZKGjM4jmnxnKhXKlsL3wjhXJBQuOakYUkt7gn70nDjNMgml/jS4qOzY78MUT/1T05MMxkGJYiH57oWoeiI3/aOBytvzRnkrj/rCzBpCitNOk0sAeodEH0rWIl7pKZEp/hXmIrW0tHwfM9+PBR6CJMMef7YDaEADiZQTzMl1ib41/9sq0kJNwtBXj43sytY9GlcA8Tnv9cSiiaET8DNSbebOpQgq+e9rlY9glQ5UA2bSbZ9td/1TWdQjW/A5/VyccrT/X0PQ+bb5RL2Qv7ytE9Z47qqZk5R1gE/549QZWIoH8pC9rFPBr5Bpqi/DsqYDgnKY3w3d8bQarYR7aGqi1aWtjSJJ/4nlA5jgizWx4f/FV5qj7fexk5JzVJ3kF8rQR/XHu07TWiBTyO7szw68RzEsCpvU2fthNVCJ/fw== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(46966006)(36840700001)(1076003)(82310400003)(8936002)(47076005)(508600001)(55016002)(4326008)(83380400001)(70206006)(7696005)(2906002)(5660300002)(36756003)(70586007)(2616005)(186003)(8886007)(316002)(6862004)(44832011)(54906003)(356005)(8676002)(336012)(26005)(33656002)(81166007)(36860700001)(956004)(86362001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2021 12:09:27.9099 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dd511936-e32c-45ee-4f3a-08d98fd4a305 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT036.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3325 X-Spam-Status: No, score=-13.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 12:09:35 -0000 The 10/15/2021 09:54, Lukasz Majewski wrote: > This change is a partial revert of commit > bca0f5cbc9257c13322b99e55235c4f21ba0bd82 > "arm: Simplify elf_machine_{load_address,dynamic}" which imposed usage > of __ehdr_start linker variable to get the address of loaded program. > > The elf_machine_load_address() function is declared in the > sysdeps/arm/dl-machine.h header. It is called from (very early) > _dl_start() entry point for the program. It shall return the load > address of the dynamic linker program. > > With this revert the 'adr' assembler instruction is used instead of a > place holder: > > arm-poky-linux-gnueabi-objdump -t ld-linux-armhf.so.3 | grep ehdr > 00000000 l .note.gnu.build-id 00000000 __ehdr_start > > which is pre-set by binutils. > > The problem starts when one runs 'prelink' on the rootfs created with > for example OE/Yocto. > Then the _ehdr_start stays as 0x0, but the ELF header's sections have > different addresses - for example 0x41000000 instead of the originally > set 0x0. > > This is crucial when /sbin/init is executed. Value set in __ehdr_start > symbol is not updated. This causes the program to crash very early > when ld-linux-armhf.so.3's _dl_start is executed, as calculated offset > for loader relocation is going to hit the kernel space (0xf7xxyyyy). > > It looks like the correct way to obtain the _dl_start offset on ARM is > to use assembler instruction 'adr' at execution time (so the prelink > assigned offset is taken into consideration) instead of __ehdr_start. > > With this patch we only modify the elf_machine_load_address() function, > as it is called very early, before the ld-linux-armhf.so.3 is performing > relocation (also its own one). i'd use an explanation like: __ehdr_start is a linker created symbol that points to the elf header. The elf header is at the beginning of the elf file and normally its virtual address is 0 in a shared library. This means the runtime address of __ehdr_start is the load address of the module. However if prelinking is applied to ld.so then all virtual addresses are moved by an offset so the runtime address of the elf header becomes the load address + prelink offset. The kernel does not treat prelinked ld.so specially so the load address is not 0, it still has to be computed, but simply using __ehdr_start no longer gives a correct value for that. This issue affects all targets with prelinking support, but so far we only got reports from OE/Yocto builds for arm that has prelinked ld.so. but i think a better fix is possible than revert: ElfW(Addr) elf_machine_load_address () { extern ElfW(Dyn) _DYNAMIC[] attribute_hidden; extern ElfW(Dyn) extern_DYNAMIC[] asm ("_DYNAMIC"); /* Uses pc-relative address computation. */ ElfW(Addr) runtime_addr = (ElfW(Addr)) &_DYNAMIC; /* Loads an unrelocated GOT entry. */ ElfW(Addr) linktime_addr = (ElfW(Addr)) &extern_DYNAMIC; return runtime_addr - linktime_addr; } I expect this to work on most targets and very similar to the code that was originally used on other targets: only a new GOT entry is introduced instead of using GOT[0]. (that new got entry will have a relative relocation which means there must be a dynamic section even in a static PIE, so i expect _DYNAMIC to be defined. this also means that it's slightly more expensive than &__ehdr_start, so it is for targets that want to support prelinked ld.so) The original arm code used _dl_start symbol, likely because that's within range for the adr instruction for more efficient pc-relative computation. But that's a function symbol that requires fixups due to thumb interworking issues and is not available in static PIE, so using _DYNAMIC sounds better even on arm. > > HW: > Hardware name: > - ARM-Versatile Express (Run with QEMU) > - Beagle Bone Black > > Build Environment: OE/Yocto -> poky > SHA1: 1e2e9a84d6dd81d7f6dd69c0d119d0149d10ade1 > > Fixes: BZ #28293 > --- > sysdeps/arm/dl-machine.h | 28 +++++++++++++++++++++++++--- > 1 file changed, 25 insertions(+), 3 deletions(-) > > diff --git a/sysdeps/arm/dl-machine.h b/sysdeps/arm/dl-machine.h > index dfa05eee44..d6e5f1d5ec 100644 > --- a/sysdeps/arm/dl-machine.h > +++ b/sysdeps/arm/dl-machine.h > @@ -39,11 +39,33 @@ elf_machine_matches_host (const Elf32_Ehdr *ehdr) > } > > /* Return the run-time load address of the shared object. */ > -static inline ElfW(Addr) __attribute__ ((unused)) > +static inline Elf32_Addr __attribute__ ((unused)) > elf_machine_load_address (void) > { > - extern const ElfW(Ehdr) __ehdr_start attribute_hidden; > - return (ElfW(Addr)) &__ehdr_start; > + Elf32_Addr pcrel_addr; > +#ifdef SHARED > + extern Elf32_Addr __dl_start (void *) asm ("_dl_start"); > + Elf32_Addr got_addr = (Elf32_Addr) &__dl_start; > + asm ("adr %0, _dl_start" : "=r" (pcrel_addr)); > +#else > + extern Elf32_Addr __dl_relocate_static_pie (void *) > + asm ("_dl_relocate_static_pie") attribute_hidden; > + Elf32_Addr got_addr = (Elf32_Addr) &__dl_relocate_static_pie; > + asm ("adr %0, _dl_relocate_static_pie" : "=r" (pcrel_addr)); > +#endif > +#ifdef __thumb__ > + /* Clear the low bit of the function address. > + > + NOTE: got_addr is from GOT table whose lsb is always set by linker if it's > + Thumb function address. PCREL_ADDR comes from PC-relative calculation > + which will finish during assembling. GAS assembler before the fix for > + PR gas/21458 was not setting the lsb but does after that. Always do the > + strip for both, so the code works with various combinations of glibc and > + Binutils. */ > + got_addr &= ~(Elf32_Addr) 1; > + pcrel_addr &= ~(Elf32_Addr) 1; > +#endif > + return pcrel_addr - got_addr; > } > > /* Return the link-time address of _DYNAMIC. */ > -- > 2.20.1 >