[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug 1893040] Re: External modules retreval using Go1.15 on s390x appear
From: |
Ruixin Bao |
Subject: |
[Bug 1893040] Re: External modules retreval using Go1.15 on s390x appears to have checksum and ECDSA verification issues |
Date: |
Tue, 27 Apr 2021 20:17:32 -0000 |
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