From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id WJopBxpNK2dplgAAqHPOHw:P1 (envelope-from ) for ; Wed, 06 Nov 2024 11:03:54 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id WJopBxpNK2dplgAAqHPOHw (envelope-from ) for ; Wed, 06 Nov 2024 12:03:54 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=icepic.de header.s=x header.b=ntyjvHG+; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1730891033; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=VJJDITwQmXx1pjYdSwxruQ8nLFkRVxOWMMUrvRxGARM=; b=sGvGGJbEmt6IAMADHAgiMGhbNXdvIsq70h+wWFbWs9Nk4fsEqKEGKfFQvEzSzbRStOZmHX bO0DGwepIVq2WCuLM+eWBr0P0s/RQJ4X4vWA9q306WT6y7BOoTdW6UzfQGO01hs7WiHU8t OoTOjW0FxYCV2zAmWBBFG9ARkV1NuLoj8yMNSdJkZJcyT0oaf1F1paQJVsGKTvIOYf/79c W84ZtP5cAAXXKhH/RCB60wLSflSP3GZb43UIpnbV0AHPxeo+syNgObjwBd/fUUB5K5C32r 8U+2vN6LpDvkSxk+Uwf5bVeNBJrBhlPVgmn3nGsLqZJr8iuU4bkNW9yoK3evVg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1730891033; a=rsa-sha256; cv=none; b=ovDPk20fcssWC6TNvGe5MSN5zjuXuWyF3h6rXlC8dKmAlL0JPftlLNsleXoIgkmN2ZiXrK Ux21VCOcN7ha8xZLwG45yddpJIGlE3BdhB60eIy+kZbL1FXRdFxAmJYTinu2k6bF0K7C5v HzsO3l9lQAMRIyXpYshzZlwcpEFyd/p2fXOV9hEv79+OI7muUrrWL0NDWW8DpQLZRW56Oy JYbJoGc4lVUPqLdeBplj+6vKhcS0vWWV+XcmF2wRnbJae6nNP8Iet0MN68yyl4oOt06weN dMakZso9VdBEA1BynPR8mlVpF4KG7ZsoClEqlH6P8UWjhOwaLqU+mA0muMc0DA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=icepic.de header.s=x header.b=ntyjvHG+; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=none Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id BF7EC5F4B1 for ; Wed, 06 Nov 2024 12:03:53 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t8dET-0007pK-3b; Wed, 06 Nov 2024 05:25:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t8dEP-0007kK-Tf for help-guix@gnu.org; Wed, 06 Nov 2024 05:25:46 -0500 Received: from mail-108-mta199.mxroute.com ([136.175.108.199]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t8dEJ-0008Mr-59 for help-guix@gnu.org; Wed, 06 Nov 2024 05:25:44 -0500 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta199.mxroute.com (ZoneMTA) with ESMTPSA id 19301020ef80003e01.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 06 Nov 2024 10:25:32 +0000 X-Zone-Loop: 80b0e248c37adcbf27d250e25a4f602ab9c8cab3b4d6 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=icepic.de; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VJJDITwQmXx1pjYdSwxruQ8nLFkRVxOWMMUrvRxGARM=; b=ntyjvHG+FVso8Hko3oQ2aWf6yR QBSahLjnUJaebn9U1oo/u05avEPaGLbYDzKoam8oW0wHF8eoJKEMkyvGtaOjYh4yjQPxp7Gr3CGHq f/bn0Kc/+yiTIO/QEUk/dnGcxnmC2O7oImFcpBY9RXB6E6TmOUW7Dlgcoh0z+j2IGs/j2wOwJL4Hf OGUAQFv5IQFLNZ7u3UxVSvpQ0Vw+Ccwj2AEN05lc/a6iCKuJ3/tZOtTenaDNuWB33gaJfEp88oszj X4RQpBtLs4fYlRvyOmpp7bas0cN9eHH3rQ4n4/AjEe+uctoT0SCZmiUFNIZRbPcmjC8u/gd0zTKkj LCM4TZsw==; From: Christoph Buck To: Zack Weinberg , Efraim Flashner Cc: help-guix@gnu.org Subject: Re: ABI mismatch on boot on arm32 system In-Reply-To: <87plnh67w5.fsf@icepic.de> (Christoph Buck's message of "Wed, 30 Oct 2024 14:24:26 +0100") References: <87y12opdbh.fsf@icepic.de> <87iktmhk6v.fsf@icepic.de> <86b5aa0a-35ce-40ee-84a6-de58ea153fbf@app.fastmail.com> <87a5eyheme.fsf@icepic.de> <87o73dvkz6.fsf@icepic.de> <87wmhqesw0.fsf@icepic.de> <87plnh67w5.fsf@icepic.de> User-Agent: mu4e 1.12.0; emacs 30.0.50 Date: Wed, 06 Nov 2024 11:25:29 +0100 Message-ID: <87jzdg4q1y.fsf@icepic.de> MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: dev@icepic.de Received-SPF: pass client-ip=136.175.108.199; envelope-from=dev@icepic.de; helo=mail-108-mta199.mxroute.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: help-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: 1.34 X-Spam-Score: 1.34 X-Migadu-Queue-Id: BF7EC5F4B1 X-Migadu-Scanner: mx13.migadu.com X-TUID: b/8VsRDFpzXl Hi Guix! So i looked into the guile source code and, as expected, the `scm_hash` function (see hash.c in guile) uses `unsigned long` wich is 8 bytes on x64 and 4 bytes on arm32/i868. If `string-hash` is called with the size parameter `n`, the hash value is limited to size by calculating the modulo `n` of the hash value, see scm_ihash in hash.c:440, namely > (unsigned long) scm_raw_ihash (obj, 10) % n (The `10` can be ignored as far as i can tell). Since the hash values are different on different platforms the modulo is different as well. However, if one steps through the call stack of `string-hash` you can see that the actual hash value is calculated by the `JENKINS_LOOKUP3_HASHWORD2` macro, which contains are rather interesting comment and a possible workaround for the abi problem, namely --8<---------------cut here---------------start------------->8--- /* Scheme can access symbol-hash, which exposes this value. For \ cross-compilation reasons, we ensure that the high 32 bits of \ the hash on a 64-bit system are equal to the hash on a 32-bit \ system. The low 32 bits just add more entropy. */ \ if (sizeof (ret) == 8) \ ret = (((unsigned long) c) << 32) | b; \ else \ ret = c; \ --8<---------------cut here---------------end--------------->8--- in hash.c:82. Meaning, if executed on a x64 platform, the higher 32bit of the resulting 64bit hash result are equal to the hash value on a 32bit platform. A simple test case in c++ looks like this: --8<---------------cut here---------------start------------->8--- int main(int args, char** argv) { scm_init_guile(); auto strToHash = scm_from_locale_string ("((device) (mount-point))"); auto maxULong = scm_from_ulong(ULONG_MAX); auto hashResult = scm_hash(strToHash,maxULong); auto hashResultUL = scm_to_ulong(hashResult); std::cout << "Max ULONG_MAX: " << ULONG_MAX <> 32) << std::endl; } } --8<---------------cut here---------------end--------------->8--- which results on x64 in > Max ULONG_MAX: 18446744073709551615 > Original hashResult ulong: 10454028974864831 > Corrected for 32bit: 2434018 and on arm32 to > Max ULONG_MAX: 4294967295 > Original hashResult ulong: 2434018 This suggest the following workaround. Always limit the hash size to 32bit even if executed on a 64bit platform (or to be more specific a platform where ulong is 8bytes big). Do this by right shift the hash value 32bits and don't rely on the size parameter of the `string-hash` function. In code it could look something like this --8<---------------cut here---------------start------------->8--- (define (compute-abi-cookie field-specs) ;; Compute an "ABI cookie" for the given FIELD-SPECS. We use ;; 'string-hash' because that's a better hash function that 'hash' on a ;; list of symbols. (let ((hash (syntax-case field-specs () (((field get properties ...) ...) (let ((hash-value (string-hash (object->string (syntax->datum #'((field properties ...) ...)))))) (if (= (native-word-size) 8) (ash hash-value -32) hash-value))))) (fd (syntax-case field-specs () (((field get properties ...) ...) (object->string (syntax->datum #'((field properties ...) ...))))))) (format #t "Compute-abi-cookie: ~a~%" hash) hash)) --8<---------------cut here---------------end--------------->8--- where `native-word-size` is define by --8<---------------cut here---------------start------------->8--- (define (native-word-size) ((@ (system foreign) sizeof) '*)) --8<---------------cut here---------------end--------------->8--- (taken from `cross-compilation.test`). There might be a cleaner way to formulate this, but you get the point. This seems to work for all combinations on my machine. I tested x64 -> arm, x64 -> i868, i868 -> x64... I can only think of two drawbacks. 1) Lost entropy on 64 bit machines 2) Abi break because on new compilation the hash values on 64bit platforms will change. 1) is imho irrelevant, because it is not cryptophically important. For 2) i am not sure how important this is. Any thoughts on this? Might this be something worth fixing and sending a patch in? Best regard Christoph -- Best regards Christoph