From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 5F4213858416 for ; Thu, 21 Oct 2021 17:43:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5F4213858416 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 9ha5qjttl7hLsD6bksRDHuteMIiwcEt9N5STRLWI/wB07b1PVW+yGZET1up0ceBnH8ATp5UrUe DcRVGsJlh6COUMWMvfzekU5KpXMK3TUx2EcV/yrzlxYa7BGqxO6dNHcdKHDfQdIBK5n0n+Ecvg ftmGfKIwt8r8WBeYNAS7VLPpwfePzf9hdr8IfrUyiIb/oTAg/Hr3nSmEGo5Yl4amfqH5EViWRh nT9TN5quPFop9WJiBXRz4E7M54riFxNSdApcxeHbhO8sMBcqGBd5FMXsgsXsLvvcUPs8qjgQhv sOzGsz+uRx++ZTZThIi42AlL X-IronPort-AV: E=Sophos;i="5.87,170,1631606400"; d="scan'208";a="67481120" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 21 Oct 2021 09:43:26 -0800 IronPort-SDR: xqybkv5MaaCC68TFl1eePv6UgzpFpfDCMo41OQAf138mGmDQet/McQNENHNioGr2OjUIR0mKcy fmjo0XxQqGwlY1byDhuNDTl3N2vYV39qYRRfQlVHpOkeMCGv4+soEnYOmmRWBgexl5sffBxbrX tAT5SZYD1443fRHWsqTO+zLHYVfEi6oMeG1lPPp4YY3lWmU/FjBi0Jbw3ZcF0ZxouFyOPiohiw mZNJF58c+awlYilp4JtszbC+W79rQ6JPrH+pcV9P12msbg/D4Oi0Nqk4KUABFHfMjqdNQMgtqR 9ew= Date: Thu, 21 Oct 2021 17:43:21 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Subject: When to prevent execution of new binaries with old glibc Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3117.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 17:43:29 -0000 This question has come up in a couple of threads lately, but perhaps deserves its own thread. When should glibc try to ensure that a binary (either a main executable or a shared library) built and linked against a newer version of glibc, and using some feature that would not work correctly when run with an older version of glibc, fails on startup (or shared library load) when run with older glibc, rather than failing later or executing incorrectly? The main mechanism we have for this is symbol versions, although the EI_ABIVERSION / libc-abis mechanism might help detect some cases of using unsupported ELF features. We use new symbol versions for new glibc ports, newly exported symbols, symbols that have changed semantics in a way incompatible with existing binaries, and symbols that have moved from another library to libc. We rarely, however, use such a mechanism in cases where old binaries are expected to continue to work OK. That includes, for example: * Bug fixes. * Changed function semantics where the new semantics are a refinement of the old semantics (e.g. a new standard imposes stricter requirements on the result than an old standard, and glibc changes to implement that). * Functions taking an enumerated argument (including any case of integers from some enumerated list, whether or not using a C enum type) describing something about the operation they carry out, where support for a new value of that argument is added. (In some cases, it may be the kernel not glibc that adds support for new values of the argument, in which case there is nothing much glibc can do.) * Functions taking a flags argument, where support for a new flag is added. (Again, in some cases it's actually the kernel implementing the argument.) * Functions taking a string argument that they parse, where support for some new feature in the string is added and strings using that new feature would previously have been considered to result in undefined behavior (such as adding new format specifiers for printf, scanf, strftime, strptime and strfmon format strings). In the above cases, it would be possible to use symbol versioning, making the new symbol version an alias of the old one, but we don't generally do so. There are also other, possibly rarer, cases where such symbol version aliasing can be used for a similar purpose (e.g. the change long ago of the return type of various functions from void to int in C99 TC1, where we did use symbol version aliasing on the affected functions). When, if at all, should we set up symbol version aliases for such issues (or use some other mechanism to prevent execution of new binaries with old glibc)? We can take the case of new printf specifiers as an example, where HJ has suggested that binaries using such features should have a dependency on the relevant glibc version (and in practice that would mean binaries using any affected printf-like function, 56 per long double variant, whether they use the new formats or not). But we haven't done that for e.g. strftime/strptime changes (and scanf functions have only got new function names because of incompatible differences in the handling of formats that were already valid before the changes). -- Joseph S. Myers joseph@codesourcery.com