From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id 44DA83858D3C for ; Wed, 22 Mar 2023 14:40:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 44DA83858D3C 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-ot1-x32e.google.com with SMTP id f17-20020a9d7b51000000b00697349ab7e7so10468738oto.9 for ; Wed, 22 Mar 2023 07:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1679496042; 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=H3US+BngCBWXbkraBv/9OrLLthMRu9LhW02e+I3XhmI=; b=qZoLjsNSzHwULDHsgrqrnjn1adHHlbS4zAY2JHftoHfQIGDvyBWkya9nz5gU0nuhUH PxK1oM1+ikN8HwqlvL706BzwDPHHpdDtsNsZnwXFSQk+B+5sAricv9VdPbNMRpnwHj+O WQGdDo2EAJtnxL2u5f9u5bcYL923tS+MCu3/47jfdiKewBTHbmnmJDWRATKgqToutGQ7 plvRgjdROiXqA74hHz9JIKP4HuLD4efIYPuqok6ZhjGwbGH6ovWnLzl3IX5aCiR8W9ka uoXev+w7kxpDPINcIBsecccJppkj/U/FLbb08DTfCUGCL6aEuRoHnSLu9h0Z8f6CdjZP OUtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679496042; 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=H3US+BngCBWXbkraBv/9OrLLthMRu9LhW02e+I3XhmI=; b=iXKl4xbNH3L2Np6JfLs0rl2ZivsDLRRS3ZIOAx2V6OzGSkLkFNIqNnVb6bY8W8eVIE tkiWq4PZIF0yHwYfP/wDn9Ii8SsAuZhTJ2x+MsugZ+6WJezOXDUpZj5vUF1VSq0uvleL uVjd0R8z1pn6E7udDCj6fhetJa+QOGinOKvv2Ftj4uP6/mhzLFrYRu3NYgfwU5sprg7b k6u/zvBzLkkpp6UnNboFLHubXq8ey7d/rgoXEi2jaP2lupKF3tJIyNecn/jWsEjlPtMl SvNydFbtBmtKD2OYnZNH7k+Y6Z9G4uM1j8fNvG8IgjiYLmktZyINnvXnXblBvIBDpzI9 kB6A== X-Gm-Message-State: AO0yUKViIRJdJrd8fZNXgdbIv8HN4ewmHkolRYS5leuyrN/rbhnV0usp jK7y1ExWGOxOAe7BjTybRZFEasLBseJohbBEoUw3yQ== X-Google-Smtp-Source: AK7set9X2CifzSNFBGmY/S4u8OMemIPaZmybsouWB4OtqFDCQSxB6qSKqdfUcbCwxzXoqZd8NKHSJg== X-Received: by 2002:a05:6830:1d0:b0:69f:a1e0:7993 with SMTP id r16-20020a05683001d000b0069fa1e07993mr822686ota.38.1679496042505; Wed, 22 Mar 2023 07:40:42 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:c260:d4b6:6c90:6159:ac3d? ([2804:1b3:a7c0:c260:d4b6:6c90:6159:ac3d]) by smtp.gmail.com with ESMTPSA id q204-20020a4a33d5000000b0053853156b5csm5857651ooq.8.2023.03.22.07.40.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Mar 2023 07:40:41 -0700 (PDT) Message-ID: Date: Wed, 22 Mar 2023 11:40:39 -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: <9a6d86db-e799-0476-98cf-253a533d12ad@gotplt.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 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 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.