bug: When dynamic linking, R15 may be clobbered by a global variable access

[ale-linux]

bug: When dynamic linking, R15 may be clobbered by a global variable access

[ale-linux]

we use 3 curves (bls12-377, bls12-381, bn254) directly in mathlib which is in turn used in quite a few places (idemix, fabric, aries-framework-go). See the latest issue in fabric.

[gbotrel]

Hi -- I think the best workaround for now if you are not in a perf critical workflow, is to compile with -tags=purego .

Could also be that we unnecessarily force users to import more packages than they need; do you need to link with all gnark-crypto or some specific packages only?

[ale-linux]

Thanks @gbotrel . For now I think it's acceptable to take this route but it would be good to find a long-term solution. As you can see, we're pulling gnark-crypto from half of Hyperledger's projects now 😁

[gbotrel]

Are you? :) Well that's where I'm curious -- do you need to import github.com/consensys/gnark-crypto/ecc/bls12-378/fp and github.com/consensys/gnark-crypto/ecc/bw6-633/fp for example, or are they being "vendored" or are you, as a user being forced to import all of it because in some place we accidentally imported more than we should have??

[ale-linux]

Just a clarification: in the comments to the issue I linked, you'll see the compilation failure text relating to kilic/bls12-381#42, but #468 equally affects that build.

[gbotrel]

@ale-linux I could NOT reproduce with Go 1.21.4 on Ubuntu, but could reproduce with go1.20.8.linux-amd64. Seems this part of Go 1.21 releases notes helps:

The verifier that checks for incorrect uses of R15 when dynamic linking on amd64 has been improved.

[ale-linux]

a-ha... yeah in many cases the clobbering actually did not take place because for instance the access to the global variable took place before R15 was actually used to store temp data. I would say we're good to go then - we're building with purego till we upgrade to go1.21. Thanks!