Message ID | 20230313190627.2000578-1-adhemerval.zanella@linaro.org |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 92A2C3858291 for <patchwork@sourceware.org>; Mon, 13 Mar 2023 19:06:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 92A2C3858291 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678734415; bh=E/sH5fL2k0kvYtMi6LJZ4SVoXwKXK2o5TXmU3o8RpCA=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=wPAd2DfaXlEAUlXar8AXbe73o/sxdWQ4HIEeMlcgrJZm+GgMRopqwUrV7CVUV2FmS 7NbdeSERvNQOPsuf7fe+tTmBrPQikN304/v2sTWDXVZtpBYxxNtW6+ZhbHLyX0y6Wq q3nWKK+dkVVLGz2Djq34iwsKwZ1m8dtc6Fe48Qw0= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) by sourceware.org (Postfix) with ESMTPS id 2032A3858D1E for <libc-alpha@sourceware.org>; Mon, 13 Mar 2023 19:06:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2032A3858D1E Received: by mail-oo1-xc36.google.com with SMTP id n27-20020a4ad63b000000b005252709efdbso1982360oon.4 for <libc-alpha@sourceware.org>; Mon, 13 Mar 2023 12:06:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678734392; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=E/sH5fL2k0kvYtMi6LJZ4SVoXwKXK2o5TXmU3o8RpCA=; b=Dj64p1+S2PsHIn5VC86ht0gzec7Jggfm6X4dNhRO1lL9/hNqm1LhFM9uIJ560DintJ XakLSMPw54vR4ZC/aTBVqXOA8tpKv5PkUaCAc3BpQnGb+k8Q8bvea0OU3yzLL5S4x2WX GDy+TJmdBwsUJrXIw5K5lGlzLRcsm3HLS1VE3EgTIRQPBToXfiHthI3CHeRfpUDEcW8o 8jrDLplQkiLLESVQb0QZhNt8iqLWLs1vj62lxBwww9duxmLB6x73VdnRxMeid889oaSR LdomHupLhVlZYhg4HEs1OKAf5wFS1fyKfLwGJa0vieFLuyXDktbRNZ//BSWLSUOmZJBT DXuw== X-Gm-Message-State: AO0yUKUbFQ1F4mvnaSSv9+EcWmCID0Pqg0gP5+M7oA6Nx1eiwW9Gfvw2 iNcqKd1fX2FnNm7r4erkF9JcAklBBvHULVqu0ju8HA== X-Google-Smtp-Source: AK7set/3hj9dS3bYPMDTqBednvE8OHgk0D6KcCAWAzke0QuAwXvD+Wi0CCs8fc60Pya/DY+VGbtnxg== X-Received: by 2002:a4a:88ae:0:b0:525:5c24:fa55 with SMTP id j43-20020a4a88ae000000b005255c24fa55mr5834585ooa.2.1678734391690; Mon, 13 Mar 2023 12:06:31 -0700 (PDT) Received: from mandiga.. ([2804:1b3:a7c0:544b:9bad:e673:fbfa:30eb]) by smtp.gmail.com with ESMTPSA id d21-20020a056830045500b0068bb73bd95esm297122otc.58.2023.03.13.12.06.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Mar 2023 12:06:30 -0700 (PDT) To: libc-alpha@sourceware.org, Siddhesh Poyarekar <siddhesh@gotplt.org>, Florian Weimer <fweimer@redhat.com> Subject: [PATCH 0/2] Make tunable a default feature Date: Mon, 13 Mar 2023 16:06:25 -0300 Message-Id: <20230313190627.2000578-1-adhemerval.zanella@linaro.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Adhemerval Zanella <adhemerval.zanella@linaro.org> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Make tunable a default feature
|
|
Message
Adhemerval Zanella Netto
March 13, 2023, 7:06 p.m. UTC
It is enabled as default since 2.26, some features option require it (such as hwcap mask, huge pages support, and lock elisition tuning), and assuming its support also simplifies the build permutation. Adhemerval Zanella (2): elf: Remove glibc.rtld.dynamic_sort tunable Remove --enable-tunables configure option INSTALL | 19 --- Makeconfig | 4 - NEWS | 3 + config.h.in | 3 - config.make.in | 1 - configure | 17 --- configure.ac | 10 -- elf/Makefile | 8 +- elf/dl-cache.c | 2 +- elf/dl-hwcaps.h | 11 -- elf/dl-sort-maps.c | 139 +----------------- elf/dl-support.c | 15 -- elf/dl-tls.c | 6 - elf/dl-tunables.h | 35 ++--- elf/dl-tunables.list | 9 -- elf/dl-usage.c | 8 +- elf/dso-sort-tests-1.def | 15 +- elf/dso-sort-tests-2.def | 10 +- elf/rtld.c | 23 +-- elf/tst-env-setuid-tunables.c | 11 -- elf/tst-rtld-list-tunables.exp | 1 - gmon/gmon.c | 12 +- malloc/Makefile | 2 - malloc/arena.c | 118 +-------------- malloc/malloc-check.c | 8 - malloc/malloc.c | 14 +- manual/install.texi | 19 --- manual/tunables.texi | 13 -- nptl/pthread_mutex_conf.c | 4 +- nptl/tst-mutex8.c | 2 - scripts/build-many-glibcs.py | 1 - sysdeps/generic/ldsodefs.h | 17 --- sysdeps/generic/unsecvars.h | 8 +- sysdeps/mach/hurd/dl-sysdep.c | 3 - sysdeps/nptl/dl-tls_init_tp.c | 2 - sysdeps/nptl/pthreadP.h | 4 - sysdeps/nptl/pthread_early_init.h | 2 - sysdeps/nptl/pthread_mutex_conf.h | 8 - sysdeps/powerpc/cpu-features.c | 9 +- sysdeps/s390/cpu-features.c | 14 +- sysdeps/sparc/sparc32/dl-machine.h | 5 +- sysdeps/unix/sysv/linux/Makefile | 4 +- .../unix/sysv/linux/aarch64/cpu-features.c | 6 - sysdeps/unix/sysv/linux/dl-sysdep.c | 3 - .../unix/sysv/linux/powerpc/elision-conf.c | 8 +- sysdeps/unix/sysv/linux/s390/elision-conf.c | 8 +- sysdeps/unix/sysv/linux/x86/elision-conf.c | 8 +- sysdeps/unix/sysv/linux/x86_64/64/Makefile | 2 - sysdeps/x86/Makefile | 10 -- sysdeps/x86/cacheinfo.h | 8 +- sysdeps/x86/cpu-features.c | 24 +-- sysdeps/x86/cpu-tunables.c | 45 +++--- sysdeps/x86/dl-cacheinfo.h | 10 -- sysdeps/x86_64/Makefile | 2 - 54 files changed, 80 insertions(+), 673 deletions(-)
Comments
On 2023-03-13 15:06, Adhemerval Zanella wrote: > It is enabled as default since 2.26, some features option require it > (such as hwcap mask, huge pages support, and lock elisition tuning), > and assuming its support also simplifies the build permutation. from a historical perspective, there was not just the question of enabling tunables but also providing multiple ways to read tunables, each having its own parser. That is why there's a 'valstring' as an option for --enable-tunables. Over the years there haven't really been any other ideas to read tunables. There's the idea of systemwide tunables through, e.g. ld.so.conf that we'd like to have at some point, but that is more effective alongside valstring than as an either-or feature. There's also conceivably a use case for having only systemwide tunables without any valstring override but maybe that should get supported when it's actually needed by someone. So in summary, I'm not aware of anybody using --disable-tunables, so I'm not opposed to removing the configure flag altogether and simplifying the code. Hopefully if someone is using it they'll come forward before this patchset gets accepted. Thanks, Sid
On 14/03/23 15:02, Siddhesh Poyarekar wrote: > On 2023-03-13 15:06, Adhemerval Zanella wrote: >> It is enabled as default since 2.26, some features option require it >> (such as hwcap mask, huge pages support, and lock elisition tuning), >> and assuming its support also simplifies the build permutation. > > from a historical perspective, there was not just the question of enabling tunables but also providing multiple ways to read tunables, each having its own parser. That is why there's a 'valstring' as an option for --enable-tunables. Does it really make sense to provide such option, where multiple distributions would support different tunables? I don't this much as way forward, it would require additional effort to document, along with some prudence to make it concise. And its has the inherent problem of fragmentation. > > Over the years there haven't really been any other ideas to read tunables. There's the idea of systemwide tunables through, e.g. ld.so.conf that we'd like to have at some point, but that is more effective alongside valstring than as an either-or feature. For ld.so cache, the program can use DF_1_NODEFLIB to either avoid its costs or not use system cache (if its uses RUNPATH). I think a system-wide tunable would require a similar scheme, where the program can opt-out if required. > > There's also conceivably a use case for having only systemwide tunables without any valstring override but maybe that should get supported when it's actually needed by someone. So in summary, I'm not aware of anybody using --disable-tunables, so I'm not opposed to removing the configure flag altogether and simplifying the code. Hopefully if someone is using it they'll come forward before this patchset gets accepted. Alright, so I think it should be good to setup this for next release then.
On 2023-03-15 16:05, Adhemerval Zanella Netto wrote: > On 14/03/23 15:02, Siddhesh Poyarekar wrote: >> On 2023-03-13 15:06, Adhemerval Zanella wrote: >>> It is enabled as default since 2.26, some features option require it >>> (such as hwcap mask, huge pages support, and lock elisition tuning), >>> and assuming its support also simplifies the build permutation. >> >> from a historical perspective, there was not just the question of enabling tunables but also providing multiple ways to read tunables, each having its own parser. That is why there's a 'valstring' as an option for --enable-tunables. > > Does it really make sense to provide such option, where multiple distributions > would support different tunables? I don't this much as way forward, it would require > additional effort to document, along with some prudence to make it concise. And > its has the inherent problem of fragmentation. Yeah I agree it doesn't make a lot of sense anymore; I think we made it like that to bake in some flexibility for use cases we weren't aware of yet. I mentioned it here in the hope that folks who were part of the conversation then and have better memory than I would be able to pitch in with additional context :) >> Over the years there haven't really been any other ideas to read tunables. There's the idea of systemwide tunables through, e.g. ld.so.conf that we'd like to have at some point, but that is more effective alongside valstring than as an either-or feature. > > For ld.so cache, the program can use DF_1_NODEFLIB to either avoid its costs or > not use system cache (if its uses RUNPATH). I think a system-wide tunable would > require a similar scheme, where the program can opt-out if required. Actually I was thinking of systemwide tunables as the canonical way to apply default rules that *won't* get overridden by users. That could allow users to, e.g. lock down memory tagging on a systemwide basis if needed, or put a hard upper or lower limit on some of the malloc tunables. The scheme would work similar to rlimit, but it shouldn't be misunderstood to be a security feature in that sense; applications can always work around a malloc tunable limit by rolling their own allocator. >> There's also conceivably a use case for having only systemwide tunables without any valstring override but maybe that should get supported when it's actually needed by someone. So in summary, I'm not aware of anybody using --disable-tunables, so I'm not opposed to removing the configure flag altogether and simplifying the code. Hopefully if someone is using it they'll come forward before this patchset gets accepted. > > Alright, so I think it should be good to setup this for next release then. Yep. I don't know how we can make this more widely visible before we drop the option. Maybe @gnutools could tweet about it. If there are no major objections in the next week or so I'll do a proper review of the patchset. Thanks, Sid
On 17/03/23 08:15, Siddhesh Poyarekar wrote: > On 2023-03-15 16:05, Adhemerval Zanella Netto wrote: >> On 14/03/23 15:02, Siddhesh Poyarekar wrote: >>> On 2023-03-13 15:06, Adhemerval Zanella wrote: >>>> It is enabled as default since 2.26, some features option require it >>>> (such as hwcap mask, huge pages support, and lock elisition tuning), >>>> and assuming its support also simplifies the build permutation. >>> >>> from a historical perspective, there was not just the question of enabling tunables but also providing multiple ways to read tunables, each having its own parser. That is why there's a 'valstring' as an option for --enable-tunables. >> >> Does it really make sense to provide such option, where multiple distributions >> would support different tunables? I don't this much as way forward, it would require >> additional effort to document, along with some prudence to make it concise. And >> its has the inherent problem of fragmentation. > > Yeah I agree it doesn't make a lot of sense anymore; I think we made it like that to bake in some flexibility for use cases we weren't aware of yet. I mentioned it here in the hope that folks who were part of the conversation then and have better memory than I would be able to pitch in with additional context :) > >>> Over the years there haven't really been any other ideas to read tunables. There's the idea of systemwide tunables through, e.g. ld.so.conf that we'd like to have at some point, but that is more effective alongside valstring than as an either-or feature. >> >> For ld.so cache, the program can use DF_1_NODEFLIB to either avoid its costs or >> not use system cache (if its uses RUNPATH). I think a system-wide tunable would >> require a similar scheme, where the program can opt-out if required. > > Actually I was thinking of systemwide tunables as the canonical way to apply default rules that *won't* get overridden by users. That could allow users to, e.g. lock down memory tagging on a systemwide basis if needed, or put a hard upper or lower limit on some of the malloc tunables. The scheme would work similar to rlimit, but it shouldn't be misunderstood to be a security feature in that sense; applications can always work around a malloc tunable limit by rolling their own allocator. I think it might make sense for tunables that change the program semantic, such as security hardening; although I don't think it really fits for performance oriented ones (such malloc or pthread tuning). So maybe we can define a global file format where the administrator can set where setuid binaries can use it, and if uses can overwrite it. My initial idea would be something quite simple, similar to sysctl.conf: $ cat /etc/glibc-tunables.conf # tunable setuid override glibc.cpu.hwcaps=-AVX512F,-AVX2 1 0 glibc.malloc.trim_threshold=128 1 1 glibc.malloc.tcache_count=2 0 1 And I was thinking about an DF_1_NODEFLIB analogous so the program can opt-out any performance or behavior difference any tunable might incur. Although with your idea of enforceable tunable, I think it does not make much sense. > >>> There's also conceivably a use case for having only systemwide tunables without any valstring override but maybe that should get supported when it's actually needed by someone. So in summary, I'm not aware of anybody using --disable-tunables, so I'm not opposed to removing the configure flag altogether and simplifying the code. Hopefully if someone is using it they'll come forward before this patchset gets accepted. >> >> Alright, so I think it should be good to setup this for next release then. > > Yep. I don't know how we can make this more widely visible before we drop the option. Maybe @gnutools could tweet about it. If there are no major objections in the next week or so I'll do a proper review of the patchset. > > Thanks, > Sid
On 2023-03-20 12:59, Adhemerval Zanella Netto wrote: > I think it might make sense for tunables that change the program semantic, such > as security hardening; although I don't think it really fits for performance > oriented ones (such malloc or pthread tuning). So maybe we can define a global Administrative level performance tuning defaults for setuid binaries? > file format where the administrator can set where setuid binaries can use it, > and if uses can overwrite it. My initial idea would be something quite simple, > similar to sysctl.conf: Yes, I think Florian suggested reusing ld.so.conf instead. I don't have a strong preference either way so y'all can fight that one out - potato potato ;) > And I was thinking about an DF_1_NODEFLIB analogous so the program can opt-out > any performance or behavior difference any tunable might incur. Although with > your idea of enforceable tunable, I think it does not make much sense. Yeah an ELF flag to override all tunables seems counter to the whole idea, but ELF flags to override specific tunables may make sense. E.g. memory tagging enabled by default in the system and a program built with DF_NO_MEMTAG overrides that systemwide setting. Sid
On 20/03/23 20:15, Siddhesh Poyarekar wrote: > On 2023-03-20 12:59, Adhemerval Zanella Netto wrote: >> I think it might make sense for tunables that change the program semantic, such >> as security hardening; although I don't think it really fits for performance >> oriented ones (such malloc or pthread tuning). So maybe we can define a global > > Administrative level performance tuning defaults for setuid binaries? I was thinking more of opt-in security features (such as mte_state on aarch64), although it might fit better on some ABI extension (such as done by cet). > >> file format where the administrator can set where setuid binaries can use it, >> and if uses can overwrite it. My initial idea would be something quite simple, >> similar to sysctl.conf: > > Yes, I think Florian suggested reusing ld.so.conf instead. I don't have a strong preference either way so y'all can fight that one out - potato potato ;) Did he mean add the tunable information on ld.so.conf or using a similar scheme where the file is preprocessed by a tool so loader can just mmap a file without the need any parsing? For later, I don't have a strong opinion. I assume that a global tunable won't be a default configuration, like loader cache; and parsing should really easy (it a ini like file). > >> And I was thinking about an DF_1_NODEFLIB analogous so the program can opt-out >> any performance or behavior difference any tunable might incur. Although with >> your idea of enforceable tunable, I think it does not make much sense. > > Yeah an ELF flag to override all tunables seems counter to the whole idea, but ELF flags to override specific tunables may make sense. E.g. memory tagging enabled by default in the system and a program built with DF_NO_MEMTAG overrides that systemwide setting. The issue of a per-tunable flag is it will require to settle a minimum ABI for tunable, or adding a ELF extension with a string blob that is only understable by an specific glibc version. I am not sure, maybe we can it only if required.
On 2023-03-22 10:40, Adhemerval Zanella Netto wrote: > > > On 20/03/23 20:15, Siddhesh Poyarekar wrote: >> On 2023-03-20 12:59, Adhemerval Zanella Netto wrote: >>> I think it might make sense for tunables that change the program semantic, such >>> as security hardening; although I don't think it really fits for performance >>> oriented ones (such malloc or pthread tuning). So maybe we can define a global >> >> Administrative level performance tuning defaults for setuid binaries? > > I was thinking more of opt-in security features (such as mte_state on aarch64), > although it might fit better on some ABI extension (such as done by cet). Yeah, that too. >>> file format where the administrator can set where setuid binaries can use it, >>> and if uses can overwrite it. My initial idea would be something quite simple, >>> similar to sysctl.conf: >> >> Yes, I think Florian suggested reusing ld.so.conf instead. I don't have a strong preference either way so y'all can fight that one out - potato potato ;) > > Did he mean add the tunable information on ld.so.conf or using a similar scheme > where the file is preprocessed by a tool so loader can just mmap a file without > the need any parsing? > > For later, I don't have a strong opinion. I assume that a global tunable won't > be a default configuration, like loader cache; and parsing should really easy > (it a ini like file). Just the former IIRC, i.e. extending ld.so.conf to add a section for systemwide tunables. >> >>> And I was thinking about an DF_1_NODEFLIB analogous so the program can opt-out >>> any performance or behavior difference any tunable might incur. Although with >>> your idea of enforceable tunable, I think it does not make much sense. >> >> Yeah an ELF flag to override all tunables seems counter to the whole idea, but ELF flags to override specific tunables may make sense. E.g. memory tagging enabled by default in the system and a program built with DF_NO_MEMTAG overrides that systemwide setting. > > The issue of a per-tunable flag is it will require to settle a minimum ABI for > tunable, or adding a ELF extension with a string blob that is only understable > by an specific glibc version. I am not sure, maybe we can it only if required. We shouldn't need a flag for *every* tunable, only those that would have practical benefit from having ELF overrides, e.g. those that control architecture-specific features. That is, the ELF flag should not be tied to a tunable, but a tunable could change behaviour based on an ELF flag. Sid
On 22/03/23 12:21, Siddhesh Poyarekar wrote: > On 2023-03-22 10:40, Adhemerval Zanella Netto wrote: >> >> >> On 20/03/23 20:15, Siddhesh Poyarekar wrote: >>> On 2023-03-20 12:59, Adhemerval Zanella Netto wrote: >>>> I think it might make sense for tunables that change the program semantic, such >>>> as security hardening; although I don't think it really fits for performance >>>> oriented ones (such malloc or pthread tuning). So maybe we can define a global >>> >>> Administrative level performance tuning defaults for setuid binaries? >> >> I was thinking more of opt-in security features (such as mte_state on aarch64), >> although it might fit better on some ABI extension (such as done by cet). > > Yeah, that too. > >>>> file format where the administrator can set where setuid binaries can use it, >>>> and if uses can overwrite it. My initial idea would be something quite simple, >>>> similar to sysctl.conf: >>> >>> Yes, I think Florian suggested reusing ld.so.conf instead. I don't have a strong preference either way so y'all can fight that one out - potato potato ;) >> >> Did he mean add the tunable information on ld.so.conf or using a similar scheme >> where the file is preprocessed by a tool so loader can just mmap a file without >> the need any parsing? >> >> For later, I don't have a strong opinion. I assume that a global tunable won't >> be a default configuration, like loader cache; and parsing should really easy >> (it a ini like file). > > Just the former IIRC, i.e. extending ld.so.conf to add a section for systemwide tunables. I am not very found of mixing too different libc facilities in the same config file and the syntax won't be the same and there are two different > >>> >>>> And I was thinking about an DF_1_NODEFLIB analogous so the program can opt-out >>>> any performance or behavior difference any tunable might incur. Although with >>>> your idea of enforceable tunable, I think it does not make much sense. >>> >>> Yeah an ELF flag to override all tunables seems counter to the whole idea, but ELF flags to override specific tunables may make sense. E.g. memory tagging enabled by default in the system and a program built with DF_NO_MEMTAG overrides that systemwide setting. >> >> The issue of a per-tunable flag is it will require to settle a minimum ABI for >> tunable, or adding a ELF extension with a string blob that is only understable >> by an specific glibc version. I am not sure, maybe we can it only if required. > > We shouldn't need a flag for *every* tunable, only those that would have practical benefit from having ELF overrides, e.g. those that control architecture-specific features. > > That is, the ELF flag should not be tied to a tunable, but a tunable could change behaviour based on an ELF flag. I think it might be an option if the flag is opaque to ELF itself, like a string that glibc would parse. But I don't have a strong preference. I still think the simplest solution would to have a textual glibc-tunables.conf similar to sysctl.conf.