mbox series

[bug#74296,0/1] Fix abi mismatch error on boot for cross-compiled images

Message ID cover.1731253918.git.dev@icepic.de
Headers
Series Fix abi mismatch error on boot for cross-compiled images |

Message

Christoph Buck Nov. 10, 2024, 4:43 p.m. UTC 
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

Comments

Ludovic Courtès Nov. 12, 2024, 10:40 p.m. UTC | #1 
Hi Christoph,

Christoph Buck <dev@icepic.de> skribis:

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

Woow, thanks for the investigation & explanation!

(I would say that the ‘scm_ihash’ implementation as a mere modulo is
dubious, but that’s hard to change anyway.)

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

Capping at 32-bits means that potentially some ABI changes could go
unnoticed, but that’s extremely unlikely if the hash function is good
enough.

I believe the ABI break is fine too: developers will have to
“make clean-go && make”, but that’s okay.

Thoughts?  Opinions?

Ludo’.
Christoph Buck Nov. 13, 2024, 12:45 p.m. UTC | #2 
Ludovic Courtès <ludo@gnu.org> writes:

> Woow, thanks for the investigation & explanation!

Your are welcome :) I usually keep notes during investigation of bugs
and append them to my patches. This keeps my train of thought
transparent and makes it easier for others to follow along or spot
obvious errors on my side. However, it can get a little bit noisy. So
let met now if i should "keep it done" more.

> Capping at 32-bits means that potentially some ABI changes could go
> unnoticed, but that’s extremely unlikely if the hash function is good
> enough.

Yes, but this problem exits for 32bit builds in general.

> I believe the ABI break is fine too: developers will have to
> “make clean-go && make”, but that’s okay.

Good to know.
Simon Tournier Nov. 16, 2024, 7:05 a.m. UTC | #3 
Hi Christoph,

On Wed, 13 Nov 2024 at 13:45, Christoph Buck <dev@icepic.de> wrote:

>> Woow, thanks for the investigation & explanation!
>
> Your are welcome :) I usually keep notes during investigation of bugs
> and append them to my patches. This keeps my train of thought
> transparent and makes it easier for others to follow along or spot
> obvious errors on my side. However, it can get a little bit noisy. So
> let met now if i should "keep it done" more.

I like this sentence attributed to Leslie Lamport: « If you're thinking
without writing, you only think you’re thinking. ».  For what my opinion
is worth, your explanations appears to me the good ratio between the
“too much details” and the “help outsider to follow”.


Cheers,
simon
Ludovic Courtès Nov. 18, 2024, 10:07 a.m. UTC | #4 
Hi,

Christoph Buck <dev@icepic.de> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> I believe the ABI break is fine too: developers will have to
>> “make clean-go && make”, but that’s okay.
>
> Good to know.

I added a summary of your explanation as a comment in the code, so our
future selves get an idea of why things are done this way, and pushed as
23cbbe6860782c5d4a0ba599ea1cda0642e91661.

Time for “make clean-go && make”!

Thanks,
Ludo’.