From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2d.google.com (mail-oa1-x2d.google.com [IPv6:2001:4860:4864:20::2d]) by sourceware.org (Postfix) with ESMTPS id 0B7113858414 for ; Fri, 10 Feb 2023 22:23:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0B7113858414 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-16cc1e43244so4243002fac.12 for ; Fri, 10 Feb 2023 14:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ckq1tueAk1t8OqJvW00eDQBJlJqAg5CqE/4P8lcC7cU=; b=EFk/kPc+M2DFUiBNNWv76nACYNtvtpcwmutpPqFa1ZtfgdZtrwtjS0aaF4vu7cXBDb XOLmf77hIW6k48QQSLteIxvpEi8kUFK+JZLznXHv7MKNTcZfSIFzvn5OJvg5khzz/jxJ bfybctbVPGrxANaYlwv7xOtRjuS/FrgslJINHWS0EkKTiHbiW9Jtp4NG/FkKnJv+ZW/N CSxJ8C8i8KUFXm2c+d96z1Tdy5bepOLw9t5adfNJerTwAzldiTlpVdwCtMMRo4/x6bn9 4It63pxvnaUXInmHCq+fKjcnl03YajT+TPpkGdpTSl9/bN4GJG2afdHYBQLp1noeN0Zw pucg== 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:subject:date:message-id :reply-to; bh=ckq1tueAk1t8OqJvW00eDQBJlJqAg5CqE/4P8lcC7cU=; b=Ujkos1cEUj2Rmvl4j1VS3L1KXPUhWMd9asvm8Sf2HwqZT0Hosic7muMDyJuZE0lFa1 W9o3yFoieJiSd8Zz/ieEqR+43504BN3qDV7hvGH+l0ptmUNnLiFcr9rQDRrdLi9rCuTN 5ImrRI+PgTrwCNWYEnLiR68y3AwFp+CY6uLezxRndnCzPRPP+Skinrf7y2UhGmT5siVC 603nGhT55nW5FPS9An0GbmCJS34im6dKvZWnBZehGaVQx+o04mkm09h9MDBIMHYiW7vN YnSzqMz+0z/jAR9iUp6gEYTpSYXs6xQf0i4JCvVHux0/ELIn2pzH26rvXYDiIH+fEXok 7IvQ== X-Gm-Message-State: AO0yUKWxL4Ncb5D8Z4K0Xud3125LHoN65PDzx5/JBVRHannh5d6sGHKw Kcrru3MD/4vM3+D7N0ezPYtCwtJLHT9P57hdGK9ICRTzAKY= X-Google-Smtp-Source: AK7set8rwIir1o7Xx4NZGTr7xHGDk2B4aoHoo4YKPhKy3fN8xb5wvbGl4nCTefdaM2gKfPZZC4JtVIgCmY8ZjTp7WLc= X-Received: by 2002:a05:6870:10cf:b0:16a:839d:8ce5 with SMTP id 15-20020a05687010cf00b0016a839d8ce5mr2691558oar.298.1676067811329; Fri, 10 Feb 2023 14:23:31 -0800 (PST) MIME-Version: 1.0 References: <20230126172256.829709-1-hjl.tools@gmail.com> <87k00qkitj.fsf@oldenburg.str.redhat.com> <202f0385-86bd-fa4a-3a44-804d9d01ecaf@redhat.com> In-Reply-To: <202f0385-86bd-fa4a-3a44-804d9d01ecaf@redhat.com> From: "H.J. Lu" Date: Fri, 10 Feb 2023 14:22:55 -0800 Message-ID: Subject: Re: [PATCH] x86-64: Restore LD_PREFER_MAP_32BIT_EXEC support [BZ #28656] To: "Carlos O'Donell" Cc: Florian Weimer , "H.J. Lu via Libc-alpha" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3016.0 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Feb 10, 2023 at 1:54 PM Carlos O'Donell wrote: > > On 2/10/23 11:50, H.J. Lu wrote: > > On Thu, Feb 9, 2023 at 6:35 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 Intel Golden Cove CPU (see the > >>> "Misprediction for Branches >2GB" section in Intel 64 and IA-32 > >>> Architectures Optimization Reference Manual.) 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 in shared > >>> libraries 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. LD_PREFER_MAP_32BIT_EXEC works only between > >>> shared libraries or between shared libraries and executables with > >>> addresses below 2GB. PIEs are usually mapped above 4GB by the kernel. > >> > >> I still think we should fix this in the kernel, using MAP_DENYWRITE as a > >> hint for placement. This way, it's easier to turn it on unconditionally > >> for the whole system because the lower 4 GiB will not be polluted by > >> code mappings. > >> > > > > Kernel MM change may take a long time and this mitigation may only be needed > > for a few specific applications. On the other hand, it is simpler to > > use tunable > > instead. > > I tend to agree with you here that a Kernel MM change is going to take too long and may > be possibly fragile. > > I would like to see this use a tunable with an alias. Done: https://patchwork.sourceware.org/project/glibc/patch/20230210222142.17943-1-hjl.tools@gmail.com/ > Note that the Linux man pages continue to document LD_PREFER_MAP_32BIT_EXEC :-) > > -- > Cheers, > Carlos. > Thanks. -- H.J.