From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id 055B4385414F for ; Fri, 6 Oct 2023 14:44:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 055B4385414F 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-pl1-x635.google.com with SMTP id d9443c01a7336-1c60f1a2652so17895425ad.0 for ; Fri, 06 Oct 2023 07:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696603457; x=1697208257; darn=sourceware.org; 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=YB6Hkdzykqc6qzz6rScHyvDGxnZCKlzR+lV17bKr6tE=; b=HUIMNOAL1jjm5KmzZkx/PFXkBdMNFM5eQyqQPG5XwRIwiqv8s14Y1wsGec+LtS25xf LFCYCexGVOmXPIP/IyC53QVQyzo1kGcBeAOqRlB+e0tg2/bOD+crpVUqUd3+3tM403IV OHm6WLgT+BnhlFD36zNaOFMD6ZwdQdFEs8orfps6iqHucR1GR03cSK1L0Vub77LeMaSt ljMt740mtJaY9Z3eznwCfQ0VYaBAKMgF5o9r4lUqsOvQVWmYbYgn1klMHGu7f1G4+zQf mjRA4kiIp5WptzDpAeAOnE+DwfVlQpl8w5D14sf1Ou4PNrkP6NwN0IeCwAo75ifB5p7I NtuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696603457; x=1697208257; 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=YB6Hkdzykqc6qzz6rScHyvDGxnZCKlzR+lV17bKr6tE=; b=ZO13xpcrMCOnwI3BEQzwlApSKDY9v87xQXpQStLE6SvTPSuKkjVt1i6xxjVpXCRt5Z DwpQQwzxhhrsAFm+pTJwX3a1cD0HnoYplAf4fYMUPVQMST/FVE+JAC5sGA46pIP3Z0Wr L+IeLUgjixNmzIDd/ZWX9tB93Pbvw+lPVL4bpfhYznz9bPNNKEqxNw1LLXAtWqb/5IuZ R8kv4xIsDikv+40mWKbflKWww9NgoNos/xpTg89WNZbAEiwlA3lWIwuBf2t/tUSUR1UN wsilXv89ffRFt7c0Qh0ZtjbnkkiFnaNLcuV9MylKpkPItPHinKz0WujEkrXOSM/XXx4V kTGQ== X-Gm-Message-State: AOJu0Yz0/DNVFhVoavlfZmIaxALpuW7fA6tyHnbU5yuSrPCMwtT5RpDA 5cC7xWH9gxozOOKJewhM6DrvUfhhhg5eJrPggkSMLg== X-Google-Smtp-Source: AGHT+IHu9KCk+U+2BZZcM+n1u03l4SUTsaVD6R/jYK+TncS8K1acPfAAJHXDtpkzan9rcfxnGu0zhQ== X-Received: by 2002:a17:902:e80a:b0:1c3:9928:7b28 with SMTP id u10-20020a170902e80a00b001c399287b28mr6539421plg.6.1696603456707; Fri, 06 Oct 2023 07:44:16 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:feaf:8ce1:2536:f945:8046? ([2804:1b3:a7c1:feaf:8ce1:2536:f945:8046]) by smtp.gmail.com with ESMTPSA id p5-20020a170902bd0500b001c73701bd17sm3937100pls.4.2023.10.06.07.44.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Oct 2023 07:44:15 -0700 (PDT) Message-ID: <66646260-c6c9-4d2d-b3e3-20f3d5b83ff3@linaro.org> Date: Fri, 6 Oct 2023 11:44:13 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RFC: system-wide default tunables Content-Language: en-US To: DJ Delorie , libc-alpha@sourceware.org References: From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 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 List-Id: On 04/10/23 17:55, DJ Delorie wrote: > > Before I start on actual coding, I'm sharing my thoughts on this > project to gain consensus... > > Problem: tunables are set by an environment variable, and may be > limited by security settings, containerization, etc. Plus users may > not assume that the env var is pre-set, and just overwrite it. > > Solution: Add a way to specify system-wide defaults for tunables. > The idea sounds ok, but adding on ld.so.cache means it would not work for static. I don't think this is really an issue, static PIE is really tricky because self-relocation happens after tunable (because tunables itself might change ifunc selection); and trying to add support for static PIE would require a lot of messy refactoring (all ld.so.cache loading would need to be annotated hidden, no external function calling, even mem* ones; etc.). > Ideas: > > * Specify some file or files in /etc that contain tunables settings. > Follow the ld.so.conf patterns, allow subdirectories, etc. > > * Store tunables info in /etc/ld.so.cache in a new slot at the end, > with a new enum for the chunk. This way older glibc will just > ignore it. Parsing and storing will be done via ldconfig. It means that we will have to always load the ld.so.cache, not only when we will actually have to load an ET_DYN . It should be ok, but runtimes that usually only link against libc.so (like rust) will have additional overhead on startup. We also have DF_1_NODEFLIB to inhibit loader cache search, should we add another flag to inhibit the global tunables? It does not make sense to set per-library, but it still might be useful to set on ET_EXEC. So I am not fully sure adding the global tunable setting on ld.so.cache is the correct approach. However, adding on an external file will add another open/mmap/close on each program; plus the extra mmap. > > * 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, so I think we should add the range check on ldconfig ld.so.cache setup. There is no error checking on env var tunable, invalid values are just ignored without any user feedback. Since we will do pre-processing, I think it would be valuable to at least show any possible invalid range, specially because this is a administration setting. > > * read those, do range checking, and call callbacks at runtime > > * To speed processing, encode a hash for each tunable name, both in > glibc's table (which is built at glibc build time) and in > /etc/ld.so.cache. Comparing the hash typically fails but avoids a > string compare. Matching hashes are followed by a string compare to > verify. The hash need not be crypographically secure. Do we really need this optimization? Internally, the tunables are already accessed through a enum, which is essentially a index on tunable_list. Why can you we use the same enums value on the cache definition keys? The string mapping could be accomplished by adding a string list, with the tunable value being the offset. > > * 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? Should we ignore the envvar or merge the results? Which one takes precedence (I take the system-wide)? Should we add a way to override system-wide value (similar to DF_1_NODEFLIB) as a runtime options (either another envvar or a extra field in GLIBC_TUNABLE)? > > * Tunables set by these defaults will not be disabled for setuid > programs; it's assumed they're a "trusted source". This seems reasonable, and with this rationale should we add an option to allow some tunable to be disabled or overriden? I take this is an extra complexity that we should not pursuit.