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.133.124]) by sourceware.org (Postfix) with ESMTPS id 380AF3856DE7 for ; Tue, 23 Aug 2022 15:14:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 380AF3856DE7 Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-608-7jFd-udKNaGwZGIthus2_Q-1; Tue, 23 Aug 2022 11:14:58 -0400 X-MC-Unique: 7jFd-udKNaGwZGIthus2_Q-1 Received: by mail-qt1-f200.google.com with SMTP id o21-20020ac87c55000000b00344646ea2ccso10737194qtv.11 for ; Tue, 23 Aug 2022 08:14:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=bS2WOm8gq/HzXQTsci1Kt+CRVlw/8w+ZpuyfeNsS4gg=; b=bbaI41MPpnFZxYPh4MFVrzVHRmEQTgns8FsBQ8tcWW7T3IonOL7ktY9QAy90Q09QIl ZYg52gysASSXlRYGjsdhH0+KEeIcRCYcNgDNBCKe02Wo0UXwxQHBhPizFE+qxfAWorqm Xj52YI3vfbmz+Oaqej6PdFg5OXtcV9oRgkytGIyrVPpkXaFciqYA9FRvB5AacNqXC6+2 mc6KztLJGYLeyABfVN8yeWCrd9CzxpnuhB2MoTrhrT3D1JJcvZCPsP7iZrwmh36Ynv50 Mz8Fff8kbM5QegrVZv1tcVL0FPFtcepPfJu62F1e0c6RNfG7lfSYQB+cNEo90grotYfJ lkVw== X-Gm-Message-State: ACgBeo26vZvQ8XptuacOMMYm8waAb874L8JZN4hie62c+HHjv+odnF/+ M4/tWGXgXARxQeuaGYgVmxJeeOl6F1XQn7Y7+8yVC7VXmkip0S2sTayhgIg8aNtKMK1xOsCbf4J Kus/4BPaGGol+ata54iwv X-Received: by 2002:a05:622a:48c:b0:344:9d12:db79 with SMTP id p12-20020a05622a048c00b003449d12db79mr16469468qtx.351.1661267696974; Tue, 23 Aug 2022 08:14:56 -0700 (PDT) X-Google-Smtp-Source: AA6agR46tvbVCT8lL0bUxoFJv9GvzN3hono8QktcI7CidN5wRxN+kP8FS7Ojlr1fLHJQbbwaqP7BfQ== X-Received: by 2002:a05:622a:48c:b0:344:9d12:db79 with SMTP id p12-20020a05622a048c00b003449d12db79mr16469443qtx.351.1661267696702; Tue, 23 Aug 2022 08:14:56 -0700 (PDT) Received: from [192.168.0.241] (192-0-145-146.cpe.teksavvy.com. [192.0.145.146]) by smtp.gmail.com with ESMTPSA id f39-20020a05622a1a2700b00342f05defd1sm11451468qtb.66.2022.08.23.08.14.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Aug 2022 08:14:56 -0700 (PDT) Message-ID: Date: Tue, 23 Aug 2022 11:14:55 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 0/2] Check ld.so/libc.so consistency during startup To: Florian Weimer , libc-alpha@sourceware.org References: From: Carlos O'Donell Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Tue, 23 Aug 2022 15:15:00 -0000 On 8/19/22 06:16, Florian Weimer via Libc-alpha wrote: > This avoids mysterious crashes and produces a clear error message > instead. The high-level idea here makes complete sense to me. In my opinion the gold standard would be: - If the interface between libc and ld.so was more formally defined then we would have a way to know if ld.so could use the the libc that the system was providing. - The new ld.so is always installed first and knows about past libc interfaces and could choose to use a slightly older interface if possible. We don't have that today, and I am not asking for you to implement this. What I want to make sure is that what we implement retains some of the invariants that such a design would have: - ld.so is always installed first is generally maintained in rpm-based installs because of the file name ordering ld.so < libc.so - True for Fedora testing. - ld.so needs to know if libc is new enough that it can work together. - Your patch uses a known symbol with a hash as the discriminator. - ld.so provides better diagnostics if the requirements cannot be met. - Your patch provides a diagnostic. I think your patch meets all of these conditions. Where we loose a little bit here is that if a developer is making a non-ABI change to the interface, and just rebuilding ld.so, this will immediately cause that ld.so not to work with the libc in the build. This is a limited use case that we can fix if developers report that their workloads are impacted. We might change how to enable/disable this feature. Of key importance is going to be the quality of the diagnostic message here because that will be the first thing users see when they try to use ld.so from outside of a container with a libc inside a container, and what used to work by sheer luck may now fail with a diagnostic because of non-ABI related changes. We have always said this was unsupported, and now we try to enforce this, and I can stand behind that technical enforcement. > This helps somewhat with concurrent glibc updates on a live system > because it inhibits coredumps resulting from mismatches. This avoids > secondary crashes from a coredump catching services that in turn crashes > during launch while the update is in progress. A full solution to the > concurrent update problem will look very different. Agreed. > Tested on i686-linux-gnu and x86_64-linux-gnu. Built with > build-many-glibcs.py. > > Thanks, > Florian > > Florian Weimer (2): > scripts/glibcelf.py: Add hashing support > Detect ld.so and libc.so version inconsistency during startup > > INSTALL | 9 ++++ > Makerules | 14 ++++++ > NEWS | 7 ++- > config.make.in | 1 + > configure | 11 +++++ > configure.ac | 5 ++ > csu/libc-start.c | 1 + > elf/Versions | 4 +- > elf/dl-call-libc-early-init.c | 9 ++-- > elf/libc-early-init.h | 9 +++- > elf/tst-glibcelf.py | 19 ++++++++ > manual/install.texi | 9 ++++ > scripts/glibcelf.py | 19 ++++++++ > scripts/libc_early_init_name.py | 85 +++++++++++++++++++++++++++++++++ > 14 files changed, 194 insertions(+), 8 deletions(-) > create mode 100644 scripts/libc_early_init_name.py > > > base-commit: f7b0fc5cc61301461e3c1a278240ce78701bb9a8 -- Cheers, Carlos.