From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 0E5023858D3C for ; Sun, 16 Jan 2022 00:10:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0E5023858D3C Received: by mail-pf1-x42a.google.com with SMTP id i17so6267631pfk.11 for ; Sat, 15 Jan 2022 16:10:54 -0800 (PST) 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=CBUISIR2kRLSUYqNRQ97YZpCl/baPEKz67c6TI7OOO8=; b=IBGvSPxSGDBGiLTne0a5YZ+wTlnzEdZ/UofTGYw3CLDSON7FeSV9B9KFzruZdQcaIV sKoVUgK3iBuRM0Rsbl0lOwY8iVXvO5mZ85Bv+Slvmyi+BAReF9ghWmg2OxdE/KSeyLuj utC4e3tJTJr3TdzZQLUQT0rc5s77UBN3HyEUniwY+fPJhPosb8eWc+CEvZYYhu4HCl3n GAy/JI+LxnkHefTWMV3kqDt2fl4D1zGY8WbCayzdJ+5sPAZTYyPq8eKAujOGdY5N19Te 9Mg9PcRHoyvBnaBhWsHp7QnbQvV5GGMxsPbw3RrrmK6Hkv760F83AmMqQ0iaYtuJPctt c5Ig== X-Gm-Message-State: AOAM530P0kWDGOXFiU5LbHAQnMrMYjInOnaBH2P3hO/oITRRX4kmXfD3 /5OODCA3QWBAjaTaLJImtjov/OCdBdY0WTsRl3vvG3BwcNI= X-Google-Smtp-Source: ABdhPJxjmrWCX/XgPLkCMXJJhljHXMZD2haSlFyw1k3fKe6SiSptKsWHHjm124v6IX6hb+B+w7r1hT9lznjzihkLKDY= X-Received: by 2002:a63:b24e:: with SMTP id t14mr13513922pgo.381.1642291853132; Sat, 15 Jan 2022 16:10:53 -0800 (PST) MIME-Version: 1.0 References: <1c4f55eb03365f9ea7238e7ab4a997802081bf6e.1641228666.git.fweimer@redhat.com> In-Reply-To: <1c4f55eb03365f9ea7238e7ab4a997802081bf6e.1641228666.git.fweimer@redhat.com> From: "H.J. Lu" Date: Sat, 15 Jan 2022 16:10:17 -0800 Message-ID: Subject: Re: [PATCH 2/3] elf: Set l_contiguous to 1 for the main map in more cases To: Florian Weimer Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3027.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, 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: Sun, 16 Jan 2022 00:10:56 -0000 On Mon, Jan 3, 2022 at 9:12 AM Florian Weimer via Libc-alpha wrote: > > l_contiguous was not initialized at all for the main map and > always 0. This commit adds code to check if the LOAD segments > are adjacent to each other, and sets l_contiguous accordingly. > This helps _dl_find_object because it is more efficient if the > main mapping is contiguous. > > Note that not all (PIE or non-PIE) binaries are contiguous in this > way because BFD ld creates executables with LOAD holes: > > ELF LOAD segments creating holes in the process image on GNU/Linux > https://sourceware.org/pipermail/binutils/2022-January/119082.html > https://sourceware.org/bugzilla/show_bug.cgi?id=28743 > --- > elf/rtld.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/elf/rtld.c b/elf/rtld.c > index ba6e31377d..53293f5b13 100644 > --- a/elf/rtld.c > +++ b/elf/rtld.c > @@ -1144,6 +1144,22 @@ rtld_setup_main_map (struct link_map *main_map) > main_map->l_map_start = ~0; > /* And it was opened directly. */ > ++main_map->l_direct_opencount; > + main_map->l_contiguous = 1; > + > + /* A PT_LOAD segment at an unexpected address will clear the > + l_contiguous flag. The ELF specification says that PT_LOAD > + segments need to be sorted in in increasing order, but perhaps > + not all executables follow this requirement. Having l_contiguous > + equal to 1 is just an optimization, so the code below does not > + try to sort the segments in case they are unordered. > + > + There is one corner case in which l_contiguous is not set to 1, > + but where it could be set: If a PIE (ET_DYN) binary is loaded by > + glibc itself (not the kernel), it is always contiguous due to the > + way the glibc loader works. However, the kernel loader may still > + create holes in this case, and the code here still uses 0 > + conservatively for the glibc-loaded case, too. */ > + ElfW(Addr) expected_load_address = 0; > > /* Scan the program header table for the dynamic section. */ > for (const ElfW(Phdr) *ph = phdr; ph < &phdr[phnum]; ++ph) > @@ -1207,12 +1223,21 @@ rtld_setup_main_map (struct link_map *main_map) > if (main_map->l_map_start > mapstart) > main_map->l_map_start = mapstart; > > + if (main_map->l_contiguous && expected_load_address != 0 > + && expected_load_address != mapstart) > + main_map->l_contiguous = 0; > + > /* Also where it ends. */ > allocend = main_map->l_addr + ph->p_vaddr + ph->p_memsz; > if (main_map->l_map_end < allocend) > main_map->l_map_end = allocend; > if ((ph->p_flags & PF_X) && allocend > main_map->l_text_end) > main_map->l_text_end = allocend; > + > + /* The next expected address is the page following this load > + segment. */ > + expected_load_address = ((allocend + GLRO(dl_pagesize) - 1) > + & ~(GLRO(dl_pagesize) - 1)); > } > break; > > -- > 2.33.1 > LGTM. Reviewed-by: H.J. Lu Thanks. -- H.J.