diff options
Diffstat (limited to 'results/classifier/zero-shot/016/assembly-x86')
6 files changed, 449 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/016/assembly-x86/1156313 b/results/classifier/zero-shot/016/assembly-x86/1156313 new file mode 100644 index 00000000..f3c30a2a --- /dev/null +++ b/results/classifier/zero-shot/016/assembly-x86/1156313 @@ -0,0 +1,147 @@ +x86: 0.943 +assembly: 0.861 +operating system: 0.178 +debug: 0.028 +files: 0.011 +TCG: 0.007 +kernel: 0.006 +hypervisor: 0.006 +register: 0.005 +user-level: 0.004 +architecture: 0.004 +semantic: 0.003 +PID: 0.002 +device: 0.002 +performance: 0.002 +virtual: 0.002 +VMM: 0.001 +boot: 0.001 +KVM: 0.001 +risc-v: 0.001 +vnc: 0.001 +graphic: 0.001 +permissions: 0.000 +socket: 0.000 +ppc: 0.000 +network: 0.000 +peripherals: 0.000 +mistranslation: 0.000 +alpha: 0.000 +i386: 0.000 +arm: 0.000 + +X86-64 flags handling broken + +The current qemu sources cause improper handling of flags on x86-64. +This bug seems to have shown up a few weeks ago. + +A plain install of Debian GNU/Linux makes user processes catch +spurious signals. The kernel seems to run stably, though. + +The ADX feature works very poorly. It might be related; at least it +allows for reproducibly provoking invalid behaviour. + +Here is a test case: + +================================================================ +qemumain.c +#include <stdio.h> +long adx(); +int +main () +{ + printf ("%lx\n", adx (0xffbeef, 17)); + return 0; +} +================================================================ +qemuadx.s: + .globl adx +adx: xor %rax, %rax +1: dec %rdi + jnz 1b + .byte 0xf3, 0x48, 0x0f, 0x38, 0xf6, 0xc0 # adox %rax, %rax + .byte 0x66, 0x48, 0x0f, 0x38, 0xf6, 0xc0 # adcx %rax, %rax + ret +================================================================ + +Compile and execute: +$ gcc -m64 qemumain.c qemuadx.s +$ a.out +ffffff8000378cd8 + +Expected output is simply "0". The garbage value varies between qemu +compiles and guest systems. + +Note that one needs a recent GNU assembler in order to handle adox and +adcx. For convenience I have supplied them as byte sequences. + +Exaplanation and feeble analysis: + +The 0xffbeef argument is a loop count. It is necessary to loop for a +while in order to trigger this bug. If the loop count is decreased, +the bug will seen intermittently; the lower the count, the less +frequent the invalid behaviour. + +It seems like a reasonable assumption that this bug is related to +flags handling at context switch. Presumably, qemu keeps flags state +in some internal format, then recomputes then when needing to form the +eflags register, as needed for example for context switching. + +I haven't tried to reproduce this bug using qemu-x86_64 and SYSROOT, +but I strongly suspect that to be impossible. I use +qemu-system-x86_64 and the guest Debian GNU/Linux x86_64 (version +6.0.6) . + +The bug happens also with the guest FreeBSD x86_64 version 9.1. (The +iteration count for triggering the problem 50% of the runs is not the +same when using the kernel Linux and FreeBSD's kernel, presumably due +to different ticks.) + +The bug happens much more frequently for a loaded system; in fact, the +loop count can be radically decreased if two instances of the trigger +program are run in parallel. + +Richard Henderson <email address hidden> writes: + + Patch at http://patchwork.ozlabs.org/patch/229139/ + +Thanks. I can confirm that this fixes the bug triggered by my test case +(and yours). However, the instability of Debian GNU/Linux x86_64 has +not improved. + +The exact same Debian version (debian "testing") updated at the same +time runs well on hardware. + +My qemu Debian system now got messed up, since I attempted an upgrade in +the buggy qemu, which segfaulted several times during the upgrade. I +need to reinstall, and then rely on -snapshot. + +There is a problem with denorms which is reproducible, but whether that +is a qemu bug, and whether it can actually cause the observed +instability, is questionable. Here is a testcase for that problem: + + + + +It should terminate. The observed buggy behaviour is that it hangs. + +The instability problem can be observed at gmplib.org/devel/tm-date.html. +hwl-deb.gmplib.org is Debian under qemu with -cpu Haswell,+adx. + +Not that the exact same qemu runs FreeBSD flawlessly (hwl.gmplib.org). +It is neither instable nor does it run the denorms testcase poorly. + +I fully realise this is a hopeless bug report, but I am sure you can +reproduce it, since it is far from GMP specific. After all apt-get +update; apt-get upgrade triggered it. Debugging it will be a nightmare. + +Qemu version: main git repo from less than a week ago + Richard ADX +patch. + +-- +Torbjörn + + +It looks from this bug that we fixed the initial ADOX bug in commit c53de1a2896cc (2013), and I've just tried the 'qemu-denorm-problem.s' test case from comment #1 and it works OK, so I think we've fixed that denormals bug too. Given that, and that this bug report is 4 years old, I'm going to close it. If you're still having problems with recent versions of QEMU, please open a new bug. + + diff --git a/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_addsubps b/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_addsubps new file mode 100644 index 00000000..4aba98a8 --- /dev/null +++ b/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_addsubps @@ -0,0 +1,55 @@ +x86: 1.000 +assembly: 0.992 +semantic: 0.981 +i386: 0.817 +debug: 0.106 +register: 0.039 +files: 0.031 +user-level: 0.025 +risc-v: 0.019 +virtual: 0.016 +PID: 0.014 +TCG: 0.013 +VMM: 0.010 +performance: 0.010 +kernel: 0.008 +architecture: 0.008 +operating system: 0.007 +alpha: 0.006 +network: 0.006 +device: 0.004 +permissions: 0.004 +boot: 0.004 +hypervisor: 0.003 +socket: 0.003 +peripherals: 0.003 +vnc: 0.002 +graphic: 0.002 +KVM: 0.002 +ppc: 0.001 +mistranslation: 0.001 +arm: 0.000 + +x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN + +Description of problem +The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different. + +Steps to reproduce + +Compile this code + +void main() { + asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];"); + asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];"); + asm("addsubps xmm1, xmm2"); +} + +Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2. + +CPU xmm1[3] = 0xffffffff + +QEMU xmm1[3] = 0x7fffffff + +Additional information +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_adox b/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_adox new file mode 100644 index 00000000..172b6260 --- /dev/null +++ b/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_adox @@ -0,0 +1,68 @@ +x86: 1.000 +assembly: 0.986 +semantic: 0.984 +i386: 0.965 +debug: 0.322 +register: 0.126 +operating system: 0.048 +files: 0.023 +TCG: 0.018 +kernel: 0.015 +performance: 0.015 +virtual: 0.013 +user-level: 0.009 +architecture: 0.007 +PID: 0.007 +device: 0.005 +peripherals: 0.005 +hypervisor: 0.004 +VMM: 0.004 +KVM: 0.003 +network: 0.002 +boot: 0.002 +graphic: 0.002 +permissions: 0.002 +socket: 0.002 +alpha: 0.002 +risc-v: 0.002 +ppc: 0.001 +vnc: 0.001 +mistranslation: 0.000 +arm: 0.000 + +x86 ADOX and ADCX semantic bug +Description of problem +The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different. + +Steps to reproduce + +Compile this code + + +void main() { + asm("push 512; popfq;"); + asm("mov rax, 0xffffffff84fdbf24"); + asm("mov rbx, 0xb197d26043bec15d"); + asm("adox eax, ebx"); +} + + + +Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF). + +CPU + +OF = 0 + + +QEMU + +OF = 1 + + + + + + +Additional information +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_bextr b/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_bextr new file mode 100644 index 00000000..3d1539ef --- /dev/null +++ b/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_bextr @@ -0,0 +1,57 @@ +x86: 1.000 +assembly: 0.991 +semantic: 0.982 +i386: 0.980 +debug: 0.687 +register: 0.219 +user-level: 0.151 +operating system: 0.067 +virtual: 0.044 +files: 0.029 +kernel: 0.023 +hypervisor: 0.017 +performance: 0.017 +TCG: 0.016 +architecture: 0.009 +PID: 0.008 +peripherals: 0.007 +device: 0.007 +network: 0.006 +alpha: 0.003 +risc-v: 0.003 +VMM: 0.003 +permissions: 0.002 +socket: 0.002 +KVM: 0.002 +graphic: 0.002 +boot: 0.002 +ppc: 0.001 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.000 + +x86 BEXTR semantic bug +Description of problem +The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit. + +Steps to reproduce + +Compile this code + +void main() { + asm("mov rax, 0x17b3693f77fb6e9"); + asm("mov rbx, 0x8f635a775ad3b9b4"); + asm("mov rcx, 0xb717b75da9983018"); + asm("bextr eax, ebx, ecx"); +} + +Execute and compare the result with the CPU. + +CPU +RAX = 0x5a + +QEMU +RAX = 0x635a775a + +Additional information +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_blsi b/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_blsi new file mode 100644 index 00000000..002bc4ec --- /dev/null +++ b/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_blsi @@ -0,0 +1,52 @@ +x86: 1.000 +assembly: 0.985 +semantic: 0.981 +i386: 0.962 +debug: 0.206 +register: 0.172 +operating system: 0.060 +performance: 0.033 +kernel: 0.027 +files: 0.026 +TCG: 0.018 +architecture: 0.012 +virtual: 0.011 +user-level: 0.010 +PID: 0.009 +peripherals: 0.007 +device: 0.006 +risc-v: 0.005 +VMM: 0.005 +alpha: 0.005 +hypervisor: 0.004 +network: 0.004 +permissions: 0.003 +boot: 0.003 +KVM: 0.003 +graphic: 0.003 +socket: 0.002 +vnc: 0.001 +mistranslation: 0.001 +ppc: 0.000 +arm: 0.000 + +x86 BLSI and BLSR semantic bug +Description of problem +The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different. + +Steps to reproduce + +Compile this code + + +void main() { + asm("blsi rax, rbx"); +} + + + +Execute and compare the result with the CPU. The value of CF is exactly the opposite. This problem happens with BLSR, too. + + +Additional information +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_bzhi b/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_bzhi new file mode 100644 index 00000000..fc53b1ca --- /dev/null +++ b/results/classifier/zero-shot/016/assembly-x86/gitlab_semantic_bzhi @@ -0,0 +1,70 @@ +x86: 1.000 +i386: 0.989 +assembly: 0.989 +semantic: 0.987 +debug: 0.282 +register: 0.159 +operating system: 0.067 +kernel: 0.025 +files: 0.022 +TCG: 0.021 +performance: 0.021 +virtual: 0.020 +user-level: 0.013 +hypervisor: 0.010 +architecture: 0.009 +PID: 0.008 +device: 0.008 +peripherals: 0.007 +KVM: 0.004 +network: 0.004 +VMM: 0.003 +risc-v: 0.003 +socket: 0.003 +permissions: 0.003 +boot: 0.003 +alpha: 0.002 +graphic: 0.002 +vnc: 0.001 +ppc: 0.001 +mistranslation: 0.001 +arm: 0.000 + +x86 BZHI semantic bug +Description of problem +The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different. + +Steps to reproduce + +Compile this code + + +void main() { + asm("mov rax, 0xb1aa9da2fe33fe3"); + asm("mov rbx, 0x80000000ffffffff"); + asm("mov rcx, 0xf3fce8829b99a5c6"); + asm("bzhi rax, rbx, rcx"); +} + + + +Execute and compare the result with the CPU. + +CPU + +RAX = 0x0x80000000ffffffff +SF = 1 + + +QEMU + +RAX = 0xffffffff +SF = 0 + + + + + + +Additional information +This bug is discovered by research conducted by KAIST SoftSec. |