From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id QFpeB8TbIWc+FgEA62LTzQ:P1 (envelope-from ) for ; Wed, 30 Oct 2024 07:09:56 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id QFpeB8TbIWc+FgEA62LTzQ (envelope-from ) for ; Wed, 30 Oct 2024 08:09:56 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=ErpSK39u; 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=1730272196; 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=zvtwHF1zvaEd5aqOVeFdWUGouJ8xa0kMvEJ+wlPGKp4=; b=GaUYVitvP9MA7nAoD5//PwHuxjCU/2zdOCgdVGErf79xAOIb4mdWFj5hmBxPXbNTwtLs6B CGVzBNzvEBx1QWiWZv1AB1i4b+xfka6/yamKDLYdSOD5pzUsaKfSzxmbnFVZUdijm8XfTd i4zcBVGNtasveVEan8fZ1dPeZ8Vmqpx5DQhyWlH+p6qUpM6iWITE7RZYAmEpuSEFGkyvaa +UUMAre2i1sFZQl9tXkdr4Brq1PaCEfm86kUDeMIkC88R9ZEWL5zTDYSX/wBv8880RmwOF aR/cVuxscFmHE+mZ5LauEOghq7k8HWZBceP8RPY0e4qGJvrmEDX5MBZ6NHYepg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=ErpSK39u; 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-Seal: i=1; s=key1; d=yhetil.org; t=1730272196; a=rsa-sha256; cv=none; b=bhn6sc0MwKA7G/2qgl/SrDfSEBnwqx4i0Rdbu2NwQs8H49hJpCt/YQG51t8KdFefCCHqQ6 zSZoaItV4u4K93uEj+FaUE4k5/2Mc29bKgcVPmB4LXWYixAgiVvHghVcdP1y64tp4/vpD/ v2IBgiIVLqzwIrLZpV1VxHCrUWY7/kwGAq32uigQR3LHLs0dLQJcBkuN/pCMs0BbNOZQA+ o4JioBgoXVoepZIEQvQRfSdwAajTJaNMtIp2RDB6NTJInnPcHBim0XRXU1vi0SWMOzbqe7 SmrU6TJMRLaBsiqV7TChoTcVBE8dSoGGM6a7R2XB26hDfZ/9sJUXfB7LUx0dBw== 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 5043685AF4 for ; Wed, 30 Oct 2024 08:09:55 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t62pX-00051v-NB; Wed, 30 Oct 2024 03:09:23 -0400 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 1t62pW-00051f-GA for help-guix@gnu.org; Wed, 30 Oct 2024 03:09:22 -0400 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t62pU-0000D0-9K for help-guix@gnu.org; Wed, 30 Oct 2024 03:09:22 -0400 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4315abed18aso58304175e9.2 for ; Wed, 30 Oct 2024 00:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730272156; x=1730876956; darn=gnu.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:sender:from:to :cc:subject:date:message-id:reply-to; bh=zvtwHF1zvaEd5aqOVeFdWUGouJ8xa0kMvEJ+wlPGKp4=; b=ErpSK39ulaKz0X9xxDKGF7jzPV0XmFmVQuNFl5cPawL1g1wjFYAgATVItbFux2isjq Wwl/n0EO5CmozuVXQoddiAYd+YHZMvwlE+Gu+yU3JgRtOMZnPo1eRI1KLAnZJlMYIZ9t arB3tVR0sHwnHe6wVUzOBYWqBSZOikVkVAEVsglbEeoq1WyeEXutF+PpmBSamp8xT00O O9tFh4RWcuR/8zwdNrGAbSXn5NxTydZsTIwTkljOo4OxpkDQ+7wpHh+5Ws22MBd1tsox vyH2juS5YjUykqwGqWX9cmipgjtMF7azWW0gzKl+c4Zku8+7hyNlmsuhRD+1L3CDqs71 Olpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730272156; x=1730876956; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zvtwHF1zvaEd5aqOVeFdWUGouJ8xa0kMvEJ+wlPGKp4=; b=uo1WRfC1OIfIkIWtxVpoPmnrVmLCKTKqjr4KVgIehcLSya2acLO3ppRm413N3AWvvS kIUoQilnRCqaHwC/lJQY6+fFNiex/hHpvlsaX+WEvXstHST0m9lbfPszNs804oyACThD JBIxfX+os+njPIRmDyKCC7RXLVvXz725g7NgCxzN2vA27feYfeulH1jfHFlfrPMMoXWH nMzd7qTM5Libn4XcqwicdVz59TmvxNP5BKv0Y03bpal9HDdXjLOMqg/O8XlBTHsyiwU5 L7daoR7Yb3qul8PzK5EkanKaKXpOIN2uMtJd0B2GmLd7fR6PY2FfprRW8/JCuST4VGTw RJTQ== X-Forwarded-Encrypted: i=1; AJvYcCXXD/ekUZszv+3A4G45nejoOS0AFQrfJFnH7N0XK7oed5ffCRpFZ509SGobtMfw2xWXd9724Z32YeY=@gnu.org X-Gm-Message-State: AOJu0Yzkd0Yooq/IBKknYwWfqEOwvDnUWw4nxEZpZFcV66VJ8bF3lR/+ VD9UnBcORlrPwKi0UUWg8lvqupcMR9jd+QGLTokZAMCF2ujn4gE5IPmEoJmZ X-Google-Smtp-Source: AGHT+IEQqeXq4i+wlpAv7iuMnZzD7CwFy1z26NrpbNo2O3J5IXM8jAzY4WwTGX71bsKj44v/Hc/yDQ== X-Received: by 2002:a05:600c:4d8a:b0:431:5bb1:f088 with SMTP id 5b1f17b1804b1-431aa284b53mr85363935e9.29.1730272155439; Wed, 30 Oct 2024 00:09:15 -0700 (PDT) Received: from localhost ([141.226.162.35]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38058b70bd8sm14642513f8f.87.2024.10.30.00.09.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Oct 2024 00:09:14 -0700 (PDT) Date: Wed, 30 Oct 2024 09:09:10 +0200 From: Efraim Flashner To: Christoph Buck Cc: Zack Weinberg , help-guix@gnu.org Subject: Re: ABI mismatch on boot on arm32 system Message-ID: Mail-Followup-To: Christoph Buck , Zack Weinberg , help-guix@gnu.org 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/fDnvBkBLoplpgkx" Content-Disposition: inline In-Reply-To: <87wmhqesw0.fsf@icepic.de> X-PGP-Key-ID: 0x41AAE7DCCA3D8351 X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc X-PGP-Fingerprint: A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Received-SPF: pass client-ip=2a00:1450:4864:20::331; envelope-from=efraim.flashner@gmail.com; helo=mail-wm1-x331.google.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx11.migadu.com X-Migadu-Spam-Score: 2.94 X-Spam-Score: 2.94 X-Migadu-Queue-Id: 5043685AF4 X-TUID: t/f/YE6z4vgC --/fDnvBkBLoplpgkx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 29, 2024 at 06:11:27PM +0100, Christoph Buck wrote: > Hi! >=20 > In case anybody is reading along here. I digged deeper and found > something rather interessting :P Thank you! From where I'm sitting it's much easier (for me) to suggest things than to try and setup your environment. > From my understanding by reading through the records.scm from guix (and > please note that im a total scheme newbee), the abi check works by > calculation a string-hash over the record field names and storing the > hash as hidden field in the record. During runtime this string-hash is > computed again and compared to the compiled hash. If they don't > match, the abi is broken because a field was added or removed. >=20 > The hash is calculated in the `compute-abi-cookie` procedure in the > records.scm. >=20 > I extended the procedure with the following debug outputs >=20 > --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 ...) ...) > (string-hash (object->string > (syntax->datum #'((field properties ...) ...))) > ;; (bla) > (cond-expand > (guile-3 (target-most-positive-fixnum)) > (else most-positive-fixnum)) > )))) > (fd (syntax-case field-specs () > (((field get properties ...) ...) > (object->string > (syntax->datum #'((field properties ...) ...))))))) > =20 > (format #t "Compute-abi-cookie: ~a~%" hash) > (format #t "field-specs: ~a~%" field-specs) > (format #t "fd: ~a~%" fd) > (format #t "hashsize ~a~%: " (cond-expand > (guile-3 (target-most-positive-fixnum)) > (else most-positive-fixnum))) > hash)) > --8<---------------cut here---------------end--------------->8--- >=20 > Now, if i compile a simple test record >=20 > --8<---------------cut here---------------start------------->8--- >=20 > (define-record-type* test-system > make-test-system > test-system? > (device test-system-device)=20 > (mount-point test-system-mount-point)) >=20 > (define test-abi (test-system > (device "my-root") > (mount-point "/"))) > =20 > --8<---------------cut here---------------end--------------->8--- >=20 > on x64 using guile cross-compiling (in a `guix shell --container guix > guile` environment) using the call >=20 > --8<---------------cut here---------------start------------->8--- > (with-target "arm-linux-gnueabihf" (lambda () (compile-file "test-abi.scm= "))) > --8<---------------cut here---------------end--------------->8--- >=20 > the following outputs are generated: >=20 > --8<---------------cut here---------------start------------->8--- > Compute-abi-cookie: 212719825 > field-specs: ((# #) (# #)) > fd: ((device) (mount-point)) > hashsize 536870911 > --8<---------------cut here---------------end--------------->8--- >=20 > The abi cookie is computed by calculating the string hash over > "((device) (mount-point))" while limiting the size of the hash by > 536870911. One can manually check this by calling >=20 > --8<---------------cut here---------------start------------->8--- > scheme@(guile-user)> (string-hash "((device) (mount-point))" 536870911) > $1 =3D 212719825 > --8<---------------cut here---------------end--------------->8--- >=20 > in the repl.=20 >=20 > Now, if i do the same in a qemu arm32 environment (using `guix shell > --container guix guile --system=3Darmhf-linux`), a different hash is > printed, even though the hash is calculated over the same string, see: >=20 > --8<---------------cut here---------------start------------->8--- > Compute-abi-cookie: 2434018 > field-specs: ((# #) (# #)) > fd: ((device) (mount-point)) > hashsize 536870911 > --8<---------------cut here---------------end--------------->8--- >=20 > You can verify this in the repl as well: >=20 > --8<---------------cut here---------------start------------->8--- > scheme@(guile-user)> (string-hash "((device) (mount-point))" 536870911) > $1 =3D 2434018 > --8<---------------cut here---------------end--------------->8--- >=20 > My first intuition after seeing the source of `compute-abi-cookie` was, > that maybe the `target-most-positive-fixnum` results in an wrong value > when called in a cross-compile context. But as you can see, this is not > the case. Instead, the `string-hash` calculates a different hash > even thought the input values are the same. >=20 > Now, i am not even sure if one can expect that hash functions running on > different architectures result in the same hash if the input is the > same. If not, then the implementation in guix record.scm would be > buggy. If one expects that the hash of `string-hash` for the same input > must be the same regardless of the architecture, then this would hint to > a bug in the `string-hash` function in guile for arm32. >=20 > Any inputs and thoughts regarding this issue would be appreciated. >=20 Can you run it again, but with i686 -> armhf, and x86_64 -> i686? My curiosity includes i686 -> x86_64, but I suspect it won't tell us anything we won't learn from the previous tests. --=20 Efraim Flashner =D7=A8=D7=A0=D7=A9=D7=9C=D7=A4 = =D7=9D=D7=99=D7=A8=D7=A4=D7=90 GPG key =3D A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted --/fDnvBkBLoplpgkx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmch25MACgkQQarn3Mo9 g1Fq/hAAuuh3JR857PWTs7CR2AP2bSbF2+7mSyp0u4jcNK5RISoK2k1rqqq4394K nTU29quYEW6i7EYVKcCZ/eKnS3Lw8DmBnruyXTUvxo6v5/k9idrDyOYLZlWQF8aQ TLTlX3RCJ+EwDOkhoY8DDBj6m4AYSt6Z4y6TtnpAfkgid5Lz1YpPCdAijR6Tv+yg SbZduWp+OTDatwgm/IfUCf4SQ/BjtAKp8kccSBe9Fs8VrzsrtUPtv8I4ZTQWsdBm 2p3Hd+UbD7nHf5qZI8I2CrWkDmjK6UEGIbeBNVkoKQNNQq06y5jRyIpVXtaXwy3B wOLTb6XCUBIPtDFJMgNa9Yv3oGXh5yoFPblSlWChrkopz8ZNQ8/h+ULA5KCw8rz6 Jo2YeW4pqdUeD6Zd0v4cPdMikyWpTAJXGXSM1ursevVJ57F+iVRVk8DFsR62ydXI fu3fhRNmi6vMxra1lk/3UnY+KrxZe8drhLQBXtZFBbkx1r/q1TUswB3Dx9Bbk6Hu hkUUegKxCYxNK8KxSKcT4KNG3i9NOU7tCM3RjhQ1fvzc1OmtAz0em0FR+8Z/2hFE 9RS8AF5f9FFbF15VP+YJQtSbroNwABALj+9KqyqymqZ2plntY2HoxOez8Wo7+gEc LuekIB7KaQGfiheYrjrqC5X6id9M9Op379b2UucJXp/ykg6LaF0= =6Nxc -----END PGP SIGNATURE----- --/fDnvBkBLoplpgkx--