From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 91BC4385842E for ; Fri, 15 Oct 2021 12:22:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 91BC4385842E Received: by mail-pl1-x62c.google.com with SMTP id n11so6288585plf.4 for ; Fri, 15 Oct 2021 05:22:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jLWST5wfSf9fWYirPaDdlzXVNI6DksrbkO5ZA3UrTVA=; b=0IKvHNsNQdgWezdas6qTRERuMWqbLMbpQr3T+CstLLs5DGCdXdd4hD2eXgQ6GP0OGB orTrc5aR7OdYhgp7jNw1YvZRJQaCAmpLqYEdaDt3fRMCEfo7HC0ChaW3wki0ff6l0l3P IXccNm8en2TbpcMh/mHeu0RXMJ/xO7Mp6L5hv2Xr3Q/m8vnTVnwTD3Nv+q4r19BtlC2H ZLTInY3Sho7jQ7GkK7CxCtVRYtNV94MgmX7wyAsjLPneVw4gVLXKzRV3kTtQJzm6EfW6 sGg1I2ROtmlbwqfpq0gR+TT5BwRziygd2eYUGNZnA30k0Pvhe0kP83WeFvBoSlk/RXw2 zidA== X-Gm-Message-State: AOAM531Pr6CQteHQ+O1JXp3P+bOeJKHk6G+pzLkok1WJVczqYZI1GWcq PpBNJ7LaLTL708TPH7D46drJVEQhyJ7g4SxyMrw= X-Google-Smtp-Source: ABdhPJwiMqlZxjcJ5/K3IhlDHxA4FgT//j72S4bpm29vhiCg1sxINEv/WN1FNNfmi/sb11F0TdjDYXZMxdjr1bER6UQ= X-Received: by 2002:a17:90b:38c6:: with SMTP id nn6mr1157910pjb.28.1634300519572; Fri, 15 Oct 2021 05:21:59 -0700 (PDT) MIME-Version: 1.0 References: <20210907131616.23472-1-lukma@denx.de> <20211015075417.29931-1-lukma@denx.de> <20211015120915.GD1982710@arm.com> In-Reply-To: <20211015120915.GD1982710@arm.com> From: "H.J. Lu" Date: Fri, 15 Oct 2021 05:21:23 -0700 Message-ID: Subject: Re: [PATCH v2] dl: Use "adr" assembler command to get proper load address on ARM To: Szabolcs Nagy Cc: Lukasz Majewski , Florian Weimer , libc-alpha , Andreas Schwab , Joseph Myers Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3024.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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:22:02 -0000 On Fri, Oct 15, 2021 at 5:09 AM Szabolcs Nagy via Libc-alpha wrote: > > 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: I think either prelink should be fixed not to prelink ld.so or Yocto should be fixed not to prelink ld.so. -- H.J.