diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 19:39:53 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 19:39:53 +0200 |
| commit | dee4dcba78baf712cab403d47d9db319ab7f95d6 (patch) | |
| tree | 418478faf06786701a56268672f73d6b0b4eb239 /results/classifier/118/user-level-risc-v | |
| parent | 4d9e26c0333abd39bdbd039dcdb30ed429c475ba (diff) | |
| download | emulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.tar.gz emulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.zip | |
restructure results
Diffstat (limited to 'results/classifier/118/user-level-risc-v')
| -rw-r--r-- | results/classifier/118/user-level-risc-v/1366836 | 135 | ||||
| -rw-r--r-- | results/classifier/118/user-level-risc-v/1606 | 89 | ||||
| -rw-r--r-- | results/classifier/118/user-level-risc-v/1829 | 148 |
3 files changed, 0 insertions, 372 deletions
diff --git a/results/classifier/118/user-level-risc-v/1366836 b/results/classifier/118/user-level-risc-v/1366836 deleted file mode 100644 index c45929b3..00000000 --- a/results/classifier/118/user-level-risc-v/1366836 +++ /dev/null @@ -1,135 +0,0 @@ -user-level: 0.911 -permissions: 0.888 -debug: 0.866 -semantic: 0.861 -mistranslation: 0.849 -TCG: 0.844 -register: 0.836 -VMM: 0.829 -virtual: 0.823 -KVM: 0.818 -boot: 0.817 -risc-v: 0.813 -architecture: 0.812 -device: 0.812 -PID: 0.806 -arm: 0.805 -peripherals: 0.804 -assembly: 0.801 -graphic: 0.794 -performance: 0.789 -hypervisor: 0.786 -kernel: 0.779 -ppc: 0.775 -vnc: 0.770 -files: 0.747 -socket: 0.718 -x86: 0.684 -network: 0.604 -i386: 0.509 --------------------- -x86: 0.975 -register: 0.916 -KVM: 0.861 -kernel: 0.771 -debug: 0.696 -boot: 0.691 -hypervisor: 0.590 -virtual: 0.164 -PID: 0.044 -files: 0.042 -assembly: 0.040 -user-level: 0.030 -TCG: 0.012 -performance: 0.011 -architecture: 0.005 -socket: 0.005 -device: 0.005 -risc-v: 0.004 -semantic: 0.003 -i386: 0.002 -graphic: 0.001 -peripherals: 0.001 -VMM: 0.001 -permissions: 0.001 -network: 0.001 -vnc: 0.000 -mistranslation: 0.000 -ppc: 0.000 -arm: 0.000 - -Core2Duo and KVM may not boot Win8 properly on 3.x kernels - -When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel -3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. -When I dump the CPU registers via "info registers", nothing changes, that means -the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. - -But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on -the host side it works on the Core2Duo. Also the system above but just with an -i3 or i5 CPU it works fine. - -I already disabled networking and USB for the guest and changed the graphics -card - no effect. I assume that some mean bits and bytes have to be set up -properly to get the thing running. - -Seems to be related to a kvm/progressor incompatibility. - -Here the register dump of the stalled Win8 -QEMU 2.1.0 monitor - type 'help' for more information -(qemu) info registers -EAX=3e2009e3 EBX=3e2009e3 ECX=80000000 EDX=80000000 -ESI=3e2009e3 EDI=8220c108 EBP=81f9b33c ESP=81f9b2f0 -EIP=80c98d83 EFL=00010282 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0 -ES =0023 00000000 ffffffff 00c0f300 DPL=3 DS [-WA] -CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] -SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] -DS =0023 00000000 ffffffff 00c0f300 DPL=3 DS [-WA] -FS =0030 80e65000 00004280 00409300 DPL=0 DS [-WA] -GS =0000 00000000 ffffffff 00000000 -LDT=0000 00000000 ffffffff 00000000 -TR =0028 80353000 000020ab 00008b00 DPL=0 TSS32-busy -GDT= 80a37000 000003ff -IDT= 80a37400 000007ff -CR0=8001003b CR2=8b206090 CR3=00185000 CR4=000406e9 -DR0=0000000000000000 DR1=0000000000000000 DR2=0000000500000000 DR3=0000000000000000 -DR6=00000000ffff0ff0 DR7=0000000000000400 -EFER=0000000000000800 -FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 -FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 -FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 -FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 -FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 -XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 -XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 -XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 -XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 - - -I found a new trace - using the ipipe patch that I have, there seems to be an issue in the 3.4 kernels, but as it looks also in the 3.10 kernels. -http://www.xenomai.org/pipermail/xenomai/2013-March/027865.html - -Is there an update on that already existing? It was not completely clear if this issue is related either to KVM or to the ipipe patch. - -Thanks. - -attached the trace.dat (tar-gzipped) as recommended. Hope this helps finding the issue. The file should capture the following: -- windows 8 with screen that shows that the last boot attempts failed -- issued system_reset on qemu commandline -- startup of windows 8 that stalls - - -sorry for the corrupt file, this one should be fine now. - -Confirmed - the current kvm.git without any ipipe patch also causes the issue. Trace File attached. - -Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? - -Please close it, it's solved with this patch commit to kvm / kernel: -Was found and fixed with great support of Paolo Bonzini - -From: Paolo Bonzini -Date: Thu, 12 Feb 2015 17:04:47 +0100 -Subject: KVM: emulate: fix CMPXCHG8B on 32-bit hosts - - diff --git a/results/classifier/118/user-level-risc-v/1606 b/results/classifier/118/user-level-risc-v/1606 deleted file mode 100644 index 605d9430..00000000 --- a/results/classifier/118/user-level-risc-v/1606 +++ /dev/null @@ -1,89 +0,0 @@ -user-level: 0.995 -risc-v: 0.953 -ppc: 0.826 -graphic: 0.812 -VMM: 0.790 -KVM: 0.777 -device: 0.740 -vnc: 0.739 -performance: 0.728 -permissions: 0.728 -x86: 0.676 -PID: 0.623 -semantic: 0.602 -i386: 0.565 -architecture: 0.559 -virtual: 0.534 -socket: 0.527 -network: 0.516 -hypervisor: 0.479 -TCG: 0.464 -kernel: 0.424 -register: 0.402 -debug: 0.391 -files: 0.355 -peripherals: 0.344 -assembly: 0.316 -boot: 0.313 -arm: 0.294 -mistranslation: 0.266 --------------------- -user-level: 0.985 -debug: 0.529 -x86: 0.209 -kernel: 0.158 -performance: 0.073 -files: 0.040 -i386: 0.034 -risc-v: 0.031 -virtual: 0.021 -ppc: 0.020 -TCG: 0.018 -hypervisor: 0.015 -PID: 0.013 -arm: 0.011 -device: 0.011 -register: 0.011 -assembly: 0.011 -network: 0.009 -VMM: 0.006 -semantic: 0.006 -peripherals: 0.006 -boot: 0.005 -architecture: 0.004 -socket: 0.003 -KVM: 0.003 -graphic: 0.002 -vnc: 0.002 -permissions: 0.002 -mistranslation: 0.001 - -riscv: fence.i is not functional -Description of problem: -The attached user-level test is designed to do the following (in iteration): - - - Thread P0 on CPU0 changes some text/code, while - - - Thread P1 on CPU1 checks/reads the code, fence.i, then executes the same code. - -Results (in stdout) indicates that CPU1 has read the new code (1:x5=a009) but executed the old one (1:x7=1) (against the specification). -Steps to reproduce: -1. echo 2 > /proc/sys/vm/nr_hugepages -2. ./CoRF+fence.i -Additional information: -Example output: -```[CoRF+fence.i.c](/uploads/c150ca0910783cc4bfc3886789b64c28/CoRF+fence.i.c) -Test CoRF+fence.i Allowed -Histogram (4 states) -25784 :>1:x5=0xa009; 1:x7=2; -24207 *>1:x5=0xa009; 1:x7=1; <-- THIS LINE -8 :>1:x5=0xa019; 1:x7=1; -1 :>1:x5=0xa019; 1:x7=2; -Ok -Witnesses -Positive: 24207 Negative 25793 -Condition exists (1:x5=0xa009 /\ 1:x7=1) is validated -Observation CoRF+fence.i Sometimes 24207 25793 -Time CoRF+fence.i 0.85 -Hash= -``` diff --git a/results/classifier/118/user-level-risc-v/1829 b/results/classifier/118/user-level-risc-v/1829 deleted file mode 100644 index e8eaf6f9..00000000 --- a/results/classifier/118/user-level-risc-v/1829 +++ /dev/null @@ -1,148 +0,0 @@ -risc-v: 0.971 -user-level: 0.890 -vnc: 0.879 -KVM: 0.851 -debug: 0.839 -ppc: 0.834 -TCG: 0.831 -permissions: 0.831 -performance: 0.826 -network: 0.816 -architecture: 0.813 -hypervisor: 0.812 -register: 0.805 -graphic: 0.801 -VMM: 0.800 -mistranslation: 0.800 -virtual: 0.798 -assembly: 0.790 -x86: 0.789 -socket: 0.778 -peripherals: 0.776 -semantic: 0.770 -arm: 0.769 -kernel: 0.758 -i386: 0.754 -device: 0.745 -PID: 0.738 -files: 0.704 -boot: 0.642 --------------------- -virtual: 0.965 -x86: 0.959 -TCG: 0.959 -device: 0.856 -PID: 0.805 -risc-v: 0.730 -files: 0.441 -VMM: 0.425 -vnc: 0.377 -debug: 0.147 -ppc: 0.079 -register: 0.050 -socket: 0.031 -KVM: 0.029 -graphic: 0.029 -kernel: 0.022 -assembly: 0.022 -network: 0.012 -boot: 0.011 -architecture: 0.011 -user-level: 0.010 -permissions: 0.010 -performance: 0.010 -semantic: 0.010 -mistranslation: 0.009 -hypervisor: 0.006 -i386: 0.006 -peripherals: 0.005 -arm: 0.001 - -DoS via assert failure by guest user -Description of problem: -As root in guest VM user can execute special script, which crashes the whole VM with error - -```plaintext -hw/display/qxl.c:1594 inside of function void qxl_set_mode(PCIQXLDevice *, unsigned int, int): Assertion `qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0` failed -``` -Steps to reproduce: -1. This bug can be reproduced with: - - ```bash - cat << EOF | ./build/qemu-system-x86_64 -vga qxl -m 2048 -nodefaults -qtest stdio - outl 0xcf8 0x8000101c - outl 0xcfc 0xc000 - outl 0xcf8 0x80001001 - outl 0xcfc 0x01000000 - outl 0xc006 0x00 - EOF - ``` -2. Also, we can execute this python3 script inside guest VM as root (to invoke VM use command: **_qemu-system-x86_64 -vga qxl -hda debian.img -m 2048 -nodefaults_**): - - ```python - import os - f = os.open("/dev/port", os.O_RDWR|os.O_NDELAY) - l = os.lseek(f, 0xcf8, 0) - os.write(f, b'\x80\x00\x10\x1c') - l = os.lseek(f, 0xcfc, 0) - os.write(f, b'\xc0\x00') - l = os.lseek(f, 0xcf8, 0) - os.write(f, b'\x80\x00\x10\x01') - l = os.lseek(f, 0xcfc, 0) - os.write(f, b'\x01\x00\x00\x00') - l = os.lseek(f, 0xc006, 0) - os.write(f, b'\x00') - ``` - - This script causes VM to crash. - - [PoC_qxl-vga_crash.mkv](/uploads/7ee262c20dca69aa9417812f6a93a532/PoC_qxl-vga_crash.mkv) -Additional information: -This issue was found by fuzzing. Here is an auto-generated C source code for a test case that will reproduce the bug. - -```plaintext -/* - * Autogenerated Fuzzer Test Case - * - * Copyright (c) 2023 Artem Nasonov <anasonov@astralinux.ru> - * - * This work is licensed under the terms of the GNU GPL, version 2 or later. - * See the COPYING file in the top-level directory. - */ - -#include "qemu/osdep.h" - -#include "libqtest.h" - -/* - * cat << EOF | qemu-system-x86_64 -vga qxl -hda \ - * ~/Downloads/virtualdebian.img -m 2048 -nodefaults -qtest stdio - * outl 0xcf8 0x8000101c - * outl 0xcfc 0xc000 - * outl 0xcf8 0x80001001 - * outl 0xcfc 0x01000000 - * outl 0xc006 0x00 - * EOF -*/ -static void test_qxl_set_mode(void) -{ -QTestState *s = qtest_init("-vga qxl -m 2048 -nodefaults"); -qtest_outl(s, 0xcf8, 0x8000101c); -qtest_outl(s, 0xcfc, 0xc000); -qtest_outl(s, 0xcf8, 0x80001001); -qtest_outl(s, 0xcfc, 0x01000000); -qtest_outl(s, 0xc006, 0x00); -qtest_quit(s); -}int main(int argc, char **argv) -{ - const char *arch = qtest_get_arch(); - - g_test_init(&argc, &argv, NULL); - - if (strcmp(arch, "x86_64") == 0) { - qtest_add_func("fuzz/test_qxl_set_mode",test_qxl_set_mode); - } - - return g_test_run(); -} -``` |