From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from antelope.elm.relay.mailchannels.net (antelope.elm.relay.mailchannels.net [23.83.212.4]) by sourceware.org (Postfix) with ESMTPS id 5F8FA3858D3C for ; Wed, 22 Mar 2023 15:21:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F8FA3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id AB83F641343; Wed, 22 Mar 2023 15:21:10 +0000 (UTC) Received: from pdx1-sub0-mail-a306.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3C85464102E; Wed, 22 Mar 2023 15:21:10 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1679498470; a=rsa-sha256; cv=none; b=xB+ndGUFxXyr0OnPrLKw5hKjdoA8D7yK+0bVoWfYw5FhAk6XO6jBb6uX8HvpoWdoMxxnFr P8E6gcj5CMlN7r/Kh8TonMgIwnANfo2zLGU47okb4p+axGZwKEOyoVs4Un7tZWKUVa9+Ls EI9pF4hibNmkVWT0n+E4rWkSR/n7e+eP4D3p/SU9P/gOXhWiwzrDsOQj23OBKP9PrnwEbV l4PfSXH/zigzNc4R1nGgdqypvBueFzUlAl3yzq0rg6zuvwxYBjKLMMmeLL4RNvOTv0M00N a+i6sLpeVMw8EY9ykMZiKbYgg3dF+voan+z012z776cuG3F7bN+48Mss05X8sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1679498470; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=r2K2S3M1R6McOY3HF31AdvkyZtENmTT5nQRLwxtXNLc=; b=us2l6KkEiG7MTFFzRAoL9N566JovOZYTeZrhJAzC83Eivo5wkhVN34iKMs1ppQ0xuG9OFR qqN0nJZwTqsKDNHW1h1Ry6+BpJ851/WhDiaFxM2W7zW5hU8MiCRdHJ8VjOs5NoSFFtBs2D NtH1MyINDKiZIH4pGjGZ7axJ6frEGYpwlZBxQxTymqSmSCZJETJjPqBZTs2K43qaGbxZjY nLpelSNQ5MF3ENwP0dzSLgwiwzZZ1eBrMFdDcgxJShYLm/R/1ORX4Yr5LeLTrX4cR958An fVWj8kEn8gNIeInHKPn63x+Pdc9AIjd/zyvZXSCqSgH0A8v7j5+6VH5c5RqnyQ== ARC-Authentication-Results: i=1; rspamd-9576589d-45m8g; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Cold-Harbor: 3b323c60173fbb71_1679498470494_1786094711 X-MC-Loop-Signature: 1679498470494:1569882906 X-MC-Ingress-Time: 1679498470493 Received: from pdx1-sub0-mail-a306.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.103.24.12 (trex/6.7.2); Wed, 22 Mar 2023 15:21:10 +0000 Received: from [192.168.0.182] (bras-vprn-toroon4834w-lp130-09-174-91-45-153.dsl.bell.ca [174.91.45.153]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a306.dreamhost.com (Postfix) with ESMTPSA id 4PhXHT4tJhz6m; Wed, 22 Mar 2023 08:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1679498470; bh=r2K2S3M1R6McOY3HF31AdvkyZtENmTT5nQRLwxtXNLc=; h=Date:Subject:To:From:Content-Type:Content-Transfer-Encoding; b=S5jT8PsfF5B4MfAWJG/dOsxvNjxeiX5wWsJSdvbPEepf/kK4Lcl3SYVxrRp3HYnxo R8ZTHBL/uosXyhXPP344V+f6P+ikZuUXyFwZd/US6C6AsmFjq7yyitDTNU2gB1EAXO Fw3W27j+tmZ6QUMbOHUFB6gixVBTNS55SN8yVQ6oURAVYuE+nCOzpTzZ/abpc+CvvI jtABj5hYBclsbsYU+Px5+GShMQgilJhWZWDdTscnzVAZP9KAMa6T7zk+jjLwVno1r2 LrIbePHkyFteRw8cP5h482MvO3GP+FNDSgMaNwSdaq+NYoGXGS1Pr7sCd+xHtVtehg WStQw8+GNfsPw== Message-ID: Date: Wed, 22 Mar 2023 11:21:08 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 0/2] Make tunable a default feature Content-Language: en-US To: Adhemerval Zanella Netto , 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: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3030.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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 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