From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id CAEDB3858426 for ; Fri, 6 Oct 2023 20:25:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CAEDB3858426 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696623945; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=ZNEoEgsgLdmKIxnwXqPWPiBW/O+7IdMkwzP0+ED9hYM=; b=X29/XuwNiiW/faU4Vxf7hV+6gMX1mVu2SDGPFm9tKSHvKLt5le6ihIKbdbwwCI8B7pceFu NrAqgOMZvfntFhrO3Qv+lKaQIvrH6YbD86OvIyXP0lAfflpvP7k84Bk+2uQoypxVrA80j/ Ebi3n2/6kSQUEmCMJTUIHMhSSRNXreY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-638-wqaKNA-mPFqNELEn04lJjA-1; Fri, 06 Oct 2023 16:25:43 -0400 X-MC-Unique: wqaKNA-mPFqNELEn04lJjA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E45CA187504A; Fri, 6 Oct 2023 20:25:42 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.8.97]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CB28D215670B; Fri, 6 Oct 2023 20:25:42 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.15.2/8.15.2) with ESMTP id 396KPgjW817370; Fri, 6 Oct 2023 16:25:42 -0400 From: DJ Delorie To: Adhemerval Zanella Netto Cc: libc-alpha@sourceware.org Subject: Re: RFC: system-wide default tunables In-Reply-To: Date: Fri, 06 Oct 2023 16:25:42 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: Adhemerval Zanella Netto writes: > The hwcap-related are still used for library selection, the original > intention of the ld.so.cache. What I am afraid is ld.so.cache start to > being an umbrella for different and unrelated settings. The alternative is to add an /etc/tunables.cache which would correspond to /etc/tunables.conf and/or /etc/tunables.conf.d/* On most systems (no files) that would add one unsuccessful stat() call. > It is not improper action that I worried, but security and performance > implications. For instance, the malloc tunables change performance depending > of the workload; a system-wide tunable might not the best option for all > programs. Yup. That would be a bad choice, but not an *invalid* choice. The more likely use of these tunables would be to alter the hwcaps logic to better match the hardware, or to enforce a "common minimum" hardware level for migratable programs. Or something else I can't imagine just yet ;-) > But I am assuming that system-wide has preference > over user-defined, which does not seems the case for your proposal. Since these are tunables and not, say, security settings, it seemed to make sense that a system-wide setting would be "new default" relative to the environment variable. An environment variable can be set for a specific program; a system-wide setting cannot. > I think what is not clear is if the idea is to mimic the 'security_level' > of tunable (which I intend to remove), in a way that we might have tunable > that might overridden and/or disabled by the process (through the envvar). I thought of that - being able to have flags for tunables that control those overrides et al - but decided against it. These are tunables, not security settings, and are more "advisory" than "mandatory", and I couldn't think of a legitimate reason to stop a program from having a program-specific tuning. >>>> * Values in ld.so.cache will be parsed but not range checked; that's >>>> dependent on what the glibc app expects. >>> >>> Importing the range information on tunable definition is straightforward, >> >> Unless it differs between applications. Or if the cache were generated >> with one version of glibc and the application runs with a different >> version. > > But in this case, and invalid/unknown value should be ignored if the program > is using a different glibc version. The case I was referring to would be if the *range* changed between versions. Same tunable name, different min/max. I don't think it would matter much to test the wrong range, but the app still needs to range check at runtime anyway. > Setting an invalid/unknown tunable still make little sense to me, it > means that it will always be ignored by some target if you are running > different glibc with different tunable setting support. And I don't > see why we should not make it explicit for the administrator. > > Maybe the best way is to make the range/key check as default and add an > option to force to set invalid values. I'm OK with warnings. On a system with multiple installed versions of glibc (no, don't ask me how ;) there might not be one common set of checks that works. >> That enum might change from version to version. We're already seeing >> enum-related issues with RHEL upgrades. > > Yes, Carlos has brought the awk sorting problem. I think this is fixable > (maybe porting the tunables generation to python, run the sysdeps search > in a predictable way, set enum value based on tunable ordering) and we can > add test to check if tunable enum changes over releases. > > I still think this is simpler than data structure your are proposing, and > with less performance issues. But I don't have a strong preference. If we store the enums, and *also* store the tunable name, we could use the enum for lookup but also strcmp to validate that it's the correct one. >>>> * I'm not going to try to add some "syntax" to specify if a tunable is >>>> overridable or not; this is a simple default-only change. >>> >>> How should we handle the envvar GLIBC_TUNABLEs in the presence of a system-wide >>> tunable? >> >> The variable overrides the cache. > > Right. Do we allow security opt-in option as well? I am asking because > in this case, it is expected that the system-wide should not be overridden. If a tunable needs to be ignored for security reasons, I would assume the system-wide default would be left alone but the environment variable would be ignored. I do not expect a case where a system-wide tunable should become "sticky" and block the environment variable in a non-security context. This assumes that a correct tunable setting is required for secure/proper operation; if this is not the case, the program is at fault ;-) because it's not just "tuning" at that point. >> Er, isn't that the environment variable? >> > > It is a easier way to configure per-process tunable, it avoid messing with FS > that either are mounted RO or do not allow adding wrappers to setup GLIBC_TUNABLES. > > Also, my idea is to just remove the tunable setting for setuid/setguid; so > per-process is a way to setup specific rules for security sensitive processes > (assuming that we will support non-overriden security tunables). So /etc/tunables.conf would have something like this? [/bin/bash] glibc.malloc.max_arenas=1 This is the type of complexity I wanted to avoid. We could, in theory, add an ELF section for embedding tunables into an executable image, but that's outside my scope.