On Thu, 07 Feb 2019 09:46:07 -0000
Giovanni Mascellani <g...@debian.org> wrote:
> Public bug reported:
>
> qemu-s390x in user mode crashes with SIGILL (under host architecture
> x86_64, running Debian unstable) when executing target instruction
> "stck" ("STORE CLOCK", see
> https://www-01.ibm.com/support/docview.wss?uid=isg26480faec85f44e2385256d5200627dee&aid=1),
> which is basically a kind of equivalent of Intel "rdtsc". The same
> instruction works fine under qemu-s390x in system mode. The bug is
> reproducible with both the qemu version distributed in Debian unstable
> and with the latest upstream master (commit
> 47994e16b1d66411953623e7c0bf0cdcd50bd507).
Did that work before commit 7de3b1cdc67 ("s390x/tcg: properly implement
the TOD")?
>
> This bug manifested itself as a crash of ssh-keygen program, which uses
> "stck" to obtain some bits of randomness during key creation. Bisection
> of the code led to the attached minimal example. Compile with (inside an
> s390x system):
>
> $ gcc -c -o test.o test.c
> $ gcc -c -o rdtsc.o rdtsc.S
> $ gcc -o test test.o rdtsc.o
>
> Then run test. It will crash with SIGILL in user mode and run fine in
> system mode. Also, compare with the original file at
> https://github.com/openssl/openssl/blob/master/crypto/s390xcpuid.pl#L139
> (there the instruction "stckf" is also used; it is probable that it has
> the same problem if it is supported altogether, but it did not test for
> this).
stckf will end up at the same helper, so it seems likely to hit the
same problem.
>
> Running qemu-s390x with options -d
> in_asm,out_asm,op,op_opt,exec,nochain,cpu gives the trace attached in
> log.txt.
I think the problem is that the helper tries to access the todstate
object, which we won't have in user mode IIUC. David?
