6 files changed, 360 insertions, 0 deletions
diff --git a/results/classifier/108/other/1828 b/results/classifier/108/other/1828
new file mode 100644
index 00000000..d34ba2dd
--- /dev/null
+++ b/results/classifier/108/other/1828
@@ -0,0 +1,36 @@
+device: 0.840
+graphic: 0.764
+performance: 0.712
+semantic: 0.436
+PID: 0.372
+network: 0.329
+vnc: 0.296
+debug: 0.291
+socket: 0.219
+files: 0.190
+permissions: 0.190
+KVM: 0.155
+boot: 0.154
+other: 0.060
+
+[v8.0.4 regression] `qemu-system-x86_64: -accel hvf: Unknown Error`
+Description of problem:
+`-accel hvf` crashes with "Unknown Error".
+Regression in v8.0.4.
+
+The master branch doesn't seem affected.
+Steps to reproduce:
+v8.0.3:
+```console
+$ qemu-system-x86_64 -accel hvf
+(shows iPXE screen, as expected)
+```
+
+v8.0.4:
+```console
+$ qemu-system-x86_64 -accel hvf
+qemu-system-x86_64: -accel hvf: Unknown Error
+Abort trap: 6
+```
+Additional information:
+
diff --git a/results/classifier/108/other/1828207 b/results/classifier/108/other/1828207
new file mode 100644
index 00000000..b98951b6
--- /dev/null
+++ b/results/classifier/108/other/1828207
@@ -0,0 +1,54 @@
+socket: 0.670
+vnc: 0.624
+network: 0.593
+device: 0.527
+other: 0.419
+performance: 0.344
+semantic: 0.300
+files: 0.278
+PID: 0.263
+permissions: 0.217
+KVM: 0.165
+boot: 0.153
+debug: 0.117
+graphic: 0.113
+
+Request to add something like "Auth failed from IP" log report for built-in VNC server
+
+In environment with needs of public accessible VNC ports there is no logs or other registered events about authentication failures to analyze and/or integrate it to automated services like fail2ban ans so on.
+Thus the built-in VNC service is vulnerable to brutforce attacks and in combination with weak built-in VNC-auth scheme can be a security vulnerability.
+
+Adding a simple log record like "QEMU VNC Authentication failed 192.168.0.5:5902 - 123.45.67.89:7898" will permit to quickly integrate it to fail2ban system.
+
+Note that any use of the built-in VNC-auth scheme is always considered a security flaw. It should essentially never be used, especially not on any public internet facing service, even if fail2ban were able to be used.
+
+A secure VNC server should use the VeNCrypt extension which enables TLS, with optional client certificate validation as an auth mechanism.  Once you have TLS enabled, you can also then enable the SASL auth mechanism to further authenticate clients using Kerberos or PAM, or other SASL plugins.
+
+That's not to say we shouldn't emit a log message, suitable for consuming from fail2ban, as remote clients can still trigger a CPU denial of service by repeatedly connecting even if they ultimately always fail authentication.
+
+
+On Wed, 8 May 2019 at 14:23, Daniel Berrange <email address hidden> wrote:
+>
+> Note that any use of the built-in VNC-auth scheme is always considered a
+> security flaw. It should essentially never be used, especially not on
+> any public internet facing service, even if fail2ban were able to be
+> used.
+
+Should we deprecate-and-remove the feature, then ?
+
+thanks
+-- PMM
+
+
+The challenge is that this is the only auth scheme defined by the VNC protocol, aside from no-auth.
+If we removed it, we'd no longer be compatible with the standard VNC protocol. We'd be making use of the TLS/SASL extensions mandatory if users want auth. This could ultimately push people to turn off auth altogether which is even worse.
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/170
+
+
diff --git a/results/classifier/108/other/1828272 b/results/classifier/108/other/1828272
new file mode 100644
index 00000000..12a36aac
--- /dev/null
+++ b/results/classifier/108/other/1828272
@@ -0,0 +1,42 @@
+graphic: 0.919
+device: 0.767
+boot: 0.735
+performance: 0.571
+semantic: 0.535
+KVM: 0.529
+files: 0.457
+permissions: 0.452
+PID: 0.352
+other: 0.337
+network: 0.284
+socket: 0.264
+vnc: 0.232
+debug: 0.215
+
+4.0 breaks keyboard autorepeat in guests with xserver
+
+Description:
+In a linux/bsd guest within X, pressing and holding a key for a short time causes an endless repeat of that key in the guest. The release of the key gets ignored.
+Example 1: pressing and holding 'a' for a few seconds results in typing of 'aaaaaaaaaaaa...' endlessly.
+Example 2: pressing and holding 'Backspace' for a few seconds results in deleting all your previously typed text.
+
+It doesn't happen within a VT in the guest. It also doesn't happen with guests that run windows, reactos or haiku for example.
+
+The problem goes away, when disabling xorgs autorepeat function via "xset -r" in the host.
+Normally, this setting should not have any effect on the guest, since it has it's own autorepeat setting. So there is some conflict here.
+
+Steps to reproduce:
+Start any linux/bsd guest system with xserver, open a terminal, press and hold a key for a short time: Look how it gets typed endlessly (Try a few times if it doesn't happen immediately).
+The easiest way is to run a linux live cd, like this (Link to example iso :http://download.grml.org/grml64-full_2018.12.iso)
+$ qemu-system-x86_64 -enable-kvm -m 512 -boot d -cdrom grml64-full_2018.12.iso
+
+
+Qemu version info:
+QEMU emulator version 4.0.0
+Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
+
+Adding Gerd to the CC, since this is possibly caused by recent work to keyboard state tracking code.
+
+Fix has been included here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5fff13f245cddd3bc26
+
diff --git a/results/classifier/108/other/1828429 b/results/classifier/108/other/1828429
new file mode 100644
index 00000000..dcf52b56
--- /dev/null
+++ b/results/classifier/108/other/1828429
@@ -0,0 +1,38 @@
+graphic: 0.768
+semantic: 0.659
+network: 0.571
+device: 0.523
+socket: 0.363
+performance: 0.296
+vnc: 0.230
+PID: 0.213
+boot: 0.199
+files: 0.189
+other: 0.189
+permissions: 0.172
+debug: 0.149
+KVM: 0.048
+
+qemu-system-aarch64 crashes with assertion failed while running GCC 9 test suite
+
+I am using QEMU 4.0.0 on an x86_64 Linux 4.19.0 host, the guest is an Aarch64 linux 5.0.0 system. The same issue occurred on QEMU 3.1.0.
+
+While running the GCC 9.1 test suite on the guest system, QEMU crashes with:
+
+qemu-system-aarch64: [...]/qemu-4.0.0/tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed.
+
+I am able to reproduce the issue reliably, which is encouraging. The full QEMU command line is:
+
+qemu-system-aarch64 -kernel kernel-5.0.0cbl1 -append "root=/dev/vda1 ro init=/sbin/init console=ttyAMA0" -name guest=cbl -drive file=cbl.qcow2,index=0,media=disk,format=qcow2 -drive file=swap.qcow2,index=1,media=disk,format=qcow2 -machine virt -cpu cortex-a57 -smp 4,sockets=1,cores=2,threads=2 -m size=8192 -netdev tap,id=network0,ifname=tapcbl2,script=no,downscript=no -device virtio-net-device,netdev=network0,mac=aa:bb:cc:dd:ee:02 -nographic
+
+The specific GCC test that causes QEMU to crash is vldX.c run from advsimd-intrinsics.exp; I can reproduce via "make check-gcc RUNTESTFLAGS=advsimd-intrinsics.exp=vldX.c"
+
+If there is anything I can do to further triage the issue, or gain more insight into what is going on, please let me know! I am eager to help however I can.
+
+Hi -- this looks rather like bug #1824853, which exists in QEMU 4.0 but which we have fixed in git. Could you try with a build of QEMU from current head-of-git to confirm that it's fixed there ?
+
+
+I'm on it. Will follow up when I have a result.
+
+Confirmed, this is a duplicate of 1824853 and is resolved in 68a7b9724fe80bedb85060bde605213ce3f9baec.
+
diff --git a/results/classifier/108/other/1828507 b/results/classifier/108/other/1828507
new file mode 100644
index 00000000..afa4bf35
--- /dev/null
+++ b/results/classifier/108/other/1828507
@@ -0,0 +1,80 @@
+graphic: 0.679
+device: 0.671
+other: 0.655
+network: 0.600
+boot: 0.561
+semantic: 0.550
+PID: 0.513
+socket: 0.508
+permissions: 0.499
+performance: 0.459
+debug: 0.436
+vnc: 0.435
+files: 0.368
+KVM: 0.163
+
+qemu-system-ppc64 smp crash on manual reset
+
+Host Environment:
+   x86_64 Linux v5.0.2
+   QEMU emulator version 4.0.50 (v4.0.0-354-g812b835fb4)
+   SLOF:
+       Build Date = Jan 14 2019 18:00:39
+       FW Version = git-a5b428e1c1eae703
+
+Problem: Qemu crash immediately after a manual reset
+         (this is not the initial reset which launches the guest).
+
+Steps:
+
+1. Download Debian ppc64el mini.iso:
+   http://ftp.debian.org/debian/dists/sid/main/installer-ppc64el/current/images/netboot/mini.iso
+2. Run qemu on the host. Ensure that it runs with more than one CPUs. With a single CPU, I was unable
+   to reproduce the crash.
+   qemu-system-ppc64 -M pseries -cpu power9 -smp 2 -m 512 -cdrom mini.iso
+3. SLOF prints the version info on the serial device, and proceeds to boot.
+4. After a few seconds, the GRUB menu appears on the VGA screen.
+5. Select one of the install options (I have tested with Default and Expert), and wait
+   for the Debian's text-mode installer (blue-gray-red) screen to appear.
+6. Click Machine->Reset (or enter system_reset on the qemu monitor).
+7. Notice that, on the serial device, SLOF has printed the version info. That is, the system
+   has reset and is attempting to boot again.
+8. On the host cmd prompt, qemu dies after printing this fatal error and spewing the
+   contents of the CPU registers:
+
+   qemu: fatal: Trying to deliver HV exception (MSR) 70 with no HV support
+   <CPU contents> (See attached out.txt for details)
+   Aborted (core dumped)
+
+
+The HV exception is either
+   (a) 70 = HISI, which occurs when NIP contains an outright bogus or inaccessible value, or
+   (b) 69 = HDSI, which occurs when NIP happens to contain a somewhat saner value, and
+       the cpu attempts to run the instruction at that address.
+
+The exception can occur on either of the CPUs. It occurs when qemu is running the SLOF
+code.
+
+
+
+If one continues with the iso, and installs the OS in the
+guest, the rebooting of the guest from within the guest
+OS too causes qemu to exit fatally. So, one can run
+'systemctl reboot' or 'reboot' within the guest OS and
+see qemu crash (immediately after SLOF prints version,
+etc. as part of the reboot sequence, as described before).
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1828508 b/results/classifier/108/other/1828508
new file mode 100644
index 00000000..40b35f5a
--- /dev/null
+++ b/results/classifier/108/other/1828508
@@ -0,0 +1,110 @@
+semantic: 0.880
+other: 0.863
+graphic: 0.860
+debug: 0.850
+performance: 0.845
+socket: 0.836
+KVM: 0.833
+device: 0.831
+PID: 0.830
+permissions: 0.828
+vnc: 0.809
+network: 0.792
+files: 0.784
+boot: 0.768
+
+qemu-img created VMDK files lead to "Unsupported or invalid disk type 7"
+
+Using qemu-img version 3.1.50 (v3.1.0-13607-geb2db0f7ba-dirty) on a Windows 10 machine.
+
+Converting a VHD to VMDK.
+qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic -p "c:\test\AppD-VM01.vmdk"
+
+I have also tried:
+qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic,hwversion=6 -p "c:\test\AppD-VM01.vmdk"
+
+Attaching the VMDK to a VM in VMware produces the following error when powering on.
+
+Power On virtual machine:Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+Target: MyVM1
+vCenter Server: VCENTER
+Error Stack
+An error was received from the ESX host while powering on VM MyVM1.
+Failed to start the virtual machine.
+Module DevicePowerOn power on failed. 
+Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk' 
+Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+
+
+If I do not specify the adapter type, it creates an IDE VMDK which works perfectly.
+
+On Fri, May 10, 2019 at 06:06:32AM -0000, Jake Mikelson wrote:
+> Public bug reported:
+> 
+> Using qemu-img version 3.1.50 (v3.1.0-13607-geb2db0f7ba-dirty) on a
+> Windows 10 machine.
+> 
+> Converting a VHD to VMDK.
+> qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic -p "c:\test\AppD-VM01.vmdk"
+> 
+> I have also tried:
+> qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic,hwversion=6 -p "c:\test\AppD-VM01.vmdk"
+> 
+> Attaching the VMDK to a VM in VMware produces the following error when
+> powering on.
+> 
+> Power On virtual machine:Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+> Target: MyVM1
+> vCenter Server: VCENTER
+> Error Stack
+> An error was received from the ESX host while powering on VM MyVM1.
+> Failed to start the virtual machine.
+> Module DevicePowerOn power on failed. 
+> Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk' 
+> Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+> 
+> 
+> If I do not specify the adapter type, it creates an IDE VMDK which works perfectly.
+> 
+> ** Affects: qemu
+>      Importance: Undecided
+>          Status: New
+> 
+> -- 
+> You received this bug notification because you are a member of qemu-
+> devel-ml, which is subscribed to QEMU.
+> https://bugs.launchpad.net/bugs/1828508
+
+Which version of VMware are you running?
+
+Stefan
+
+
+Hi, I'm running 5.5.
+
+I've been playing around with some of the options, and if I run the below, I end up with 2 files.
+
+qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=lsilogic,subformat=monolithicFlat -p "c:\test\AppD-VM01.vmdk"
+
+The files I get are:
+AppD-VM01.vmdk (which is always 12kb)
+AppD-VM01-flat.vmdk (which is the full size of the disk, eg 30GB).
+
+If I then upload both of these files to the datastore, they somehow merge into 1 and I can attach and power on the VM. If you dont upload both files into the datastore, VMware does not recognise it.
+
+This is the only method that seems to work for me.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+