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.129.124]) by sourceware.org (Postfix) with ESMTPS id BA72E3858426 for ; Fri, 6 Oct 2023 18:29:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BA72E3858426 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=1696616993; 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=D2pF97eH94g1yeXCy+7Y2mmNzvJGny5q9hvUogB2y2w=; b=caa8a9zchmNXBI3kP36f1u500hxKdJQ3vl9drysiVjNod+eHUQyLyf8prhppRcHrkw6Tzx M8aw6QCIywS8+AdNsznMeHpPkNPFyVv9ARyZ5SxR70zb8Pq6c5GA0v6R2suHyZ+WWIszWZ 0Wrm3m+WbKvH582ltTrz+okz6vDy4m0= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-583-OdB16LsuMAGIWTw9bzbvDg-1; Fri, 06 Oct 2023 14:29:50 -0400 X-MC-Unique: OdB16LsuMAGIWTw9bzbvDg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (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 15B742810D4E; Fri, 6 Oct 2023 18:29:50 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.8.97]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EC7921006B70; Fri, 6 Oct 2023 18:29:49 +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 396ITnuN814747; Fri, 6 Oct 2023 14:29:49 -0400 From: DJ Delorie To: Adhemerval Zanella Netto Cc: libc-alpha@sourceware.org Subject: Re: RFC: system-wide default tunables In-Reply-To: <66646260-c6c9-4d2d-b3e3-20f3d5b83ff3@linaro.org> Date: Fri, 06 Oct 2023 14:29:49 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.7 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_H4,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 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.). The idea behind using this is that admins are used to running ldconfig and managing ld.so.cache, so there would be nothing new to learn. The cache already has some hwcaps-related info in it, too, for selecting suitable libraries. >> 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 don't have to "load" it just map it and read the aux data at the end. But, yeah. > 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. If there were a system-wide tunable that caused improper action, it wouldn't be a "tunable" it would be a "stoppable". If a single program was incompatible with system-wide tunables, it would need the environmen variable set to tune them for the specific program. > 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. Yup. And worst case, those apps that don't get the tunable... act like they do now, with no system-wide tunables. If the settings were mandatory, I'd worry more. >> * 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. > 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. I see no problem with validating at cache time, but I don't want to skip range checking at run time. Doing so leads to security bugs. >> * 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, That enum might change from version to version. We're already seeing enum-related issues with RHEL upgrades. >> * 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. >> * 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. Agreed; we want a simple system. > Another possible feature that comes from the tunable discussion is > whether make sense to add a per-process tunables. Er, isn't that the environment variable?