From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fout5-smtp.messagingengine.com (fout5-smtp.messagingengine.com [103.168.172.148]) by sourceware.org (Postfix) with ESMTPS id B4232385840D for ; Tue, 23 Apr 2024 18:14:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B4232385840D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B4232385840D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=103.168.172.148 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713896067; cv=none; b=Fw3e+VkBMW5MY/S8/FvjooRwN2oMdJfKU2Cbesc363dM9A5MVG15f1cN/nyaBW8Ks16eH98itE4tmwS2zVqSOR7IyPyBzEeRbrUIkPukPhtZvfyQflAtvD1RbeAewfeHaG7e4qhyEo5nnBIjJVg0YcJB/UQoQY2CJuFWftVkJNY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713896067; c=relaxed/simple; bh=eIJOViE6YtRNnLaUnvcGvylcYuS3PJUYokDafEOvs3U=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Date:Message-Id: Subject:From:To; b=OGdAxZvkWhi2eqYxbSYw1TKe87rABcUGCwGQ8w2Z96zZ37YNbYbUbEhs5fTv9cvJ1wf01yaYBNw1JpRAnDppjHeypyqkU6UI5IOG9OfOnh1TuBblUNAjKWNQ48j2chnSGsCU7zBimWH9wepn8Knp6QZ+uEpx7B1UXtUiBt5wXzs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.nyi.internal (Postfix) with ESMTP id 7F5EF138025A for ; Tue, 23 Apr 2024 14:14:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 23 Apr 2024 14:14:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to; s=fm2; t=1713896064; x=1713982464; bh=dXdSExPNI2 R5aSWFZ0aDajsfry4nmkXgysBiiiiWMoU=; b=oKkZxMo6azbHmsGD73SRkyGtbC 6o3dbWxlqoVHte0RUoxhV+VzAw9hg4tvNdeJWSDAvSsBiHnLNpSBOZ9AbTfUXM0L JWxHbfGJogbQq4fUZv6+2AtZMWikRZkHhHVxZ6+xV1o/g0LDpe+EY0OrRQwSB2zR YiId1uoba6X48Ao5Ybtw50uYwxUXTODI4dCmVs0c+tz6flkNL/c7NKS3OSpp2QxK Jy53MkpuSQkB4cIK6e1yWJA723DUo5X0Fcbs0TargIeRtl8a1zRte5UAtPtyXOwx 7GNF1VpljU3w1yvo6Ib1b6Or/a7gcvm6TQeL63cpvdVJS4dsYOoM+tpkcpbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1713896064; x=1713982464; bh=dXdSExPNI2R5aSWFZ0aDajsfry4n mkXgysBiiiiWMoU=; b=OwcWwC+Kmj6X/t8OSpO+HsQjO7XVR0P3i/B0aRbO2z0/ AR3Xa92AEwAupZSoStRSc5Ol7RSiCKtkCqOQ/pNpIg1Wjuctz272CwM9EvO4IXgD /Ve5Q64H4MIrnDoHiKcUX82LwOoXOVE3k4rvGSr3nbwhnhzzrMrYNuQS9t+91p8u OnxsQAQQwkIYTVEfEpmpHixvydFn39tXMMWTyU8qQUZWSzNTs5E6TnVaQieR3kgC LZXqYQXpO29Vz5LasBfkGq+bSho3exHmRP+R7BbAHx0ZqHdxQWiOrIRR7D7442O0 vUpp0oTlmXA8E4ts0L3owWE55UIJi88AUJ/sjx0+cA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudeluddguddvfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepggfgtgffkffuhffvofesthhqre dtredtjeenucfhrhhomhepfdgkrggtkhcuhggvihhnsggvrhhgfdcuoeiirggtkhesohif lhhfohhlihhordhorhhgqeenucggtffrrghtthgvrhhnpeegvdfffedvieeklefhtdfhvd efiefggeduieefjeelteeileevjeefgfefffffteenucffohhmrghinhepshifthgthhdr tghomhdpshhouhhrtggvfigrrhgvrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 23 Apr 2024 14:14:24 -0400 (EDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 23 Apr 2024 14:14:23 -0400 Message-Id: Subject: Maybe we should get rid of ifuncs From: "Zack Weinberg" To: X-Mailer: aerc 0.16.0 X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,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: I've been thinking about the XZ exploit (two versions of the compression library `liblzma` included Trojan horse code that injected a back door into sshd; see https://research.swtch.com/xz-timeline) and what it means for glibc, and what I've come to is we should reconsider the entire idea of ifuncs. The SSH protocol does not use XZ compression. liblzma.so was loaded into sshd's address space because some Linux distributions patched sshd to use libsystemd, and some libsystemd functions (having to do with systemd's "journal" logging subsystem, IIUC) do use liblzma, but by itself that wouldn't have been enough to give the exploit control, because the patched sshd doesn't use any of those functions. But these same Linux distributions also compile libsshd with -z now (ironically, as a hardening measure, together with -z relro) and that means the resolvers for all the ifuncs in *all* the loaded shared libraries will be invoked, early enough in process startup that the PLT and GOT are still writable. The XZ exploit used an ifunc resolver to rewrite a whole bunch of PLT entries, intercepting both calls within sshd proper, and calls from sshd to libcrypto.so (i.e. OpenSSL's general-purpose cryptography library). Ifuncs were already a problem -- resolvers are arbitrary application code that gets called from deep within the guts of the dynamic loader, possibly while internal locks are held (I don't know for sure). In -z now mode, they are called not just before the core C library is fully initialized, but before symbol resolution is complete, meaning that they can't necessarily make *any* function calls; we've had any number of bug reports about this. They seem to be less troublesome in lazy binding mode, as far as I can tell, but I can still imagine them causing trouble (e.g. due to recursive invocation of the lazy symbol resolution machinery, or due to injecting non-async-signal-safe code into a call, from a signal handler, to a function that's *supposed* to be async-signal-safe). The glibc wiki page for ifuncs (https://sourceware.org/glibc/wiki/GNU_IFUNC) warns readers that ifunc resolvers are subject to severe restrictions that aren't documented or even agreed upon. As far as I know, the only legitimate (non-malicious) use case anyone wants for ifuncs is to allow a library to select one of several implementations of a single function, based on the characteristics of the CPU -- such as how glibc itself selects the best available implementation of `memcpy` for the CPU. It seems to me that we ought to be able to come up with a completely declarative mechanism for this use case. Perhaps a library could supply an array of candidate implementations of a function, each paired with a bit vector that declares all of the CPU capabilities that that implementation requires, sorted from most to least stringent, and the dynamic loader could run down the list and pick the first one that will work. This would avoid all the problems with calling application code from the guts of the loader. And, in -z relro -z now mode, it would mean that no application code could run before the PLT and GOT are made read-only, closing the path that the XZ trojan used to hook itself into sshd. We'd have to keep STT_GNU_IFUNC support around for at least a few releases, but we could officially deprecate it and provide a tunable and/or a build-time switch to disable it. To figure out if this is a workable idea, questions for you all: (1) Are there other use cases for ifuncs that I don't know about? (2) Are there existing ifuncs that perform CPU-capability-based function selection that *could not* be replaced with an array of bit vectors like what I sketched in the previous paragraph? zw