| 2020-08-19 07:03:30 |
Christian Ehrhardt |
description |
In porting software to guest Ubuntu 18.04 and 20.04 VMs for S/390x, I discovered
that some of my own numerical programs, and also a GNU configure script for at
least one package with CC=clang, would cause an instant crash of the VM, sometimes
also destroying recently opened files, and producing long strings of NUL characters
in /var/log/syslog in the S/390 guest O/S.
Further detective work narrowed the cause of the crash down to a single IBM S/390
instruction: sqxbr (128-bit IEEE 754 square root). Here is a one-line program
that when compiled and run on a VM hosted on QEMUcc emulator version 4.2.0
(Debian 1:4.2-3ubuntu6.1) [hosted on Ubuntu 20.04 on a Dell Precision 7920
workstation with an Intel Xeon Platinum 8253 CPU], and also on QEMU emulator
version 5.0.0, reproducibly produces a VM crash under qemu-system-s390x.
% cat bug-sqrtl-one-line.c
int main(void) { volatile long double x, r; x = 4.0L; __asm__ __volatile__("sqxbr %0, %1" : "=f" (r) : "f" (x)); return (0);}
% cc bug-sqrtl-one-line.c && ./a.out
Segmentation fault (core dumped)
The problem code may be the function float128_sqrt() defined in qemu-5.0.0/fpu/softfloat.c
starting at line 7619. I have NOT attempted to run the qemu-system-s390x executable
under a debugger. However, I observe that S/390 is the only CPU family that I know of,
except possibly for a Fujitsu SPARC-64, that has a 128-bit square root in hardware.
Thus, this instruction bug may not have been seen before. |
[Impact]
* An instruction was described wrong so that on usage the program would
crash.
[Test Case]
* Run s390x in emulation and there use this program:
For simplicity and speed you can use KVM guest as usual on s390x, that
after prep&install&compile of the test you run in qemu-tcg like:
$ sudo qemu-system-s390x -machine s390-ccw-virtio,accel=tcg -cpu max,zpci=on -serial mon:stdio -display none -m 4096 -nic user,model=virtio,hostfwd=tcp::2222-:22 -drive file=/var/lib/uvtool/libvirt/images/focal-sqxbr.qcow,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-ccw,devno=fe.0.0001,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,scsi=off
Obviously is you have no s390x access you need to use emulation right
away.
* Build and run failing program
$ sudo apt install clang
$ cat > bug-sqrtl-one-line.c << EOF
int main(void) { volatile long double x, r; x = 4.0L; __asm__
__volatile__("sqxbr %0, %1" : "=f" (r) : "f" (x)); return (0);}
EOF
$ cc bug-sqrtl-one-line.c
$ ./a.out
Segmentation fault (core dumped)
qemu is dead by now as long as the bug is present
[Regression Potential]
* The change only modifies 128 bit square root on s390x so regressions
should be limited to exactly that - which formerly before this fix was
a broken instruction.
[Other Info]
* n/a
---
In porting software to guest Ubuntu 18.04 and 20.04 VMs for S/390x, I discovered
that some of my own numerical programs, and also a GNU configure script for at
least one package with CC=clang, would cause an instant crash of the VM, sometimes
also destroying recently opened files, and producing long strings of NUL characters
in /var/log/syslog in the S/390 guest O/S.
Further detective work narrowed the cause of the crash down to a single IBM S/390
instruction: sqxbr (128-bit IEEE 754 square root). Here is a one-line program
that when compiled and run on a VM hosted on QEMUcc emulator version 4.2.0
(Debian 1:4.2-3ubuntu6.1) [hosted on Ubuntu 20.04 on a Dell Precision 7920
workstation with an Intel Xeon Platinum 8253 CPU], and also on QEMU emulator
version 5.0.0, reproducibly produces a VM crash under qemu-system-s390x.
% cat bug-sqrtl-one-line.c
int main(void) { volatile long double x, r; x = 4.0L; __asm__ __volatile__("sqxbr %0, %1" : "=f" (r) : "f" (x)); return (0);}
% cc bug-sqrtl-one-line.c && ./a.out
Segmentation fault (core dumped)
The problem code may be the function float128_sqrt() defined in qemu-5.0.0/fpu/softfloat.c
starting at line 7619. I have NOT attempted to run the qemu-system-s390x executable
under a debugger. However, I observe that S/390 is the only CPU family that I know of,
except possibly for a Fujitsu SPARC-64, that has a 128-bit square root in hardware.
Thus, this instruction bug may not have been seen before. |
|
