From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 2F1523858426 for ; Fri, 6 Oct 2023 17:12:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F1523858426 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-pf1-x433.google.com with SMTP id d2e1a72fcca58-68bed2c786eso2031938b3a.0 for ; Fri, 06 Oct 2023 10:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696612343; x=1697217143; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:references:to :from:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=Xod8skFxr/wAOqrg7yAwJGiO0fY9kl7JII2zFzQ0pOk=; b=t8wJt1LiqpVgW1uMl0DiU7iNqn5TdaIdsUO8ij/CIqZ4FLJY43wzjSYmDFLgt5IOaL RoucZAvuUYxhJgA3lOLFANlEyTPlijptYR54wokVdtMHYUT7Yid5Ue8dcxo+Rwaqayuk sj0pGaAN6vpfTU9zy/ZEMomC8u0HuIqOylq1wFbO0UGtZqz2qcS/m45Xw5ZsCM5wl5VR VK3utVxfeCiCyARfEIwv4punjkZr66m+H65pS6EVuuLikex4gP0nr7Rsbt30YO84bQqA 14TVJL2VgMHPwh0Jhit7kkH0holRINf519KmVLVATQFF2pRMQnWjR0e5P55nyJW9WlBv 8XPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696612343; x=1697217143; h=content-transfer-encoding:in-reply-to:organization:references:to :from:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Xod8skFxr/wAOqrg7yAwJGiO0fY9kl7JII2zFzQ0pOk=; b=BOo0ByM7b5CZZLaKsCv5b2gLej6VX/QrCI0Fxm+fVeNT+V+xcPixp93MHY2KW195ck igM7j7iAOlwnl1Us38fucqqJU0glnxPtKhzc4GMxuXCy/xEtejZ9tLaZXmiGDlEPy6Y2 ymnnBg57xWu94/B5s21RrbTo70rPi3XpLpYlKWoOA1eoPsfE+cAyE7ogSu4RkaSc84lf za4Q5gPKKK7YAdcSbbAc2GyCgc1ZAO7RgzQS4Px/NYgshmd3sBN0Ja5TlH12m66BJ+jn Z86+sSmF8uKdyR5K+uRYymM3vAyMqvaJrPEiF9KmHNulZT1rE4GtZompmEfTW7FmBQzn KbzQ== X-Gm-Message-State: AOJu0Yx6oCALf82w623wYY/u94n02Q/RSSy9T3jAP3c6a3Mt24IQfFY1 GLFrkLs5vDZMQLgMj1HsmqLhTw== X-Google-Smtp-Source: AGHT+IF5ZYxm29/Md7/sFkLD7R/d32Pf5u86sb70eT9Fuu+PcX+fvYqPl5ZVLf3j3EN5gRTYUxoXXA== X-Received: by 2002:a05:6a00:24c6:b0:68f:b3ed:7d4d with SMTP id d6-20020a056a0024c600b0068fb3ed7d4dmr10099746pfv.15.1696612342977; Fri, 06 Oct 2023 10:12:22 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:feaf:9e9:3fff:94f8:9e64? ([2804:1b3:a7c1:feaf:9e9:3fff:94f8:9e64]) by smtp.gmail.com with ESMTPSA id n14-20020a62e50e000000b0069319bfed42sm1711098pff.79.2023.10.06.10.12.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Oct 2023 10:12:22 -0700 (PDT) Message-ID: Date: Fri, 6 Oct 2023 14:12:20 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RFC: system-wide default tunables Content-Language: en-US From: Adhemerval Zanella Netto To: DJ Delorie , libc-alpha@sourceware.org References: <66646260-c6c9-4d2d-b3e3-20f3d5b83ff3@linaro.org> Organization: Linaro In-Reply-To: <66646260-c6c9-4d2d-b3e3-20f3d5b83ff3@linaro.org> 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 06/10/23 11:44, Adhemerval Zanella Netto wrote: > > > 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. Another possible feature that comes from the tunable discussion is whether make sense to add a per-process tunables. The aarch64 MTE for instance is an example, it is disabled by default because of performance implications; so the admin might just enable it on some really security sensitive processes.