GNU bug report logs - #74296
[PATCH 0/1] Fix abi mismatch error on boot for cross-compiled images

Previous Next

Full log

View this message in rfc822 format

From: Christoph Buck <dev <at> icepic.de>
To: 74296 <at> debbugs.gnu.org
Cc: Christoph Buck <dev <at> icepic.de>, Christopher Baines <guix <at> cbaines.net>, Josselin Poiret <dev <at> jpoiret.xyz>, Ludovic Courtès <ludo <at> gnu.org>, Mathieu Othacehe <othacehe <at> gnu.org>, Simon Tournier <zimon.toutoune <at> gmail.com>, Tobias Geerinckx-Rice <me <at> tobias.gr>
Subject: [bug#74296] [PATCH 0/1] Fix abi mismatch error on boot for cross-compiled images
Date: Sun, 10 Nov 2024 17:43:39 +0100

Hi!

The following patch fixes the `record-abi-mismatch-error` early on boot during
execution of initrd.cpio.gz if the image was cross-compiled on x64 for an
32bit platform (e.g arm32 or i868).

For a comprehensive analysis see the correspond thread [1] on the guix-help
mailing list.

The root cause of the issue is as follows:

During compilation guix stores a hash of the record field names in the
compiled go files. On runtime this has is recalcuated and checked against the
stored hash to verify that no abi mismatch occured. As described in [1] this
hash differs if the corresponding record was compiled in a cross-compiled
context. Guile uses internally an `unsigned long` to store the hash, which
results in hashes of different sizes depending on the platform the guile
compiler is executed on. Guix already tries to work around this problem by
limiting the size of the hash in a cross-compile context to the most positive
fixnum size of the target, but this is insufficient, because, as one can look
up in the guile source code, the size is limited by an modulo operation after
the hash was already calculated for an 8byte unsigned long. Therefore the
resulting hashes during compilation and execution are different and an abi
mismatch error is erroneously reported during runtime.

An easy workaround is documented in the guile src namely in an comment of the
`JENKINS_LOOKUP3_HASHWORD2`, which is used to calculate the hash:

> 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.

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. This is what this
patch tries to accomplish.

Imho this approach has two drawbacks. Lost entropy on 64 bit machines and the
abi break because on new compilation the hash values on 64bit platforms will
change. The lost entropy is irrelevant because the hash is not used in an
cryptophically relevant context. For the abi break i am not sure how severe
this change is.


[1] ABI mismatch on boot on arm32 system

(https://lists.gnu.org/archive/html/help-guix/2024-11/msg00022.html)


Christoph Buck (1):
  guix: records: Fix abi check in cross compile context

 guix/records.scm | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)


base-commit: 2a6d96425eea57dc6dd48a2bec16743046e32e06
-- 
2.45.1

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.