From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30587 invoked from network); 8 May 2022 10:31:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 May 2022 10:31:14 -0000 Received: (qmail 26530 invoked by uid 550); 8 May 2022 10:31:10 -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 27937 invoked from network); 8 May 2022 07:48:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=nEbT5yO8dv1PgrDtMgWD9hidOJVyzI/8i2NurOp8DY4=; b=nQrB5jFvY84FobWi6laPFKPzeQKLZ4WipavJI6Om2/W8Y+rfbULWJagY5706EvCax+ FQIFMxAjRuP1F62LGB1Cznv5If9VikmpeeD+wU6s9VIQY4FIBN5iig0dw8vX0cEmRleJ GGlULYgvyIFKQtbJU73Ix8AqX4K9Kr04BTi9ruBmZvPSz0UfmEy7PEqQ1FOlG2qtjttC 7bWq9M3AAsH6V8c24JwhTcHX5e1oJJAD1pmAROqjPRLlq9xQ6rH2zSdCRIiCDGKujIFu cWBg05oDvqW6Qu3KDpl3Uc4DF979Jx1oY4W9FKuJ/+2nEOYLb2CpEYsK6lA6zVojK/V0 +Jjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nEbT5yO8dv1PgrDtMgWD9hidOJVyzI/8i2NurOp8DY4=; b=pW6oBo+xSFIoNZo+tt+4bZfLK5+1qMJGmzJhx+bq0U5B7NGD59tkiTZnhoDFXMfps3 FHvQ0+Px26fvWnrhVBQZvxjiYKR+6dstHqwoRcDgTcE+8Co65yDv5dRUp9gIojPnX2nS 23ts8oNV6La3FIuyN5tqNlJ8Bn+/XaA62oJUltC+dOuUp08fmroTWupXGPelxKqiBkEQ busAipINRDYAy7SeZtS9QSKHQKKfCFUh3sd8nlrj19hqUxnBarloswSoTa7K+0Lq6Gqg r3KKyaNIcsUbMaui3FgjaeJJGK77LvFa5xg/LsR/z0BZ9yZOw6EBF6irrNuS7IEhY9Pw ebiA== X-Gm-Message-State: AOAM533pxL8wXu1xa1wS7oYHSyTU9zYrciADGs235Z98kL9bdHJO0+zx Wm5speoG02BGuOD+vUz9MLmNTUkTmNCrL75AtgzAAUpE/8oMAA== X-Google-Smtp-Source: ABdhPJyBs1WA2KJ0W8foe7WuOCnP2bGY7HUrIAblkoWwGINuXDD1EPAug6t1RIya1SpAP+N8FMSqM4xH9c3TcJ2dtHE= X-Received: by 2002:a05:6870:b509:b0:ed:b1b5:e82b with SMTP id v9-20020a056870b50900b000edb1b5e82bmr4555499oap.56.1651996120674; Sun, 08 May 2022 00:48:40 -0700 (PDT) MIME-Version: 1.0 From: Pablo Galindo Salgado Date: Sun, 8 May 2022 08:48:29 +0100 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000f1762205de7b51ad" Subject: [musl] Why the entries in the dynamic section are not always relocated? --000000000000f1762205de7b51ad Content-Type: text/plain; charset="UTF-8" Hi, I have noticed that when using dl_iterate_phdr in muslc to inspect some entries in the dynamic section of different shared libraries loaded into a program, the pointers are not always relocated (they are offset instead of full addresses). For example, consider this program: #include #include #include static int phdrs_callback(dl_phdr_info* info, size_t size, void* data) noexcept { for (auto phdr = info->dlpi_phdr, end = phdr + info->dlpi_phnum; phdr != end; ++phdr) { if (phdr->p_type != PT_DYNAMIC) { continue; } const auto* dynamic_section = reinterpret_cast(phdr->p_vaddr + info->dlpi_addr); for (; dynamic_section->d_tag != DT_NULL; ++dynamic_section) { if (dynamic_section->d_tag == DT_JMPREL) { std::cerr << "Address of JMPREL for lib " << info->dlpi_name <<" is: " << (void*)dynamic_section->d_un.d_ptr << std::endl; } } } return 0; } int main() { dl_iterate_phdr(&phdrs_callback, NULL); } In most glibc systems (for instance ubuntu:20.04), this prints regular addressed that have been relocated: Address of JMPREL for lib is: 0x557bed97a8e8 Address of JMPREL for lib /usr/lib/libc.so.6 is: 0x7f8e0f08cc18 but in muslc systems (like Alpine linux, for example using the python:3.10-alpine container) this prints offsets instead of full relocated addresses: Address of JMPREL for lib ./a.out is: 0x7f8 Address of JMPREL for lib /usr/lib/libstdc++.so.6 is: 0xa94e0 Address of JMPREL for lib /lib/ld-musl-x86_64.so.1 is: 0x145c0 Address of JMPREL for lib /usr/lib/libgcc_s.so.1 is: 0x22e8 Why is this happening? How can one programmatically know when the linker is going to place here offsets or full relocated addresses? In which situation does this happen? Thanks in advance for the help! Kind regards, Pablo Galindo Salgado --000000000000f1762205de7b51ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,<= /div>

I = have noticed that when using=C2=A0dl_iterate_phdr in muslc to inspect some = entries in the dynamic section
of differe= nt shared libraries loaded=C2=A0into a program, the pointers are not always= relocated (they
are offset instead of fu= ll addresses). For example, consider this program:

#include <elf.h>
#= include <link.h>
#include <iostream>

static int
ph= drs_callback(dl_phdr_info* info, size_t size, void* data) noexcept
{
= =C2=A0 =C2=A0 for (auto phdr =3D info->dlpi_phdr, end =3D phdr + info-&g= t;dlpi_phnum; phdr !=3D end; ++phdr) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (p= hdr->p_type !=3D PT_DYNAMIC) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 continue;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 const auto* dynamic_section =3D reinterpret_cast<const ElfW(Dyn)*>= ;(phdr->p_vaddr + info->dlpi_addr);

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 for (; dynamic_section->d_tag !=3D DT_NULL; ++dynamic_section) {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (dynamic_section->d_tag =3D= =3D DT_JMPREL) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= std::cerr << "Address of JMPREL for lib " << info-&g= t;dlpi_name <<" is: " << (void*)dynamic_section->d= _un.d_ptr << std::endl;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 retu= rn 0;
}

int main() {
=C2=A0 =C2=A0 dl_iterate_phdr(&phdrs_= callback, NULL);
}

In most glibc systems (for in= stance=C2=A0=C2=A0ubuntu:20.04), this p= rints regular addressed that have been relocated:

Address of JMPREL for lib =C2=A0is: = 0x557bed97a8e8
Address of JMPREL for lib /usr/lib/libc.so.6 is: 0x7f8e0f= 08cc18

but in muslc systems (like Alpine= linux, for example using the=C2=A0python:3.10-alpine container) this print= s offsets
instead of full= relocated addresses:

Address of JMPREL for= lib ./a.out is: 0x7f8
Address of JMPREL for lib /usr/lib/libstdc++.so.6= is: 0xa94e0
Address of JMPREL for lib /lib/ld-musl-x86_64.so.1 is: 0x14= 5c0
Address of JMPREL for lib /usr/lib/libgcc_s.so.1 is: 0x22e8

=
Why is this happening? How can one pr= ogrammatically know when the linker is going to place here offsets or full<= /font>
relocated addresses? In w= hich situation does this happen?

Thanks in ad= vance for the help!

<= /font>
Kind regards,
Pablo Galindo Salgado
--000000000000f1762205de7b51ad--