From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) by sourceware.org (Postfix) with ESMTPS id 072063851517 for ; Fri, 28 Oct 2022 16:09:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 072063851517 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-io1-xd36.google.com with SMTP id h206so1473212iof.10 for ; Fri, 28 Oct 2022 09:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=abLT4lMA22zKMihRSfC8BoNZW6j6JQdbji5/dQFaHVU=; b=bNyUQ901kOAHEU69JAxXAyx5WKUoiN2M6W8MYBMOsZmEsaEYCWeHZn/jxzOTfWQ2wb qkuxyQ2PZRASZIUkORG7uuabFob214TTNqmv67F/FwG4PoGkUZQCT26ppbNrR7Qqi0DL Rz+lOvqMsaOdoxgO+VcIDr35L+7tZeThGQcpk3vFgXXNIuK0lGB0nzHvKW/NACIcX5AU yif+r+sNUStM7JI9hwZG5f1WQtPM2rZdx64nMK/lX8S4/ABB5FZznAji8ZwrTNnpz6re ZdLenkMOg3+e+xxqE+GRuIKJEc3b/1yHD9mENbHyt0FpoB/SaIc22Baw9w/TzrDmdZU6 ZoKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=abLT4lMA22zKMihRSfC8BoNZW6j6JQdbji5/dQFaHVU=; b=XtCO0guCapxNBhcHcZUgyLIJwSC+YCya1kCS0UkkXsbqta65WJAS9aXs2h3psYzNTH xTBoasI3XqsKu3qecqhV4WMgXu70VkhIqXDUaLSYES2LMCJOGZ0x2za4JVvZDK6eXSn/ HStlodciYQXgEYQMXhJy6RdINkouBU8Gl6Qy7iUSrqEV+TEpHSfPHFCMjIBfqWvaL8WP Ba+QxheBCc/5UEa5U2ZtSNSWLMK7scuUfpr8CoRXQsEGB/r03c5k7bJxK6q6/dXZ4BZT GQzUfNBJPY8CFIeTuGNB+83GtJpoSPufFx9MkFZz1W+i1KAu26TM/CoFgVW32H70L527 4kbw== X-Gm-Message-State: ACrzQf2ZJZwZdXfPJ0Q2gMuyhPqx1vFjGPWdUOuPUy87EM6E+yR3/4Qa WTpRdAjTPDABmOEvXSedhC1Eo4fht44qA6PKouZTWA== X-Google-Smtp-Source: AMsMyM7uToKBbaFqs1H68VTJobOOEMG7EL+SuaudKfPHI4KBDbxbh0KpPnZBdBwbkZilLiGw5ySTMwwVqByRs5hsl4M= X-Received: by 2002:a02:2707:0:b0:363:6ffe:172c with SMTP id g7-20020a022707000000b003636ffe172cmr125655jaa.34.1666973365023; Fri, 28 Oct 2022 09:09:25 -0700 (PDT) MIME-Version: 1.0 References: <20221027140928.1480353-1-gprocida@google.com> <875yg4ugk4.fsf@seketeli.org> In-Reply-To: <875yg4ugk4.fsf@seketeli.org> From: Giuliano Procida Date: Fri, 28 Oct 2022 17:08:48 +0100 Message-ID: Subject: Re: [PATCH] Narrow Linux symbol CRCs to 32 bits To: Dodji Seketeli Cc: libabigail@sourceware.org, kernel-team@android.com, maennich@google.com, sidnayyar@google.com, vvvvvv@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-21.4 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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: Hi Dodji. On Fri, 28 Oct 2022 at 16:13, Dodji Seketeli wrote: > > Hello Giuliano, > > Giuliano Procida a =C3=A9crit: > > > Self-reply. > > > > On Thu, 27 Oct 2022 at 15:09, Giuliano Procida wr= ote: > >> > >> MODVERSIONS CRCs are 32-bit hashes of strings representing C type > >> elements or typed symbols. The hash is calculated using a 32-bit CRC, > >> hence the name. The kernel module loading code (implicitly) truncates > >> any provided CRC value to 32 bits before comparing it with anything. > >> > >> When support was added to libabigail, values up to 64 bits wide were > >> supported. > > > > True so far. > > > >> Recently, Linux kernel builds have now started generating > >> ELF CRC symbols with 64-bit values (where the low 32 bits are the > >> CRC). Together this has resulted in incorrect CRCs in ABIs. > > > > The actual problem is a change to how CRCs are emitted in kernel object= s. > > I think the change 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b was > > responsible. > > > >> This change resolves the problem by narrowing libabigail's concept of > >> Linux CRC to 32 bits. No tests are affected. > > > > The representation change is fine. The problem with bad CRCs is still > > there. > > The changes look good to me. Do you want me to apply it right now, or > do you prefer to send a subsequent patch that addresses the new way how > CRCs are emitted in kernel object? I'm happy for the change to go in. However, the commit message text should be updated. I would make it: -- MODVERSIONS CRCs are 32-bit hashes of strings representing C type elements or typed symbols. The hashes are calculated using a 32-bit CRC, hence the name. The kernel module loading code (implicitly) truncates any provided CRC value to 32 bits before comparing it with anything. When support was added to libabigail, values up to 64 bits wide were supported. This change narrows libabigail's concept of Linux CRC to 32 bits. No tests are affected. -- I'm not sure when we'll get around to updating the symtab reader. It'll probably not be done by me. As I understand things, there are something like 3 or 4 different encodings of CRCs depending on the kernel version and architecture (and that's ignoring endianness issues). Matthias has even suggested it might be better (more reliable) just reading CRCs from Modules.symvers instead. However, that would require more integration into build scripts etc. > I am fine with either way. > > [...] > > Cheers, > > -- > Dodji > > -- > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >