From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id BEF0638582A3 for ; Fri, 5 Aug 2022 21:54:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BEF0638582A3 Received: by mail-pl1-x62e.google.com with SMTP id m2so3741029pls.4 for ; Fri, 05 Aug 2022 14:54:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=Jm8me7l+RcAmyeayXyvQ3kfdZangRFsxYrmnbs5OvMo=; b=afiU4RW77bZKDGd4QeKH4xiqKcheXo4PEKWHTmmdDH1SxNxsUJFDckhiABu9DnDypc fbpVe06Tin2hw4ADG/sNJSmyod6jfKtKLv4RNpKoaOJ52Os/7nDVFqWROkgTbQhC1D6S gua2lvQcQN4e5Mq/C25X97GbUElRHhNP3n9+06511zgb9+Ytj1EJwmVmnz72b2P7mQ+5 Ue92NAvnW8WdFUuG4flf21ZMLnHcUIb7AxZex6UYWPJ1U4BgmsCGCNRgjL1Hx6641CVq DcUcZWA/9ofSac4KflKfkQS6g0AMcNOurfOspYBWdvGfJ6x7Gaq0hlvKjAw1Hb57ntwV foOg== X-Gm-Message-State: ACgBeo2P5lw3WPL8xH3s3+WMSzqz7/XknLiPLUTAOcO10qHhahxwWGQX FMdmdHNmhyAkFZqEtCGLr6g74BCjGOT8bCw2Zo8X2a5g2xI= X-Google-Smtp-Source: AA6agR5lrbqpLxKODvQPfV1MD6uJAXAshya6Q2fhN5DWO8k7hj2CIeiKjkrGExxYGM0lwCcAQSw1Aw64/CauWc3Z8rY= X-Received: by 2002:a17:90a:c690:b0:1f5:858e:f538 with SMTP id n16-20020a17090ac69000b001f5858ef538mr5862575pjt.10.1659736439559; Fri, 05 Aug 2022 14:53:59 -0700 (PDT) MIME-Version: 1.0 References: <20220801195150.2160919-1-hjl.tools@gmail.com> <87o7x3847o.fsf@oldenburg.str.redhat.com> In-Reply-To: <87o7x3847o.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Fri, 5 Aug 2022 14:53:23 -0700 Message-ID: Subject: Re: [PATCH] x86-64: Restore LD_PREFER_MAP_32BIT_EXEC support [BZ #28656] To: Florian Weimer Cc: "H.J. Lu via Libc-alpha" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.5 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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 05 Aug 2022 21:54:02 -0000 On Tue, Aug 2, 2022 at 1:00 AM Florian Weimer wrote: > > * H. J. Lu via Libc-alpha: > > > Crossing 2GB boundaries with indirect calls and jumps can use more > > branch prediction resources on several Intel CPUs. There is visible > > performance improvement on workloads with many PLT calls when executable > > and shared libraries are mmapped below 2GB. Add the Prefer_MAP_32BIT_EXEC > > bit so that mmap will try to map executable or denywrite pages with > > MAP_32BIT first. > > > > NB: Prefer_MAP_32BIT_EXEC reduces bits available for address space > > layout randomization (ASLR), which is always disabled for SUID programs > > and can only be enabled by setting environment variable, > > LD_PREFER_MAP_32BIT_EXEC. > > If the performance benefits are significant, this should be handled at > the kernel level. Only the kernel can put the main program, ld.so and > the vDSO into the same 2GB window (presumably with the main program at > the top, so that the heap can grow almost indefinitely). ld.so and vDSO aren't performance sensitive. But we need to handle PIE. > For mapping shared objects, we can give the kernel a hint that they will > eventually contain an executable mapping. If the kernel could reuse > MAP_DENYWRITE for that, no glibc changes would be needed after all. > > Doing this is in glibc is only a very partial solution, and so I'd > appreciate if it could be fixed properly in the kernel. > There is no easy way for kernel to selectively mmap PIE with MAP_32BIT. Can ld.so re-exec PIE with "ld.so PIE" so that ld.so can mmap PIE with MAP_32BIT? -- H.J.