From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id 5BDB23858C52 for ; Wed, 22 Mar 2023 17:58:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5BDB23858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x236.google.com with SMTP id s8so4392677ois.2 for ; Wed, 22 Mar 2023 10:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1679507885; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=NVyriZyrPJub/vgCdkutZTibJ74uMFWJvGQvnIZcX5M=; b=T341b0WgsB3Nb2Ur1i2Mz8H8s8WxtTEzm6dQDGW2AdpGMmvEyBxHaJZUpt4xFXGSni 3MG3jz99EeqBFXoAyywEf+fR5hUJLerE2UfQOE/EGdrG7fo7UG3iJyTUeO3xAzEjv5AK BTcUQaewcF83ukbaz4DlW6CZJAB50NWXyhng1/G3aaYYcWwS8KLedTqnrm19vT42LhD1 vDoVL2LPMWM5oyfpXaRlpI8cujClKt0TLSqM3iYaHIVFsel/gI2LcumQvR9VFgT6zh3A D7LNfwmVw0BdSO4Mk5fjRcjr9Vu7n3XgMF7M4mUYCTD0NmrSST5btvcs5ah3xWb2g6HW BwBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679507885; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NVyriZyrPJub/vgCdkutZTibJ74uMFWJvGQvnIZcX5M=; b=DTeunCyIS9LbbcWPvV76HntYRW3yXtabjhNmC6yMkJKepu+pqQTnGPb+AQ/rTWabFl T6D1GKbVqXfDC8gU4Y40Jo5laP9X+SIUbWA9bJ73iRvITr7XlD+1nnMTU9g2W+tPNkwt rDGmehckjyithKna/tLUZEZvqDKJDMzVvSzs/ETW272y13fKV+GkGWhplLyKHQI+WEMb RPXluC25POMpaZolTCswK4O9pG+5O73eTD/uYEmDLPp6kwQNg09dJUp9kpQqJEG86Wiv 5eXmdoIzQt8Dbl+emB0kjzsP0Pi7uoRMHQiLymF5a91q5krliLA+Es+WwvEySDUFwoyW 5oFA== X-Gm-Message-State: AO0yUKW2Qv9aBegx2ksIeGWwCOZnB8lCdWFPhmygGhcn1L7I+UbAPDfJ 5EFc9FAwUKPTffvSrGinu/gNAA== X-Google-Smtp-Source: AK7set9ENI85oc+ZYPSqs3ue8t8Z4ZGus6N/EMNa0RSaGphsJx/9yZE2AeGZ0fWlfRogHx7jE2V4Jw== X-Received: by 2002:a05:6808:6ce:b0:387:f4b:ecad with SMTP id m14-20020a05680806ce00b003870f4becadmr1605553oih.8.1679507885519; Wed, 22 Mar 2023 10:58:05 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:c260:7930:b4e8:7389:be1f? ([2804:1b3:a7c0:c260:7930:b4e8:7389:be1f]) by smtp.gmail.com with ESMTPSA id d9-20020a05680813c900b0037d8dbe4308sm6164809oiw.48.2023.03.22.10.58.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Mar 2023 10:58:04 -0700 (PDT) Message-ID: <90941d49-5e39-1195-6820-7c79998ac085@linaro.org> Date: Wed, 22 Mar 2023 14:58:02 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 0/2] Make tunable a default feature Content-Language: en-US To: Siddhesh Poyarekar , libc-alpha@sourceware.org, Florian Weimer References: <20230313190627.2000578-1-adhemerval.zanella@linaro.org> <6511a415-b165-586d-b22d-80ff4eef0fa8@gotplt.org> <6b880467-e122-d2c5-f8d6-1394a4065753@gotplt.org> <9a6d86db-e799-0476-98cf-253a533d12ad@gotplt.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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 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.