From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 004403858410 for ; Mon, 25 Oct 2021 16:53:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 004403858410 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: dxlAM2jwwmZVn2P7BcENPFqn0/mhH5S9MZSWFWwPNaamwBUBNGqZyy3f92H75d0ap1iiKIDF6E Ow+zZ0aEyCCfNNF4g/fZ89vqLN/p9c8oCvIYiL/ri6FO04ttxnSeI7l3i044qwyh1fxc/2MtM7 1qT9iAyJgm1On/NGIDqV0Veif4bX4qGV/RU+LafwKcW6KWePLnBVIlvdc17loh5tL0ppUhf4Zt jrCZayXnrZRhlmYzZpyUTMQCLJMS8caCFqmBT1ubnPDxwEtU71Dq9sPItexs8N8x/qLGWDAHfh zFCxE70EYigJWeSQ5GuOPg9/ X-IronPort-AV: E=Sophos;i="5.87,181,1631606400"; d="scan'208";a="70072187" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 25 Oct 2021 08:53:31 -0800 IronPort-SDR: blTVx4u+NcBT+B/sEGD8HZmlOxZ6SvQQqOZEYY1/2xDKLQT/XAaTX83FhtXNQ+/rprobMIMqBR QuKzddo22ZFy6AFTE1Qiep8scd5bWmSBmSUNm1v8yAI/6SoAQ1OGTHArzw3JG0lpMe7r+HbUji Kt1LQtFa5NK9SKjYICx3lcblmzZkCj2K8Zf8EdmzYUaUCbvzovdvClcDi5JekBsytcPEUhhW3i +9Rc62f7u10YkJdLFxeue125ZkBtxOTs9GxVw/1s0anIJnXr1bvSFVvAnsSjwgzgOPPxMXbcFx B9A= Date: Mon, 25 Oct 2021 16:53:25 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: "H.J. Lu" CC: GNU C Library Subject: Re: When to prevent execution of new binaries with old glibc In-Reply-To: Message-ID: References: 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-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3117.3 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: Mon, 25 Oct 2021 16:53:34 -0000 On Fri, 22 Oct 2021, H.J. Lu via Libc-alpha wrote: > On Thu, Oct 21, 2021 at 10:43 AM Joseph Myers wrote: > > > > 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? > > This is a QOI issue. We should do our best to ensure it. Otherwise, > we don't need all these intricate symbol versioning schemes. I think what we've actually tried in the past is to achieve a reasonable balance, detecting the most obvious cases where a program is expected not to work with old glibc while leaving people to try running programs on older glibc at their own risk in other cases and avoiding introducing excess complexity (symbol versioning is still needed to keep proper compatibility with existing binaries and so not require people to rebuild everything when they upgrade glibc). (Running a binary with an older glibc than that it was built with is never recommended, however, even when it sometimes works.) Cf. the past discussions of how it would make sense to *remove* the runtime kernel version check against the version specified by --enable-kernel, letting programs succeed or fail when the relevant syscalls are executed, given that (a) they might well not actually depend on any affected functionality and (b) the older host kernel used in the affected container configurations may actually have backports of the newer syscalls. > These are our oversights, but not green lights to allowexecutables > or shared libraries to crash at random or generate incorrect results > with older glibcs. I don't think they are oversights; they're more part of the balance between catching common problem cases running new binaries on old glibcs and limiting the complexity involved in catching such cases. > > 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 > > We should do that going forward if executables or shared libraries may > crash at random or generate incorrect results with older glibcs. That could cover just about any bug fix. > We can add a glibc version reference to one of the crt files which is included > in all executables and shared libraries. We can, but that's a very different balance from that chosen before for when to stop execution of new binaries with old glibc. (The new __libc_start_main symbol version means executables built with glibc 2.34 won't run with older versions, but that's because of a more general compatibility issue, rather than being routine for any new version with any new features in any function.) -- Joseph S. Myers joseph@codesourcery.com