Hello @davidhildenbrand, I have been looking into this bug recently. So far, I noticed a few things:
1: Similarly as described in comment #5, I also had success building the go file described in the reproducing steps in #4 using Ubunutu-20.04 with recent qemu-system-s390x (I did it 1 - 2 weeks ago, so it is likely qemu-6.0rc2 or rc3) 2: Similarly as described in commment #9, when qemu-user-static is used, there are "ECDSA verification failure". The failure is using multiarch /qemu-user-static with qemu-s390x 6.0.0-rc3 statically built from source and copied in when building the container 3: Debugging in a container has been really difficult for me, so I used chroot and debootstrap to emulate a full s390x file system on a x86 host and copy the qemu-s390x binary in. I find that I can still reproduce the error similarly as the container. However, I also find that if I turn the vector instruction off with vx=off and split the go command into multiple steps, I am no longer able to reproduce the error. The reason for splitting the commands is that it looks like go build first calls go mod tidy, then calls go tool compile to compile the program. Through experimentation, those appear to call some other binary so the vx=off is dropped. ———————————— Build steps ———————————— root@skewered1:~/example.com/hello# ls go.mod hello.go root@skewered1:~/example.com/hello# vim go.mod root@skewered1:~/example.com/hello# ls go.mod hello.go root@skewered1:~/example.com/hello# uname -a Linux xxx (hidden) 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 s390x GNU/Linux root@skewered1:~/example.com/hello# file /usr/bin/qemu-s390x-6.0rc5-static /usr/bin/qemu-s390x-6.0rc5-static: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, Bui ldID[sha1]=28d90b247aa25813da5b24d07707863f089a78eb, for GNU/Linux 3.2.0, stripped root@skewered1:~/example.com/hello# /usr/bin/qemu-s390x-6.0rc5-static --version qemu-s390x version 5.2.95 (v6.0.0-rc5) Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers root@skewered1:~/example.com/hello# root@skewered1:~/example.com/hello# go version go version go1.15.11 linux/s390x root@skewered1:~/example.com/hello# root@skewered1:~/example.com/hello# which go /usr/local/go/bin/go root@skewered1:~/example.com/hello# /usr/bin/qemu-s390x-6.0rc5-static /usr/local/go/bin/go build . go: finding module for package rsc.io/quote hello.go:4:5: module rsc.io/quote: Get "https://proxy.golang.org/rsc.io/quote/@v/list": tls: invalid signature by the server certificate: ECDSA verification failure root@skewered1:~/example.com/hello# /usr/bin/qemu-s390x-6.0rc5-static -cpu qemu,vx=off /usr/local/go/bin/go mod tidy go: finding module for package rsc.io/quote go: downloading rsc.io/quote v1.5.2 go: found rsc.io/quote in rsc.io/quote v1.5.2 go: downloading rsc.io/sampler v1.3.0 go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c root@skewered1:~/example.com/hello# /usr/bin/qemu-s390x-6.0rc5-static -cpu qemu,vx=off /usr/local/go/bin/go build . root@skewered1:~/example.com/hello# ls go.mod go.sum hello hello.go root@skewered1:~/example.com/hello# file hello hello: ELF 64-bit MSB executable, IBM S/390, version 1 (SYSV), statically linked, not stripped root@skewered1:~/example.com/hello# ./hello Hello, world. 4: The above findings make me think that there is some discrepancy between vector instructions handling for qemu user mode vs system mode. Additionally, running tests with vx=off in go/src/crypto/ecdsa will make the test pass while without vx=off, there remains to be a problem. Currently, I am looking into the go source code hoping to narrow down the problem. It looks like the difference (between qemu-user and s390x native host) happens during initTable() function at crypto/elliptic/p256_s390x.go. I hope the above findings make sense. It will be great if you can share some possible insights for where that discrepancy (between qemu-user and qemu-system) could be. Much appreciated. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1893040 Title: External modules retreval using Go1.15 on s390x appears to have checksum and ECDSA verification issues Status in QEMU: New Bug description: We are observing issue while building go-runner image and we suspect it is due to QEMU version being used. As referred in below issue: https://github.com/golang/go/issues/40949 We tried to build go-runner image using go1.15 and register QEMU (docker run --rm --privileged multiarch/qemu-user- static@sha256:c772ee1965aa0be9915ee1b018a0dd92ea361b4fa1bcab5bbc033517749b2af4 --reset -p yes) as mentioned in PR https://github.com/kubernetes/release/pull/1499. We observed below failure during build: --------------------------------------------------------------------------------- ERROR: executor failed running [/bin/sh -c CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner ${package}]: buildkit-runc did not terminate successfully ------ > [builder 7/7] RUN CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner .: ------ failed to solve: rpc error: code = Unknown desc = executor failed running [/bin/sh -c CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner ${package}]: buildkit-runc did not terminate successfully Makefile:52: recipe for target 'container' failed make: *** [container] Error 1 --------------------------------------------------------------------------------- To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1893040/+subscriptions