diff options
Diffstat (limited to 'results/classifier/gemma3:12b/permissions')
111 files changed, 3725 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/permissions/1013 b/results/classifier/gemma3:12b/permissions/1013 new file mode 100644 index 00000000..82cc12d8 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1013 @@ -0,0 +1,2 @@ + +[Bug] user input is not sanitized in QEMU_Elf_init and can lead to buffer overflow diff --git a/results/classifier/gemma3:12b/permissions/1018530 b/results/classifier/gemma3:12b/permissions/1018530 new file mode 100644 index 00000000..a460f1a8 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1018530 @@ -0,0 +1,53 @@ + +No write access in a 9p/virtfs shared folder + +Ubuntu version: Ubuntu 12.04 LTS +Kernel: 3.2.0-25-generic +Version of qemu-kvm: 1.0+noroms-0ubuntu13 + +I have created an shared folder for an virtual machine which is managed by libvirt. + +<filesystem type='mount' accessmode='passthrough'> +<source dir='/storage/data'/> +<target dir='data'/> +<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> +</filesystem> + +I mounted it in the virtual machine with this command: mount -t 9p -o trans=virtio,version=9p2000.L data /data +The filesystem permissions of all files an folders in the shared folder are set to 777. I expected that I have the full permissions also in the virtual machine. + +Regardless of the permissions on the filesystem I cannot write or create files and folders in the virtual machine. The original filesystem (/storage) is XFS. +In another shared folder (similar config in libvirt) which is originally NTFS I have no problems. + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: qemu-kvm 1.0+noroms-0ubuntu13 +ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18 +Uname: Linux 3.2.0-25-generic x86_64 +ApportVersion: 2.0.1-0ubuntu8 +Architecture: amd64 +Date: Wed Jun 27 20:15:20 2012 +InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Beta amd64 (20120409) +MachineType: To be filled by O.E.M. To be filled by O.E.M. +ProcEnviron: + TERM=xterm + LANG=de_DE.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.2.0-25-generic root=/dev/mapper/system-root ro +SourcePackage: qemu-kvm +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 04/18/2012 +dmi.bios.vendor: American Megatrends Inc. +dmi.bios.version: 1208 +dmi.board.asset.tag: To be filled by O.E.M. +dmi.board.name: M5A99X EVO +dmi.board.vendor: ASUSTeK COMPUTER INC. +dmi.board.version: Rev 1.xx +dmi.chassis.asset.tag: To Be Filled By O.E.M. +dmi.chassis.type: 3 +dmi.chassis.vendor: To Be Filled By O.E.M. +dmi.chassis.version: To Be Filled By O.E.M. +dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1208:bd04/18/2012:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnASUSTeKCOMPUTERINC.:rnM5A99XEVO:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: +dmi.product.name: To be filled by O.E.M. +dmi.product.version: To be filled by O.E.M. +dmi.sys.vendor: To be filled by O.E.M. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1034 b/results/classifier/gemma3:12b/permissions/1034 new file mode 100644 index 00000000..3267f535 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1034 @@ -0,0 +1,18 @@ + +Erlang/OTP 25 JIT on AArch64 fails in user mode emulation +Description of problem: +Compiling Erlang/OTP 25 fails with segfault when using user mode (but works in system mode), the Erlang devs have tracked it down in [ErlangForums](https://erlangforums.com/t/otp-25-0-rc3-release-candidate-3-is-released/1317/24) and give this explanation: + +> Thanks, I’ve found a bug in QEMU that explains this. The gist of it is: +> +> Instead of interpreting guest code, QEMU dynamically translates it to the host architecture. When the guest overwrites code for one reason or another, the translation is invalidated and redone if needed. +> +> Our JIT:ed code is mapped in two regions to work in the face of W^X restrictions: one executable but not writable, and one writable but not executable. Both of these regions point to the same physical memory and writes to the writable region are “magically” reflected in the executable one. +> +> I would’ve expected QEMU to honor the IC IVAU / ISB instructions we use to tell the processor that we’ve altered code at a particular address, but for some reason QEMU just ignores them 3 and relies entirely on trapping writes to previously translated code. +> +> In system mode QEMU emulates the MMU and sees that these two regions point at the same memory, and has no problem invalidating the executable region after writing to the writable region. +> +> In user mode it instead calls mprotect(..., PROT_READ) on all code regions it has translated, and invalidates translations in the signal handler. The problem is that we never write to the executable region – just the writable one – so the code doesn’t get invalidated. + +There doesn't seem to a open or closed QEMU bug that actually describes this problem. diff --git a/results/classifier/gemma3:12b/permissions/1066 b/results/classifier/gemma3:12b/permissions/1066 new file mode 100644 index 00000000..f62a6bf1 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1066 @@ -0,0 +1,33 @@ + +virtfs fails to access contents of non-readable directories +Description of problem: +Attempting to access a directory inside a non-readable directory via virtfs fails. +Steps to reproduce: +On host: +1. `mkdir -p test/foo/bar` +2. `echo hello world >test/foo/bar/baz.txt` +3. `chmod -r test/foo` + +The following works on host: + +``` +$ ls test +foo +$ ls test/foo +ls: cannot open directory 'test/foo': Permission denied +$ ls test/foo/bar +baz.txt +``` + +However on guest: + +``` +bash-5.1# ls /test/ +foo +bash-5.1# ls /test/foo/ +ls: cannot open directory '/test/foo/': Permission denied +bash-5.1# ls /test/foo/bar/ +ls: cannot access '/test/foo/bar/': Permission denied +``` +Additional information: +I am guessing virtfs attempts to check rights (via access?) on the directory itself when obtaining an inode to give to the guest, however not having read access doesn't mean something can't be executed, especially for directories. diff --git a/results/classifier/gemma3:12b/permissions/1113 b/results/classifier/gemma3:12b/permissions/1113 new file mode 100644 index 00000000..81c73cd2 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1113 @@ -0,0 +1,15 @@ + +TMPDIR is not usable for snapshot-blockdevs, if not root +Description of problem: +for using static disk-content we're using `snapshot`-flag for certain disks and set `TMPDIR` to a VM-specific path. + +when started as root, all is ok. + +when started as non-root, `getenv(TMPDIR)` in function `get_tmp_filename()` in file `block.c` return `NULL`, because glibc handles `TMPDIR` as `UNSECURE_ENVVAR` (glibc-src: `sysdeps/generic/unsecvars.h`) + +well, we could compile qemu by ourself, but then we might miss important updates, so maybe this can be solved in main-source? + +possible solutions: +- additionally look at another var like `QEMU_TMPDIR`, if `getenv("TMPDIR")` results in `NULL` +- add a global option to qemu like `--tmpdir=...` +- add a device-specific option like `snapshotdir=...` diff --git a/results/classifier/gemma3:12b/permissions/1136477 b/results/classifier/gemma3:12b/permissions/1136477 new file mode 100644 index 00000000..0afc107a --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1136477 @@ -0,0 +1,6 @@ + +qemu doesn't sanitize command line options carrying plaintext passwords + +A slight security problem exists with qemu's lack of sanitization of argv[], for cases where the user may have specified a plaintext password for spice/vnc authorization. (Yes, it's not great to use this facility, but it's convenient and not grotesquely unsafe, were it not for this bug.) It would be nice if those plaintext passwords were nuked from the command line, so a subsequent "ps awux" didn't show them for all to see. + +See also https://bugzilla.redhat.com/show_bug.cgi?id=916279 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1163034 b/results/classifier/gemma3:12b/permissions/1163034 new file mode 100644 index 00000000..618eaaaa --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1163034 @@ -0,0 +1,9 @@ + +linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code) + +Please look at +https://code.launchpad.net/~costamagnagianfranco/+archive/costamagnagianfranco-ppa/+packages +and +https://code.launchpad.net/~costamagnagianfranco/+archive/costamagnagianfranco-ppa/+build/4457434 + +I cannot make gnutls28 build on armhf, I suspect a builder problem \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1163474 b/results/classifier/gemma3:12b/permissions/1163474 new file mode 100644 index 00000000..20c40403 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1163474 @@ -0,0 +1,12 @@ + +qemu mount usb permission denied + +I use debian with kde and the new Qemu 14.0 . I use this Qemu start arguments: + +/usr/bin/qemu-system-x86_64 -monitor stdio -smp 2 -soundhw es1370,ac97 -k de -enable-kvm -m 4096 -localtime -cdrom /dev/sr0 -hda /home/....../.aqemu/Windows_7_x64_HDA.img -boot once=d,menu=off -net nic,vlan=0 -net user,vlan=0 -usb -usbdevice tablet -device usb-host,hostbus=1,hostaddr=2 -device usb-host,hostbus=2,hostaddr=2 -name "Windows 7 x64" + +Then I get this error: /dev/bus/usb/000/001: Permission denied + +Some says I must change the permissions /dev/bus/usb to 777 but I think that can't be the solution and when I restart the changes are lost. I think there is also a problem with the automount in KDE. + +The user user who starts Qemu has also full access to usb device (member of the group plugdev) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1192780 b/results/classifier/gemma3:12b/permissions/1192780 new file mode 100644 index 00000000..1cc576a7 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1192780 @@ -0,0 +1,71 @@ + +qemu-kvm with snapshot option always fails with Permission denied Could not open disk image + +I'm trying to use the option: -snapshot write to temporary files instead of disk image files + +How to reproduce? See following log: +2013-06-20 02:13:18.532+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -S -M pc-1.0 -no-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name instance-0000002b -uuid 2d600758-ae56-48b8-bd4d-999744a038e4 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0000002b.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -kernel /opt/stack/data/nova/instances/instance-0000002b/kernel -initrd /opt/stack/data/nova/instances/instance-0000002b/ramdisk -append root=/dev/vda console=ttyS0 -drive file=/opt/stack/data/nova/instances/instance-0000002b/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=19,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=fa:16:3e:03:ab:18,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/opt/stack/data/nova/instances/instance-0000002b/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:26868 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -snapshot +Domain id=1 is tainted: custom-argv +char device redirected to /dev/pts/18 +qemu-system-x86_64: -drive file=/opt/stack/data/nova/instances/instance-0000002b/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /opt/stack/data/nova/instances/instance-0000002b/disk: Permission denied +2013-06-20 02:13:18.683+0000: shutting down + +Version: QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + +Related info: +The disk is a qcow2 image with a backing file. Both the backing file and the disk are cmodded with 777. + +This is a log from dmesg related to apparmor: +[ 236.531287] type=1400 audit(1371694399.156:17): apparmor="STATUS" operation="profile_remove" name="libvirt-2d600758-ae56-48b8-bd4d-999744a038e4" pid=4201 comm="apparmor_parser" + + +libvirt.xml that I'm using: +<domain type="qemu" xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + <uuid>2d600758-ae56-48b8-bd4d-999744a038e4</uuid> + <name>instance-0000002b</name> + <memory>524288</memory> + <vcpu>1</vcpu> + <os> + <type>hvm</type> + <kernel>/opt/stack/data/nova/instances/instance-0000002b/kernel</kernel> + <initrd>/opt/stack/data/nova/instances/instance-0000002b/ramdisk</initrd> + <cmdline>root=/dev/vda console=ttyS0</cmdline> + </os> + <features> + <acpi/> + <apic/> + </features> + <clock offset="utc"/> + <devices> + <disk type="file" device="disk"> + <driver name="qemu" type="qcow2" cache="none"/> + <source file="/opt/stack/data/nova/instances/instance-0000002b/disk"/> + <target bus="virtio" dev="vda"/> + </disk> + <disk type="block" device="cdrom"> + <driver name="qemu" type="raw"/> + <target tray="open" dev="hdc"/> + <readonly/> + </disk> + <interface type="bridge"> + <mac address="fa:16:3e:03:ab:18"/> + <source bridge="br100"/> + <filterref filter="nova-instance-instance-0000002b-fa163e03ab18"> + <parameter name="IP" value="10.0.0.3"/> + <parameter name="DHCPSERVER" value="10.0.0.1"/> + <parameter name="PROJNET" value="10.0.0.0"/> + <parameter name="PROJMASK" value="255.255.255.0"/> + </filterref> + </interface> + <serial type="file"> + <source path="/opt/stack/data/nova/instances/instance-0000002b/console.log"/> + </serial> + <serial type="pty"/> + <input type="tablet" bus="usb"/> + <graphics type="vnc" autoport="no" port="32768" keymap="en-us" listen="127.0.0.1"/> + </devices> +<qemu:commandline> + <qemu:arg value='-snapshot'/> +</qemu:commandline> +</domain> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/122 b/results/classifier/gemma3:12b/permissions/122 new file mode 100644 index 00000000..b7d924ad --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/122 @@ -0,0 +1,2 @@ + +linux-user does not check PROT_EXEC diff --git a/results/classifier/gemma3:12b/permissions/1238 b/results/classifier/gemma3:12b/permissions/1238 new file mode 100644 index 00000000..62ff7a71 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1238 @@ -0,0 +1,120 @@ + +qemu-mipsn32el and qemu-mipsn32 problems with coreutils-9*, fadvise64 or fallocate related? +Description of problem: +- Recently about 15 of the ca. 250 packages in our system set fail during `make install`. A typical error is +> `/usr/bin/install: error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff': Invalid argument` +- Given the timing and the involved binaries (most of the times `install`, but also `cp`), I suspect this was triggered by coreutils-9 +- The problem seems to only occur on ext4 (our release engineering box), but not on btrfs (my home development box) +- The problem seems to be limited to n32 (both big and little endian) + +Here's a run with strace functionality enabled: + +``` +dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # /usr/bin/qemu-mipsn32el -strace /usr/bin/install troff '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin' +3216 brk(NULL) = 0x40032000 +3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f7ba000 +3216 uname(0x3fffebb0) = 0 +3216 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe280) = 0 +3216 mmap(NULL,11294,PROT_READ,MAP_PRIVATE,3,0) = 0x3f7b7000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libacl.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4c4,512) = 512 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe220) = 0 +3216 mmap(NULL,197008,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f786000 +3216 mmap(0x3f790000,131472,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f790000 +3216 munmap(0x3f786000,40960) = 0 +3216 munmap(0x3f7b1000,20880) = 0 +3216 mprotect(0x3f797000,98304,PROT_NONE) = 0 +3216 mmap(0x3f7af000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f7af000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libattr.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4b4,512) = 512 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe210) = 0 +3216 mmap(NULL,196864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f75f000 +3216 mmap(0x3f760000,131328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f760000 +3216 munmap(0x3f75f000,4096) = 0 +3216 munmap(0x3f781000,57600) = 0 +3216 mprotect(0x3f764000,110592,PROT_NONE) = 0 +3216 mmap(0x3f77f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f77f000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4a4,512) = 512 +3216 pread64(3,1073734640,32,34504,1065377824,0) = 32 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe200) = 0 +3216 mmap(NULL,2056864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 +3216 mmap(0x3f570000,1991328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f570000 +3216 munmap(0x3f569000,28672) = 0 +3216 munmap(0x3f757000,33440) = 0 +3216 mprotect(0x3f73c000,61440,PROT_NONE) = 0 +3216 mmap(0x3f74b000,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1cb000) = 0x3f74b000 +3216 mmap(0x3f752000,17056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x3f752000 +3216 close(3) = 0 +3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 +3216 set_thread_area(0x3f570580) = 0 +3216 set_tid_address(1062637704,1065348616,1065377824,0,-1,0) = 3216 +3216 set_robust_list(1062637712,12,1065377824,0,-1,0) = -1 errno=89 (Function not implemented) +3216 Unknown syscall 6331 +3216 mprotect(0x3f74b000,16384,PROT_READ) = 0 +3216 mprotect(0x3f77f000,4096,PROT_READ) = 0 +3216 mprotect(0x3f7af000,4096,PROT_READ) = 0 +3216 mprotect(0x4002e000,4096,PROT_READ) = 0 +3216 mprotect(0x3f7fc000,8192,PROT_READ) = 0 +3216 getrlimit(3,1073737152,1064664656,1062638996,1064337736,1064664656) = 0 +3216 munmap(0x3f7b7000,11294) = 0 +3216 getrandom(1064649956,4,1,1064337736,2130640639,1077952576) = 4 +3216 brk(NULL) = 0x40032000 +3216 brk(0x40053000) = 0x40053000 +3216 brk(0x40054000) = 0x40054000 +3216 openat(AT_FDCWD,"/usr/lib/locale/locale-archive",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffed58) = 0 +3216 mmap(NULL,2097152,PROT_READ,MAP_PRIVATE,3,0) = 0x3f369000 +3216 close(3) = 0 +3216 geteuid() = 0 +3216 umask(0) = 18 +3216 openat(AT_FDCWD,"/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin",O_RDONLY|O_DIRECTORY|O_LARGEFILE|O_PATH) = 3 +3216 statx(AT_FDCWD,"troff",AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 statx(3,"troff",AT_NO_AUTOMOUNT|AT_SYMLINK_NOFOLLOW,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 unlinkat(3,"troff",0) = 0 +3216 openat(AT_FDCWD,"troff",O_RDONLY|O_LARGEFILE) = 4 +3216 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 openat(3,"troff",O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE,0600) = 5 +3216 ioctl(5,FICLONE,4) = -1 errno=122 (Operation not supported) +3216 statx(5,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 lseek(4,0,SEEK_DATA) = 0 +3216 fadvise64(4,0,0,2,1664557525,0) = -1 errno=22 (Invalid argument) +3216 lseek(4,0,SEEK_HOLE) = 716800 +3216 lseek(4,0,SEEK_SET) = 0 +3216 mmap(NULL,139264,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f347000 +3216 read(4,0x3f348000,131072) = 131072 +3216 write(5,0x3f348000,122880) = 122880 +3216 read(4,0x3f348000,131072) = 131072 +3216 lseek(5,12288,SEEK_CUR) = 135168 +3216 fallocate(5,FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE,122880,4290510848) = -1 errno=22 (Invalid argument) +3216 openat(AT_FDCWD,"/usr/share/locale/locale.alias",O_RDONLY|O_CLOEXEC) = 6 +3216 statx(6,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe2c8) = 0 +3216 read(6,0x400333a0,4096) = 2998 +3216 read(6,0x400333a0,4096) = 0 +3216 close(6) = 0 +3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 write(2,0x3fffc888,18)/usr/bin/install: = 18 +3216 write(2,0x3fffc8b8,79)error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff' = 79 +3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 write(2,0x3fffc428,18): Invalid argument = 18 +3216 write(2,0x3fffc858,1) + = 1 +3216 close(5) = 0 +3216 close(4) = 0 +3216 munmap(0x3f347000,139264) = 0 +3216 lseek(0,0,SEEK_CUR) = -1 errno=29 (Illegal seek) +3216 close(0) = 0 +3216 close(1) = 0 +3216 close(2)dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # +``` + +More information and debugging on request. Any advice is appreciated. diff --git a/results/classifier/gemma3:12b/permissions/1253 b/results/classifier/gemma3:12b/permissions/1253 new file mode 100644 index 00000000..2dde05b4 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1253 @@ -0,0 +1,2 @@ + +pull mirroring diff --git a/results/classifier/gemma3:12b/permissions/1285363 b/results/classifier/gemma3:12b/permissions/1285363 new file mode 100644 index 00000000..a3eaad23 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1285363 @@ -0,0 +1,46 @@ + +qemu-aarch64-static segfaults + +I've found a couple conditions that causes qemu-user-static to core dump fairly reliably - same with upstream git - while a binary built from suse's aarch64-1.6 branch seems to consistently work fine. + +Testing suggests they are resolved by the sigprocmask wrapper patches included in suse's tree. + + 1) dh_fixperms is a script that commonly runs at the end of a package build. + Its basically doing a `find | xargs chmod`. + 2) debootstrap --second-stage + This is used to configure an arm64 chroot that was built using + debootstrap on a non-native host. It is basically invoking a bunch of + shell scripts (postinst, etc). When it blows up, the stack consistently + looks like this: + +Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e +/debootstrap/debootstrap --second-stage'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +51 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); +(gdb) bt +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +#1 stq_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:280 +#2 stq_le_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:315 +#3 target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678, +sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167 +#4 target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0 +<sigact_table+512>, info=info@entry=0x0, set=set@entry=0x7fff62ae3530, +env=env@entry=0x62d9c678) + at /mnt/qemu.upstream/linux-user/signal.c:1286 +#5 0x0000000060059f46 in setup_frame (env=0x62d9c678, +set=0x7fff62ae3530, ka=0x604ec1e0 <sigact_table+512>, sig=17) at +/mnt/qemu.upstream/linux-user/signal.c:1322 +#6 process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/signal.c:5747 +#7 0x0000000060056e60 in cpu_loop (env=env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/main.c:1082 +#8 0x0000000060005079 in main (argc=<optimized out>, argv=<optimized +out>, envp=<optimized out>) at +/mnt/qemu.upstream/linux-user/main.c:4374 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1299 b/results/classifier/gemma3:12b/permissions/1299 new file mode 100644 index 00000000..56514654 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1299 @@ -0,0 +1,25 @@ + +User networking with an SMB Share while not running as root +Description of problem: +When attempting to write a file to the qemu share, Samba always responds with NT_STATUS_ACCESS_DENIED. + +This only happens on the MacOS version of Samba, on Linux it appears to work without issues for now. +Steps to reproduce: +1. Start a VM with a SMB share attached to it +2. Create a test file to upload `touch test-file.txt` +3. Upload the test file `smbclient //10.0.2.4/qemu -c 'put test-file.txt' +Additional information: +QEMU has been using Samba for it's SMB shares for quite some time now. +But in the 4.17.x release a bug has appeared in the MacOS Build of Samba. + +I've filed a bug with Samba, and suggested a fix for it. +https://bugzilla.samba.org/show_bug.cgi?id=15215 + +The origin of the bug lies in the fact that when running SMBD as a non-root user, a function sets `errno` unexpectedly. +But after discussing this with Samba, they concluded that running smbd as an un-privileged user is not a supported use case. + +Whilst this is not a QEMU bug per se, it is caused by the fact that QEMU is running smbd in an unsupported manner. + +As a side note, on Linux this bug does not appear to exist as of yet. +The Linux version of `unbecome_root` doesn't seem to set `errno`. (tested on a recent ArchLinux install). +But I think this depends on the LibC implementation of setuid/seteuid/setreuid/etc. so I can't say it won't happen in the future, or with a different LibC implementation. diff --git a/results/classifier/gemma3:12b/permissions/1349 b/results/classifier/gemma3:12b/permissions/1349 new file mode 100644 index 00000000..2ac06a95 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1349 @@ -0,0 +1,8 @@ + +Windows Installer Error +Description of problem: +Windows Installer Barfs +Steps to reproduce: +1. Either run exe installer or do ```scoop update -g "qemu" ``` +Additional information: + diff --git a/results/classifier/gemma3:12b/permissions/1359 b/results/classifier/gemma3:12b/permissions/1359 new file mode 100644 index 00000000..d9e9c80f --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1359 @@ -0,0 +1,2 @@ + +open virtual format diff --git a/results/classifier/gemma3:12b/permissions/1364 b/results/classifier/gemma3:12b/permissions/1364 new file mode 100644 index 00000000..994b37ba --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1364 @@ -0,0 +1,16 @@ + +Support vmnet networking without elevated permissions +Additional information: +Here is a command, that doesn't work when running as normal user: +```bash +$ qemu-system-aarch64 \ + -device virtio-net-pci,netdev=net0 \ + -netdev vmnet-bridged,id=net0,ifname=en0 \ + -machine virt +``` +It fails with: +``` +qemu-system-aarch64: -netdev vmnet-bridged,id=net0,ifname=en0: cannot create vmnet interface: general failure (possibly not enough privileges) +``` + +When running the same command using elevated permissions (i.e. via `sudo`), it works without any issue. diff --git a/results/classifier/gemma3:12b/permissions/1386 b/results/classifier/gemma3:12b/permissions/1386 new file mode 100644 index 00000000..4552fb64 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1386 @@ -0,0 +1,629 @@ + +Qemu 7.2.0 - Failed compilation under Windows with MSYS (MINGW64) +Description of problem: +I follow the faq here + +https://wiki.qemu.org/Hosts/W32#Debian_based_cross_builds + +to compile qemu source under Windows with MSYS2 (MINGW64). +Steps to reproduce: +Follow the FAQ guide and I get + +``` +xxxx@DESKTOP-NBACH6G MINGW64 ~/qemu +$ ./configure --enable-sdl --enable-gtk +Using './build' as the directory for build output +ln: failed to create symbolic link 'aarch64-softmmu/qemu-system-aarch64.exe': No such file or directory +ln: failed to create symbolic link 'alpha-softmmu/qemu-system-alpha.exe': No such file or directory +ln: failed to create symbolic link 'arm-softmmu/qemu-system-arm.exe': No such file or directory +ln: failed to create symbolic link 'avr-softmmu/qemu-system-avr.exe': No such file or directory +ln: failed to create symbolic link 'cris-softmmu/qemu-system-cris.exe': No such file or directory +ln: failed to create symbolic link 'hppa-softmmu/qemu-system-hppa.exe': No such file or directory +ln: failed to create symbolic link 'i386-softmmu/qemu-system-i386.exe': No such file or directory +ln: failed to create symbolic link 'loongarch64-softmmu/qemu-system-loongarch64.exe': No such file or directory +ln: failed to create symbolic link 'm68k-softmmu/qemu-system-m68k.exe': No such file or directory +ln: failed to create symbolic link 'microblaze-softmmu/qemu-system-microblaze.exe': No such file or directory +ln: failed to create symbolic link 'microblazeel-softmmu/qemu-system-microblazeel.exe': No such file or directory +ln: failed to create symbolic link 'mips-softmmu/qemu-system-mips.exe': No such file or directory +ln: failed to create symbolic link 'mips64-softmmu/qemu-system-mips64.exe': No such file or directory +ln: failed to create symbolic link 'mips64el-softmmu/qemu-system-mips64el.exe': No such file or directory +ln: failed to create symbolic link 'mipsel-softmmu/qemu-system-mipsel.exe': No such file or directory +ln: failed to create symbolic link 'nios2-softmmu/qemu-system-nios2.exe': No such file or directory +ln: failed to create symbolic link 'or1k-softmmu/qemu-system-or1k.exe': No such file or directory +ln: failed to create symbolic link 'ppc-softmmu/qemu-system-ppc.exe': No such file or directory +ln: failed to create symbolic link 'ppc64-softmmu/qemu-system-ppc64.exe': No such file or directory +ln: failed to create symbolic link 'riscv32-softmmu/qemu-system-riscv32.exe': No such file or directory +ln: failed to create symbolic link 'riscv64-softmmu/qemu-system-riscv64.exe': No such file or directory +ln: failed to create symbolic link 'rx-softmmu/qemu-system-rx.exe': No such file or directory +ln: failed to create symbolic link 's390x-softmmu/qemu-system-s390x.exe': No such file or directory +ln: failed to create symbolic link 'sh4-softmmu/qemu-system-sh4.exe': No such file or directory +ln: failed to create symbolic link 'sh4eb-softmmu/qemu-system-sh4eb.exe': No such file or directory +ln: failed to create symbolic link 'sparc-softmmu/qemu-system-sparc.exe': No such file or directory +ln: failed to create symbolic link 'sparc64-softmmu/qemu-system-sparc64.exe': No such file or directory +ln: failed to create symbolic link 'tricore-softmmu/qemu-system-tricore.exe': No such file or directory +ln: failed to create symbolic link 'x86_64-softmmu/qemu-system-x86_64.exe': No such file or directory +ln: failed to create symbolic link 'xtensa-softmmu/qemu-system-xtensa.exe': No such file or directory +ln: failed to create symbolic link 'xtensaeb-softmmu/qemu-system-xtensaeb.exe': No such file or directory +The Meson build system +Version: 0.64.1 +Source dir: C:/msys64/home/Roberto/qemu +Build dir: C:/msys64/home/Roberto/qemu/build +Build type: native build +Project name: qemu +Project version: 7.2.50 +C compiler for the host machine: cc -m64 -mcx16 (gcc 12.2.0 "cc (Rev6, Built by MSYS2 project) 12.2.0") +C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.39 +Host machine cpu family: x86_64 +Host machine cpu: x86_64 +Program scripts/symlink-install-tree.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/symlink-install-tree.py) +Program sh found: YES (C:\msys64\usr\bin/sh.EXE) +Program python3 found: YES (C:/msys64/mingw64/bin/python.exe) +Program bzip2 found: YES (C:\msys64\mingw64\bin/bzip2.EXE) +Program iasl found: NO +Compiler for C supports link arguments -Wl,-z,relro: NO +Compiler for C supports link arguments -Wl,-z,now: NO +Compiler for C supports link arguments -Wl,--no-seh: YES +Compiler for C supports link arguments -Wl,--nxcompat: YES +C++ compiler for the host machine: c++ -m64 -mcx16 (gcc 12.2.0 "c++ (Rev6, Built by MSYS2 project) 12.2.0") +C++ linker for the host machine: c++ -m64 -mcx16 ld.bfd 2.39 +Compiler for C++ supports link arguments -Wl,--warn-common: YES +Program cgcc found: NO +Library m found: YES +Run-time dependency threads found: YES +Library util found: NO +Program midl found: NO +Program widl found: YES +Library pathcch found: YES +Library ws2_32 found: YES +Library winmm found: YES +Windows resource compiler: GNU windres (GNU Binutils) 2.39 +Has header "WinHvPlatform.h" : YES +Has header "WinHvEmulation.h" : YES +Run-time dependency appleframeworks found: NO (tried framework) +Found pkg-config: C:\msys64\mingw64\bin/pkg-config.EXE (1.8.0) +Run-time dependency gio-2.0 found: YES 2.74.3 +Program C:/msys64/mingw64/bin/gdbus-codegen found: YES (C:/msys64/mingw64/bin/gdbus-codegen.exe) +Run-time dependency gio-unix-2.0 found: NO (tried pkgconfig) +Run-time dependency pixman-1 found: YES 0.42.2 +Run-time dependency zlib found: YES 1.2.13 +Has header "libaio.h" : NO +Run-time dependency liburing found: NO (tried pkgconfig) +Run-time dependency libnfs found: YES 5.0.2 +Has header "attr/xattr.h" : NO +Run-time dependency appleframeworks found: NO (tried framework) +Run-time dependency appleframeworks found: NO (tried framework) +Run-time dependency libseccomp found: NO (tried pkgconfig) +Has header "cap-ng.h" : NO +Run-time dependency xkbcommon found: NO (tried pkgconfig) +Run-time dependency slirp found: YES 4.7.0 +Has header "libvdeplug.h" : NO +Run-time dependency jack found: NO (tried pkgconfig) +Run-time dependency sndio found: NO (tried pkgconfig) +Run-time dependency spice-protocol found: YES 0.14.4 +Run-time dependency spice-server found: YES 0.15.1 +Library rt found: NO +Run-time dependency libiscsi found: NO (tried pkgconfig) +Run-time dependency libzstd found: YES 1.5.2 +Run-time dependency virglrenderer found: NO (tried pkgconfig) +Run-time dependency blkio found: NO (tried pkgconfig) +Run-time dependency libcurl found: YES 7.86.0 +Run-time dependency ncurses found: NO (tried pkgconfig) +Run-time dependency ncursesw found: YES 6.3.20211021 +Has header "brlapi.h" : NO +Run-time dependency sdl2 found: YES 2.26.1 +Run-time dependency sdl2_image found: YES 2.6.2 +Library rados found: NO +Has header "rbd/librbd.h" : NO +Run-time dependency glusterfs-api found: NO (tried pkgconfig) +Run-time dependency libssh found: YES 0.10.4 +Has header "bzlib.h" : YES +Library bz2 found: YES +Has header "lzfse.h" : NO +Has header "sys/soundcard.h" : NO +Has header "dsound.h" : YES +Run-time dependency epoxy found: YES 1.5.10 +Has header "epoxy/egl.h" with dependency epoxy: NO +Run-time dependency gnutls found: YES 3.7.8 +Run-time dependency gmp found: YES 6.2.1 +Run-time dependency gtk+-3.0 found: YES 3.24.35 +Run-time dependency gtk+-x11-3.0 found: NO (tried pkgconfig) +Run-time dependency vte-2.91 found: NO (tried pkgconfig) +Run-time dependency libpng found: YES 1.6.39 +Run-time dependency libjpeg found: YES 2.1.4 +Has header "sasl/sasl.h" : YES +Library sasl2 found: YES +Has header "security/pam_appl.h" : NO +Has header "snappy-c.h" : YES +Library snappy found: YES +Has header "lzo/lzo1x.h" : YES +Library lzo2 found: YES +Has header "numa.h" : NO +Library ibumad found: NO +Has header "rdma/rdma_cma.h" : NO +Library ibverbs found: NO +Run-time dependency xencontrol found: NO (tried pkgconfig) +Library xenstore found: NO +Library xenctrl found: NO +Library xendevicemodel found: NO +Library xenforeignmemory found: NO +Library xengnttab found: NO +Library xenevtchn found: NO +Library xentoolcore found: NO +Run-time dependency libcacard found: NO (tried pkgconfig) +Run-time dependency u2f-emu found: NO (tried pkgconfig) +Run-time dependency canokey-qemu found: NO (tried pkgconfig) +Run-time dependency libusbredirparser-0.5 found: YES 0.8.0 +Run-time dependency libusb-1.0 found: YES 1.0.26 +Run-time dependency libpmem found: NO (tried pkgconfig) +Run-time dependency libdaxctl found: NO (tried pkgconfig) +Run-time dependency libtasn1 found: YES 4.19.0 +Run-time dependency libkeyutils found: NO (tried pkgconfig) +Checking for function "gettid" : NO +Run-time dependency libselinux found: NO (tried pkgconfig) +Run-time dependency fuse3 found: NO (tried pkgconfig) +Run-time dependency libbpf found: NO (tried pkgconfig) +Checking for function "pthread_fchdir_np" : NO +Has header "sys/epoll.h" : NO +Has header "linux/magic.h" : NO +Has header "valgrind/valgrind.h" : NO +Has header "linux/btrfs.h" : NO +Has header "libdrm/drm.h" : NO +Has header "pty.h" : NO +Has header "sys/disk.h" : NO +Has header "sys/ioccom.h" : NO +Has header "sys/kcov.h" : NO +Has header "afunix.h" : YES +Checking for function "close_range" : NO +Checking for function "accept4" : NO +Checking for function "clock_adjtime" : NO +Checking for function "dup3" : NO +Checking for function "fallocate" : NO +Checking for function "posix_fallocate" : NO +Checking for function "posix_memalign" : NO +Checking for function "_aligned_malloc" : YES +Checking for function "valloc" : NO +Checking for function "memalign" : NO +Checking for function "ppoll" : NO +Checking for function "preadv" : NO +Checking for function "pthread_fchdir_np" : NO (cached) +Checking for function "sendfile" : NO +Checking for function "setns" : NO +Checking for function "syncfs" : NO +Checking for function "sync_file_range" : NO +Checking for function "timerfd_create" : NO +Checking for function "copy_file_range" : NO +Checking for function "getifaddrs" : NO +Checking for function "openpty" with dependency -lutil: NO +Checking for function "strchrnul" : NO +Checking for function "system" : YES +Header "byteswap.h" has symbol "bswap_32" : NO +Header "sys/epoll.h" has symbol "epoll_create1" : NO +Header "linux/falloc.h" has symbol "FALLOC_FL_PUNCH_HOLE" : NO +Header "linux/falloc.h" has symbol "FALLOC_FL_ZERO_RANGE" : NO +Has header "linux/fiemap.h" : NO +Checking for function "getrandom" : NO +Header "sys/inotify.h" has symbol "inotify_init" : NO +Header "sys/inotify.h" has symbol "inotify_init1" : NO +Header "machine/bswap.h" has symbol "bswap32" : NO +Header "sys/prctl.h" has symbol "PR_SET_TIMERSLACK" : NO +Header "linux/rtnetlink.h" has symbol "IFLA_PROTO_DOWN" : NO +Header "sys/sysmacros.h" has symbol "makedev" : NO +Header "getopt.h" has symbol "optreset" : NO +Header "netinet/in.h" has symbol "IPPROTO_MPTCP" : NO +Header "sys/mount.h" has symbol "FSCONFIG_SET_FLAG" : NO +Checking whether type "struct sigevent" has member "sigev_notify_thread_id" : NO +Checking whether type "struct stat" has member "st_atim" : NO +Checking for type "struct iovec" : NO +Checking for type "struct utmpx" : NO +Checking for type "struct mmsghdr" : NO +Header "linux/vm_sockets.h" has symbol "AF_VSOCK" : NO +Has header "vscoordint.h" : NO +Checking if "_lock_file and _unlock_file" : links: YES +Program scripts/minikconf.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/minikconf.py) +Configuring aarch64-softmmu-config-target.h using configuration +Configuring aarch64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/aarch64-softmmu-config-devices.mak.d +Configuring aarch64-softmmu-config-devices.h using configuration +Configuring alpha-softmmu-config-target.h using configuration +Configuring alpha-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/alpha-softmmu-config-devices.mak.d +Configuring alpha-softmmu-config-devices.h using configuration +Configuring arm-softmmu-config-target.h using configuration +Configuring arm-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/arm-softmmu-config-devices.mak.d +Configuring arm-softmmu-config-devices.h using configuration +Configuring avr-softmmu-config-target.h using configuration +Configuring avr-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/avr-softmmu-config-devices.mak.d +Configuring avr-softmmu-config-devices.h using configuration +Configuring cris-softmmu-config-target.h using configuration +Configuring cris-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/cris-softmmu-config-devices.mak.d +Configuring cris-softmmu-config-devices.h using configuration +Configuring hppa-softmmu-config-target.h using configuration +Configuring hppa-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/hppa-softmmu-config-devices.mak.d +Configuring hppa-softmmu-config-devices.h using configuration +Configuring i386-softmmu-config-target.h using configuration +Configuring i386-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/i386-softmmu-config-devices.mak.d +Configuring i386-softmmu-config-devices.h using configuration +Configuring loongarch64-softmmu-config-target.h using configuration +Configuring loongarch64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/loongarch64-softmmu-config-devices.mak.d +Configuring loongarch64-softmmu-config-devices.h using configuration +Configuring m68k-softmmu-config-target.h using configuration +Configuring m68k-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/m68k-softmmu-config-devices.mak.d +Configuring m68k-softmmu-config-devices.h using configuration +Configuring microblaze-softmmu-config-target.h using configuration +Configuring microblaze-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/microblaze-softmmu-config-devices.mak.d +Configuring microblaze-softmmu-config-devices.h using configuration +Configuring microblazeel-softmmu-config-target.h using configuration +Configuring microblazeel-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/microblazeel-softmmu-config-devices.mak.d +Configuring microblazeel-softmmu-config-devices.h using configuration +Configuring mips-softmmu-config-target.h using configuration +Configuring mips-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mips-softmmu-config-devices.mak.d +Configuring mips-softmmu-config-devices.h using configuration +Configuring mips64-softmmu-config-target.h using configuration +Configuring mips64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mips64-softmmu-config-devices.mak.d +Configuring mips64-softmmu-config-devices.h using configuration +Configuring mips64el-softmmu-config-target.h using configuration +Configuring mips64el-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mips64el-softmmu-config-devices.mak.d +Configuring mips64el-softmmu-config-devices.h using configuration +Configuring mipsel-softmmu-config-target.h using configuration +Configuring mipsel-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mipsel-softmmu-config-devices.mak.d +Configuring mipsel-softmmu-config-devices.h using configuration +Configuring nios2-softmmu-config-target.h using configuration +Configuring nios2-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/nios2-softmmu-config-devices.mak.d +Configuring nios2-softmmu-config-devices.h using configuration +Configuring or1k-softmmu-config-target.h using configuration +Configuring or1k-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/or1k-softmmu-config-devices.mak.d +Configuring or1k-softmmu-config-devices.h using configuration +Configuring ppc-softmmu-config-target.h using configuration +Configuring ppc-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/ppc-softmmu-config-devices.mak.d +Configuring ppc-softmmu-config-devices.h using configuration +Configuring ppc64-softmmu-config-target.h using configuration +Configuring ppc64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/ppc64-softmmu-config-devices.mak.d +Configuring ppc64-softmmu-config-devices.h using configuration +Configuring riscv32-softmmu-config-target.h using configuration +Configuring riscv32-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/riscv32-softmmu-config-devices.mak.d +Configuring riscv32-softmmu-config-devices.h using configuration +Configuring riscv64-softmmu-config-target.h using configuration +Configuring riscv64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/riscv64-softmmu-config-devices.mak.d +Configuring riscv64-softmmu-config-devices.h using configuration +Configuring rx-softmmu-config-target.h using configuration +Configuring rx-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/rx-softmmu-config-devices.mak.d +Configuring rx-softmmu-config-devices.h using configuration +Configuring s390x-softmmu-config-target.h using configuration +Configuring s390x-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/s390x-softmmu-config-devices.mak.d +Configuring s390x-softmmu-config-devices.h using configuration +Configuring sh4-softmmu-config-target.h using configuration +Configuring sh4-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sh4-softmmu-config-devices.mak.d +Configuring sh4-softmmu-config-devices.h using configuration +Configuring sh4eb-softmmu-config-target.h using configuration +Configuring sh4eb-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sh4eb-softmmu-config-devices.mak.d +Configuring sh4eb-softmmu-config-devices.h using configuration +Configuring sparc-softmmu-config-target.h using configuration +Configuring sparc-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sparc-softmmu-config-devices.mak.d +Configuring sparc-softmmu-config-devices.h using configuration +Configuring sparc64-softmmu-config-target.h using configuration +Configuring sparc64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sparc64-softmmu-config-devices.mak.d +Configuring sparc64-softmmu-config-devices.h using configuration +Configuring tricore-softmmu-config-target.h using configuration +Configuring tricore-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/tricore-softmmu-config-devices.mak.d +Configuring tricore-softmmu-config-devices.h using configuration +Configuring x86_64-softmmu-config-target.h using configuration +Configuring x86_64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/x86_64-softmmu-config-devices.mak.d +Configuring x86_64-softmmu-config-devices.h using configuration +Configuring xtensa-softmmu-config-target.h using configuration +Configuring xtensa-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/xtensa-softmmu-config-devices.mak.d +Configuring xtensa-softmmu-config-devices.h using configuration +Configuring xtensaeb-softmmu-config-target.h using configuration +Configuring xtensaeb-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/xtensaeb-softmmu-config-devices.mak.d +Configuring xtensaeb-softmmu-config-devices.h using configuration +Program scripts/make-config-poison.sh found: YES (sh C:/msys64/home/Roberto/qemu/scripts/make-config-poison.sh) +Run-time dependency capstone found: YES 4.0.2 +Library fdt found: NO +Configuring config-host.h using configuration +Program scripts/hxtool found: YES (sh C:/msys64/home/Roberto/qemu/scripts/hxtool) +Program scripts/shaderinclude.pl found: YES (perl C:/msys64/home/Roberto/qemu/scripts/shaderinclude.pl) +Program scripts/qapi-gen.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/qapi-gen.py) +Program scripts/qemu-version.sh found: YES (sh C:/msys64/home/Roberto/qemu/scripts/qemu-version.sh) +Program scripts/decodetree.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/decodetree.py) +Program ../scripts/modules/module_block.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/block/../scripts/modules/module_block.py) +Program ../scripts/block-coroutine-wrapper.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/block/../scripts/block-coroutine-wrapper. +py) +Program scripts/modinfo-collect.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/modinfo-collect.py) +Program scripts/modinfo-generate.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/modinfo-generate.py) +Program nm found: YES +Program scripts/undefsym.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/undefsym.py) +Program scripts/feature_to_c.sh found: YES (sh C:/msys64/home/Roberto/qemu/scripts/feature_to_c.sh) +Compiler for C supports link arguments -fstack-protector-all: YES +Compiler for C supports link arguments -fstack-protector-strong: YES +Compiler for C supports link arguments -Wl,--add-stdcall-alias: YES +Compiler for C supports link arguments -Wl,--enable-stdcall-fixup: YES +Library ole32 found: YES +Library oleaut32 found: YES +Library shlwapi found: YES +Library uuid found: YES +Library intl found: YES +Program wixl found: NO +Configuring 50-edk2-i386-secure.json using configuration +Configuring 50-edk2-x86_64-secure.json using configuration +Configuring 60-edk2-aarch64.json using configuration +Configuring 60-edk2-arm.json using configuration +Configuring 60-edk2-i386.json using configuration +Configuring 60-edk2-x86_64.json using configuration +Program qemu-keymap found: NO +Program sphinx-build found: YES (C:\msys64\mingw64\bin/sphinx-build.EXE) +../docs/meson.build:74: WARNING: Project targets '>=0.61.3' but uses feature deprecated since '0.60.0': install_subdir with empty directory. It worked by accide +nt and is buggy. Use install_emptydir instead. +Program diff found: YES (C:\msys64\usr\bin/diff.EXE) +Program dbus-daemon found: NO +Did not find CMake 'cmake' +Found CMake: NO +Run-time dependency gvnc-1.0 found: NO (tried pkgconfig and cmake) +Program initrd-stress.sh found: YES (sh C:/msys64/home/Roberto/qemu/tests/migration/initrd-stress.sh) +Program xgettext found: YES (C:\msys64\mingw64\bin/xgettext.EXE) +Program msgfmt found: YES (C:\msys64\mingw64\bin/msgfmt.EXE) +Program msginit found: YES (C:\msys64\mingw64\bin/msginit.EXE) +Program msgmerge found: YES (C:\msys64\mingw64\bin/msgmerge.EXE) +Program xgettext found: YES (C:\msys64\mingw64\bin/xgettext.EXE) +Program scripts/nsis.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/nsis.py) +Build targets in project: 639 +WARNING: Deprecated features used: + * 0.60.0: {'install_subdir with empty directory'} + +qemu 7.2.50 + + Directories + Install prefix : C:/msys64/qemu + BIOS directory : share/ + firmware path : share/qemu-firmware + binary directory : C:/msys64/qemu/. + library directory : C:/msys64/qemu/lib + module directory : lib/ + libexec directory : C:/msys64/qemu/libexec + include directory : C:/msys64/qemu/include + config directory : C:/msys64/qemu/etc + local state directory : queried at runtime + Doc directory : C:/msys64/qemu/share/doc + Build directory : C:/msys64/home/xxx/qemu/build + Source path : C:/msys64/home/xxx/qemu + GIT submodules : ui/keycodemapdb tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc + + Host binaries + git : git + make : make + python : C:/msys64/mingw64/bin/python.exe (version: 3.10) + sphinx-build : C:\msys64\mingw64\bin/sphinx-build.EXE + gdb : /mingw64/bin/gdb-multiarch + iasl : NO + genisoimage : + wixl : NO + smbd : NO + + Configurable features + Documentation : YES + system-mode emulation : YES + user-mode emulation : NO + block layer : YES + Install blobs : YES + module support : NO + fuzzing support : NO + Audio drivers : dsound sdl + Trace backends : log + D-Bus display : NO + QOM debugging : NO + vhost-kernel support : NO + vhost-net support : NO + vhost-user support : NO + vhost-user-crypto support : NO + vhost-user-blk server support: NO + vhost-vdpa support : NO + build guest agent : YES + + Compilation + host CPU : x86_64 + host endianness : little + C compiler : cc -m64 -mcx16 + Host C compiler : cc -m64 -mcx16 + C++ compiler : c++ -m64 -mcx16 + CFLAGS : -O2 -g + CXXFLAGS : -O2 -g + QEMU_CFLAGS : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prot +otypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -W +type-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallt +hrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong + QEMU_CXXFLAGS : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef -Wwri +te-strings -fno-strict-aliasing -fno-common -fwrapv -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wendif-labels -W +expansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong + QEMU_OBJCFLAGS : -Wold-style-declaration -Wold-style-definition -Wtype-limits -Winit-self -Wempty-body -Wnested-externs -Wendif-labels -Wexpan +sion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi + QEMU_LDFLAGS : -fstack-protector-strong -Wl,--no-seh -Wl,--nxcompat -Wl,--warn-common + profiler : NO + link-time optimization (LTO) : NO + PIE : NO + static build : NO + malloc trim support : NO + membarrier : NO + debug stack usage : NO + mutex debugging : NO + memory allocator : system + avx2 optimization : YES + avx512f optimization : NO + gprof enabled : NO + gcov : NO + thread sanitizer : NO + CFI support : NO + strip binaries : NO + sparse : NO + mingw32 support : YES + + Cross compilers + x86_64 : cc + + Targets and accelerators + KVM support : NO + HAX support : YES + HVF support : NO + WHPX support : YES + NVMM support : NO + Xen support : NO + TCG support : YES + TCG backend : native (x86_64) + TCG plugins : NO + TCG debug enabled : NO + target list : aarch64-softmmu alpha-softmmu arm-softmmu avr-softmmu cris-softmmu hppa-softmmu i386-softmmu loongarch64-softmmu m68k-softmmu + microblaze-softmmu microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu nios2-softmmu or1k-softmmu ppc-softmmu ppc64-softmmu riscv3 +2-softmmu riscv64-softmmu rx-softmmu s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu tricore-softmmu x86_64-softmmu xtensa-softmmu xtensae +b-softmmu + default devices : YES + out of process emulation : NO + vfio-user server : NO + + Block layer support + coroutine backend : win32 + coroutine pool : YES + Block whitelist (rw) : + Block whitelist (ro) : + Use block whitelist in tools : NO + VirtFS support : NO + build virtiofs daemon : NO + Live block migration : YES + replication support : YES + bochs support : YES + cloop support : YES + dmg support : YES + qcow v1 support : YES + vdi support : YES + vvfat support : YES + qed support : YES + parallels support : YES + FUSE exports : NO + VDUSE block exports : NO + + Crypto + TLS priority : NORMAL + GNUTLS support : YES 3.7.8 + GNUTLS crypto : YES + libgcrypt : NO + nettle : NO + AF_ALG support : NO + rng-none : NO + Linux keyring : NO + + Dependencies + SDL support : YES + SDL image support : YES 2.6.2 + GTK support : YES + pixman : YES 0.42.2 + VTE support : NO + slirp support : YES 4.7.0 + libtasn1 : YES 4.19.0 + PAM : NO + iconv support : YES + curses support : YES + virgl support : NO + blkio support : NO + curl support : YES 7.86.0 + Multipath support : NO + PNG support : YES 1.6.39 + VNC support : YES + VNC SASL support : YES + VNC JPEG support : YES 2.1.4 + DirectSound support : YES + JACK support : NO + brlapi support : NO + vde support : NO + netmap support : NO + l2tpv3 support : NO + Linux AIO support : NO + Linux io_uring support : NO + ATTR/XATTR support : NO + RDMA support : NO + PVRDMA support : NO + fdt support : internal + libcap-ng support : NO + bpf support : NO + spice protocol support : YES 0.14.4 + spice server support : YES 0.15.1 + rbd support : NO + smartcard support : NO + U2F support : NO + libusb : YES 1.0.26 + usb net redir : YES 0.8.0 + OpenGL support (epoxy) : NO + GBM : NO + libiscsi support : NO + libnfs support : YES 5.0.2 + QGA VSS support : YES + seccomp support : NO + GlusterFS support : NO + TPM support : NO + libssh support : YES 0.10.4 + lzo support : YES + snappy support : YES + bzip2 support : YES + lzfse support : NO + zstd support : YES 1.5.2 + NUMA host support : NO + capstone : YES 4.0.2 + libpmem support : NO + libdaxctl support : NO + libudev : NO + FUSE lseek : NO + selinux : NO + + User defined options + Native files : config-meson.cross + bindir : + prefix : C:/msys64/qemu + werror : true + b_pie : false + gtk : enabled + qemu_suffix : + sdl : enabled + vfio_user_server : disabled + +Found ninja-1.11.1 at C:/msys64/mingw64/bin/ninja.exe +Running postconf script 'C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/symlink-install-tree.py' +--- stdout --- + +--- stderr --- +error making symbolic link C:/msys64/qemu/share/trace-events-all +Traceback (most recent call last): + File "C:\msys64\home\Roberto\qemu\scripts\symlink-install-tree.py", line 33, in <module> + raise e + File "C:\msys64\home\Roberto\qemu\scripts\symlink-install-tree.py", line 29, in <module> + os.symlink(source, bundle_dest) +OSError: [WinError 1314] Il privilegio richiesto non appartiene al client: 'C:/msys64/home/Roberto/qemu/build/trace/trace-events-all' -> 'qemu-bundle/msys64/qem +u/share/trace-events-all' +``` +Additional information: +The line below ensures that proper tags are added to the issue. +Please do not remove it. +--> diff --git a/results/classifier/gemma3:12b/permissions/1394 b/results/classifier/gemma3:12b/permissions/1394 new file mode 100644 index 00000000..2688b804 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1394 @@ -0,0 +1,62 @@ + +Byte-swapping issue in getresuid on qemu-user-sparc64 +Description of problem: +When calling getresuid() in the big-endian sparc64 guest, the uid_t values are written with their 16-bit halves reversed. + +For example, the UID 0x000003e8 (1000) becomes 0x03e80000. +Steps to reproduce: +A minimal test case looks like this: +```c +#define _GNU_SOURCE +#include <stdio.h> +#include <sys/types.h> +#include <pwd.h> +#include <unistd.h> + +int main(int argc, char **argv) { + struct passwd *pw = getpwuid(geteuid()); + if (pw == NULL) { + perror("getpwuid failure"); + return 1; + } + printf("getpwuid()->pw_uid=0x%08x\n", pw->pw_uid); + + uid_t ruid = 0, euid = 0, suid = 0; + if (getresuid(&ruid, &euid, &suid) != 0) { + perror("getresuid failure"); + return 1; + } + printf("getresuid()->suid=0x%08x\n", suid); + + return 0; +} +``` + +Compile and run with: +``` +$ sparc64-linux-gnu-gcc -Wall -O0 -g -o sid-sparc64/test test.c +$ sudo chroot sid-sparc64 +[chroot] $ qemu-sparc64-static ./test +``` + +Alternatively, static compilation without a chroot is also possible (despite a warning about `getpwuid()`): +``` +$ sparc64-linux-gnu-gcc -static -Wall -O0 -g -o test test.c +$ qemu-sparc64-static ./test +``` + +Expected output: +``` +$ ./test +getpwuid()->pw_uid=0x000003e8 +getresuid()->suid=0x000003e8 +``` + +Actual output: +``` +$ ./test +getpwuid()->pw_uid=0x000003e8 +getresuid()->suid=0x03e80000 +``` +Additional information: +I'm not sure if this is a glibc, qemu or kernel issue, but it doesn't occur outside qemu. diff --git a/results/classifier/gemma3:12b/permissions/1426593 b/results/classifier/gemma3:12b/permissions/1426593 new file mode 100644 index 00000000..4876e796 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1426593 @@ -0,0 +1,9 @@ + +linux-user: doesn't handle guest setting its memory ulimit very small + +using the latest build from git (hash 041ccc922ee474693a2869d4e3b59e920c739bc0 ) and all older versions i have tested. +i am using an amd64 host with an arm chroot using "qemu-user arm cortex-a8" cpu emulation to run it + +building coreutils hangs on "checking whether printf survives out-of-memory conditions" + +i have not had time to dig into the build system to isolate the test yet, there were old reports of this bug but i can no longer find them on google. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1432103 b/results/classifier/gemma3:12b/permissions/1432103 new file mode 100644 index 00000000..a963011e --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1432103 @@ -0,0 +1,4 @@ + +error in x86 executable segment permission check + +When the code segment register (%cs) selects an executable segment with no read permission, mov instructions that read from the segment via %cs prefix can still succeed without causing a general protection error. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1505 b/results/classifier/gemma3:12b/permissions/1505 new file mode 100644 index 00000000..ccf24bd5 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1505 @@ -0,0 +1,2 @@ + +guest agent: add --allow-rpcs / whitelist mode diff --git a/results/classifier/gemma3:12b/permissions/1505652 b/results/classifier/gemma3:12b/permissions/1505652 new file mode 100644 index 00000000..7bab0d55 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1505652 @@ -0,0 +1,53 @@ + +An IO error happen when qemu snapshot-create + +My qemu version is 1.7.1,but when I try to make live snapshot by libvirt,the libvirt sometimes report an error :qemuMonitorJSONCheckError:377 : internal error: unable to execute QEMU command 'transaction': An IO error has occurred. + +Here is the command being snpshot create by virsh: +virsh snapshot-create snapshot-test.vm snapshot.xml --no-metadata --disk-only --reuse-external +the snapshot.xml: +<domainsnapshot> + <description>test</description> + <disks> + <disk name='vda' snapshot="external"> + <source dev='/home/disk/sbd8' file='/home/disk/sdb8' type="block"/> + </disk> + </disks> +</domainsnapshot> + + +I have read the qemu code about the snapshot create, and I find the qemu when call the function handle_aiocb_rw_linear(): +static ssize_t handle_aiocb_rw_linear(RawPosixAIOData *aiocb, char *buf) +{ + ssize_t offset = 0; + ssize_t len; + + while (offset < aiocb->aio_nbytes) { + if (aiocb->aio_type & QEMU_AIO_WRITE) { + len = pwrite(aiocb->aio_fildes, + (const char *)buf + offset, + aiocb->aio_nbytes - offset, + aiocb->aio_offset + offset); + } else { + len = pread(aiocb->aio_fildes, + buf + offset, + aiocb->aio_nbytes - offset, + aiocb->aio_offset + offset); + } + if (len == -1 && errno == EINTR) { + continue; + } else if (len == -1) { + offset = -errno; + break; + } else if (len == 0) { + break; + } + offset += len; + } + + return offset; +} + +The function pwrite happen error,the errono is 1,and the error describe:"pwrite failed, Operation not permitted (1, EPERM) because the process does not have the appropriate privileges to use the pwrite system call". +The qemu call stack about is: +external_snapshot_prepare()->bdrv_flush()->...->paio_submit->...->handle_aiocb_rw_linear. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1508 b/results/classifier/gemma3:12b/permissions/1508 new file mode 100644 index 00000000..e3cd01a3 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1508 @@ -0,0 +1,92 @@ + +vfio-pci 0000:00:02.1: VF token required to access device +Description of problem: +I'm trying to use SR-IOV on an i5-12400 trying to create VFs for my UHD Graphics 730. + +I had to build this DKMS module for it to work: +https://github.com/strongtz/i915-sriov-dkms + +So far I have managed to have 7 VFs created per the dmsg: +``` +[root@fedora ~]# dmesg | grep -i vf +[ 0.000000] Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.1.13-200.fc37.x86_64 root=UUID=a1ec5891-71c6-44ea-9beb-c4f1cde55c0e ro rootflags=subvol=root rhgb quiet intel_iommu=on iommu=pt split_lock_detect=off i915.enable_guc=7 video=vesafb:off video=efifb:off initcall_blacklist=sysfb_init vfio-pci.disable_vga=1 vfio-pci.enable_sriov=1 vfio-pci.ids=8086:4692,8086:7ad0 +[ 0.074362] Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.1.13-200.fc37.x86_64 root=UUID=a1ec5891-71c6-44ea-9beb-c4f1cde55c0e ro rootflags=subvol=root rhgb quiet intel_iommu=on iommu=pt split_lock_detect=off i915.enable_guc=7 video=vesafb:off video=efifb:off initcall_blacklist=sysfb_init v +io-pci.disable_vga=1 vfio-pci.enable_sriov=1 vfio-pci.ids=8086:4692,8086:7ad0 +[ 0.288336] pci 0000:00:02.0: VF(n) BAR0 space: [mem 0x60e0000000-0x60e6ffffff 64bit] (contains BAR0 for 7 VFs) +[ 0.288339] pci 0000:00:02.0: VF(n) BAR2 space: [mem 0x6000000000-0x60dfffffff 64bit pref] (contains BAR2 for 7 VFs) +[ 0.293518] pci 0000:01:00.0: VF(n) BAR0 space: [mem 0xa1330000-0xa134ffff 64bit] (contains BAR0 for 8 VFs) +[ 0.336464] VFS: Disk quotas dquot_6.6.0 +[ 0.336470] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) +[ 1.028560] VFIO - User Level meta-driver version: 0.3 +[ 1.039931] vfio-pci 0000:00:02.0: vgaarb: deactivate vga console +[ 1.039933] vfio-pci 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem +[ 1.040007] vfio_pci: add [8086:4692[ffffffff:ffffffff]] class 0x000000/00000000 +[ 1.040140] vfio_pci: add [8086:7ad0[ffffffff:ffffffff]] class 0x000000/00000000 +[ 3.373977] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 655360 ms ovfl timer +[ 45.696323] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.1 driver_override +[ 45.696356] vfio-pci 0000:00:02.1: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.696598] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.2 driver_override +[ 45.696609] vfio-pci 0000:00:02.2: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.696724] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.3 driver_override +[ 45.696734] vfio-pci 0000:00:02.3: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.696811] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.4 driver_override +[ 45.696825] vfio-pci 0000:00:02.4: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.696947] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.5 driver_override +[ 45.696958] vfio-pci 0000:00:02.5: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.697050] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.6 driver_override +[ 45.697060] vfio-pci 0000:00:02.6: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.697127] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.7 driver_override +[ 45.697137] vfio-pci 0000:00:02.7: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +``` +I've blacklisted these modules: +``` +blacklist igb +blacklist i915 +blacklist snd_hda_intel +blacklist snd_sof_pci_intel_tgl +``` +And loaded these modules: +``` +vfio +vfio-pci +vfio_virqfd +vfio_iommu_type1 +``` +Kernel args: +``` +GRUB_CMDLINE_LINUX="rhgb quiet intel_iommu=on iommu=pt split_lock_detect=off i915.enable_guc=7 video=vesafb:off video=efifb:off initcall_blacklist=sysfb_init vfio-pci.disable_vga=1 vfio-pci.enable_sriov=1 vfio-pci.ids=8086:4692,8086:7ad0" +``` + +**Error shown:** +``` +[root@fedora ~]# ./test.sh +QEMU 7.0.0 monitor - type 'help' for more information +(qemu) qemu-system-x86_64: -device vfio-pci,host=0000:02.2,multifunction=on,bus=pcie.1,addr=0x00,x-vga=on: vfio 0000:00:02.2: error getting device from group 14: Permission denied +Verify all devices in group 14 are bound to vfio-<bus> or pci-stub and not already in use +``` +**DMESG shows:** +``` +[ 2160.408395] vfio-pci 0000:00:02.2: VF token required to access device +``` + +This lead me to this conversation / thread: + +https://inbox.dpdk.org/dev/CALBAE1MrEoCc8Ch6MNUNTsOcZyJnhr+z+iD0VWjHagQsEdBWCw@mail.gmail.com/#t + +Quote: "Something needs to be sorted with the QEMU community." + +In fact, something needs to be sorted. **It seems there's no way to specify this VF token anywhere from the CLI args**, so I'm reporting this as a bug (or feature not developed yet?? any ETA?) + +**Additional information:** It seems that QEMU might require a patch or a change to allow this VF token to be passed through. It seems that DPDK and other similar projects have already implemented this (it seems Linux has it since Kernel 5.7 - Maybe I'm missing something to pass this token with QEMU considering how old that kernel is? I'd expect this flag to be here in QEMU already) + +**Useful code / info:** +* https://patches.dpdk.org/project/dpdk/patch/20200529013710.72302-3-haiyue.wang@intel.com/ +* https://github.com/intel/pf-bb-config/blob/master/README.md#usage-example +* https://support.hpe.com/hpesc/public/docDisplay?docId=sd00001790en_us&docLocale=en_US&page=GUID-1D5D76F8-522A-47F5-922B-142BD5177033.html + +Thanks, + +-Alemar +Steps to reproduce: +1. See description +2. Run QEMU as described diff --git a/results/classifier/gemma3:12b/permissions/1515 b/results/classifier/gemma3:12b/permissions/1515 new file mode 100644 index 00000000..177ef5fb --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1515 @@ -0,0 +1,19 @@ + +qemu have the way to change the windows sid? +Description of problem: +I want to change the guest of windows sid after clone guest, have the way to change it before new guest start? "virt-sysprep" Seems impossible to do it. Although it can be done manually as follow: + +[change sid in windows system](https://www.heelpbook.net/2019/microsoft-changing-sid-of-cloned-vms/) + +query windows sid: +cmd: whoami /user + + +step: +1.clone a new windows guest vm_new + +2.change the sid of vm_new (step2 I don't know how to do that) + +3.start vm_new + +4.query the vm_new's sid is change diff --git a/results/classifier/gemma3:12b/permissions/1525676 b/results/classifier/gemma3:12b/permissions/1525676 new file mode 100644 index 00000000..a004143b --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1525676 @@ -0,0 +1,36 @@ + +qemu runas and sandbox option incompatible, process will hang in futex after setgid + +With -runas [user] and -sandbox on, qemu process will fail in the process of dropping privileges. While setgid() is done (see below), setuid() is not attempted. Instead process blocks waiting for a futex never to come. + +[pid 21769] +++ killed by SIGSYS +++ +[pid 21767] <... tgkill resumed> ) = 0 +[pid 21767] tgkill(21767, 21768, SIGRT_1 <unfinished ...> +[pid 21768] <... nanosleep resumed> {0, 7284187}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) +[pid 21768] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=21767, si_uid=0} --- +[pid 21768] setgid(100) = 0 +[pid 21768] futex(0x7f7f0f53fd1c, FUTEX_WAKE_PRIVATE, 1) = 0 +[pid 21768] rt_sigreturn() = -1 EINTR (Interrupted system call) +[pid 21768] nanosleep({0, 7284187}, <unfinished ...> +[pid 21767] <... tgkill resumed> ) = 0 +[pid 21767] futex(0x7ffd5a9b6890, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...> +[pid 21768] <... nanosleep resumed> 0x7f7f0f53eb00) = 0 +[pid 21768] futex(0x55f52acd1f44, FUTEX_WAIT, 4294967295, NULL + +This bug might be addresses in the discussion/patchset http://qemu.11.n7.nabble.com/PATCH-Add-syscalls-for-runas-and-chroot-to-the-seccomp-sandbox-td359588.html + +# lsb_release -rd +Description: Ubuntu 15.10 +Release: 15.10 + +# apt-cache policy qemu-system-x86 +qemu-system-x86: + Installed: 1:2.3+dfsg-5ubuntu9.1 + Candidate: 1:2.3+dfsg-5ubuntu9.1 + Version table: + *** 1:2.3+dfsg-5ubuntu9.1 0 + 500 http://archive.ubuntu.com/ubuntu/ wily-updates/main amd64 Packages + 500 http://archive.ubuntu.com/ubuntu/ wily-security/main amd64 Packages + 100 /var/lib/dpkg/status + 1:2.3+dfsg-5ubuntu9 0 + 500 http://archive.ubuntu.com/ubuntu/ wily/main amd64 Packages \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1531352 b/results/classifier/gemma3:12b/permissions/1531352 new file mode 100644 index 00000000..50516a7f --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1531352 @@ -0,0 +1,7 @@ + +QEMU_LD_PREFIX not load correct library order in the PATH + +run qemu with QEMU_LD_PREFIX argument will not load the library in the PATH. +Ex: I use debootstrap to download the library of i386 architecture +And use -L point to the path. +But not load the library from that directory. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1548471 b/results/classifier/gemma3:12b/permissions/1548471 new file mode 100644 index 00000000..619c0662 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1548471 @@ -0,0 +1,10 @@ + +Lost of log file during block migration + + Hello, i've discovered that during live block migration +log file is copied(or created on destination) but it actually empty. +When regular(cold) migration is called log file migrates successfully. +I'm working on nova project in openstack and i've tried to fix it by adding +simple scp from source to destination, but log file is owned by libvirt-qemu user +and i cannot do that from regular user created by openstack. +Could explain how can i migrate logs safely? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1585840 b/results/classifier/gemma3:12b/permissions/1585840 new file mode 100644 index 00000000..9edd28f3 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1585840 @@ -0,0 +1,10 @@ + +multiprocess program gets incorrect results with qemu arm-linux-user + +The attached program can run either in a threaded mode or a multiprocess mode. It defaults to threaded mode, and switches to multiprocess mode if the first positional argument is "process". "success" of the test is defined as the final count being seen as 2000000 by both tasks. + +In standard linux x86_64 userspace (i7, 4 cores) and in standard armhf userspace (4 cores), the test program consistently completes successfully in both modes. But with qemu arm-linux-user, the test consistently succeeds in threaded mode and generally fails in multiprocess mode. + +The test reflects an essential aspect of how the Free and Open Source project linuxcnc's IPC system works: shared memory regions (created by shmat, but mmap would probably behave the same) contain data and mutexes. I observed that our testsuite encounters numerous deadlocks and failures when running in an schroot with qemu-user (x86_64 host), and I believe the underlying cause is improper support for atomic operations in a multiprocess model. (the testsuite consistently passes on real hardware) + +I observed the same failure at v1.6.0 and master (v2.6.0-424-g287db79), as well as in the outdated Debian version 1:2.1+dfsg-12+deb8u5a. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1605506 b/results/classifier/gemma3:12b/permissions/1605506 new file mode 100644 index 00000000..1fb34858 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1605506 @@ -0,0 +1,155 @@ + +qemu driver_mirror error "Operation not permitted" + +I use libvirtd to call qemu drive_mirror return error message "Operation not permitted", But directly run qemu and call drive_mirror is OK; +when drive_mirror target is logic device return error message "Operation not permitted",But the file is OK; + +Operating Environment： +OS:ubuntu 14.04 +kernel:3.16.0-28-generic +libvirt-bin version: 1.2.2-0ubuntu13.1.17 +qemu:2.5.0 or 2.6.0 +run vm user: root +（retry in redhat7.2 have the same problem！） + +Here is my running process: +libvirtd call +prepare libvirt xml libvirt.xml +<?xml version="1.0"?><domain type="kvm"> + <name>i-745F35DC</name> + <memory>65536</memory> + <vcpu>1</vcpu> + <cpu mode="host-model"><model fallback="allow"/><topology sockets="1" threads="1" cores="1"/></cpu> + <os><type>hvm</type><boot dev="cdrom"/><boot dev="hd"/></os> + <features><acpi/><apic/><pae/></features> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/local/qemu-2.5.0-20160720/bin/qemu-system-x86_64</emulator> + <graphics type="vnc" passwd="" autoport="yes" keymap="en-us" listen="0.0.0.0"/> + <disk type="file" device="disk"> + <driver name="qemu" type="raw" cache="none"/> + <source file="/tmp/image.raw"/> + <target dev="hda" bus="ide"/> + <serial>bc-system</serial> + </disk> + </devices> + <clock offset="localtime"/> +</domain> + +virsh create libvirt.xml +root@test:/opt/run/instance/i-745F35DC# virsh list + Id Name State +---------------------------------------------------- + 2 i-745F35DC running +call drive_mirror: +virsh qemu-monitor-command --hmp i-745F35DC 'drive_mirror -n -f drive-ide0-0-0 /dev/vg_bc_local/test raw' +Could not open '/dev/vg_bc_local/test': Operation not permitted + +directly run qemu and call drive_mirror: +/usr/local/qemu-2.5.0-20160720/bin/qemu-system-x86_64 -hda /tmp/image.raw -m 64 --enable-kvm -vnc :51 -monitor stdio +QEMU 2.5.0 monitor - type 'help' for more information +(qemu) info block +ide0-hd0 (#block135): /tmp/image.raw (raw) + Cache mode: writeback +(qemu) drive_mirror -n -f ide0-hd0 /dev/vg_bc_local/test raw +(qemu) info block-jobs +Type mirror, device ide0-hd0: Completed 41126400 of 41126400 bytes, speed limit 0 bytes/s +(qemu) block_job_cancel ide0-hd0 +(qemu) info block-jobs +No active jobs + +It is OK!!! + + +Here is my debugging process: +Recompile qemu-2.5.0 to enable debug +../configure --prefix=/usr/local/qemu-2.5.0-20160720 --enable-trace-backend=simple --enable-werror --disable-xen --disable-virtfs --enable-kvm --enable-seccomp --enable-docs --enable-debug-tcg --enable-vnc-sasl --enable-linux-aio --enable-lzo --enable-snappy --enable-usb-redir --enable-vnc-png --disable-vnc-jpeg --enable-uuid --disable-vhost-scsi --enable-rbd --block-drv-rw-whitelist=qcow2,raw,file,host_device,blkdebug,nbd,iscsi,rbd,cdp --block-drv-ro-whitelist=vmdk,vhdx,vpc --target-list=x86_64-softmmu CFLAGS=-O0 + +Use libvirtd to Re-run VM and debug by gdb +VM process info: +root 7804 1 0 10:45 ? 00:00:10 /usr/local/qemu-2.5.0-20160720/bin/qemu-system-x86_64 -name i-745F35DC -S -machine pc-i440fx-2.5,accel=kvm,usb=off -cpu Westmere,+invpcid,+erms,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+abm,+rdtscp,+pdpe1gb,+rdrand,+f16c,+avx,+osxsave,+xsave,+tsc-deadline,+movbe,+pcid,+pdcm,+xtpr,+fma,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 64 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid ef55dfa6-b82e-488d-a7fc-4c882f8091ab -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/i-745F35DC.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/tmp/image.raw,if=none,id=drive-ide0-0-0,format=raw,serial=bc-system,cache=none -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -vnc 0.0.0.0:0,password -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 + +gdb -p 7804 +set breakpoint +(gdb) i b +Num Type Disp Enb Address What +1 breakpoint keep y 0x00007f51d9e92cb1 in qmp_drive_mirror at /opt/qemu/qemu-2.5.0/blockdev.c:3310 +2 breakpoint keep y 0x00007f51da1252f2 in raw_open_common at /opt/qemu/qemu-2.5.0/block/raw-posix.c:457 +3 breakpoint keep y 0x00007f51da12500f in raw_parse_flags at /opt/qemu/qemu-2.5.0/block/raw-posix.c:358 +(gdb) + +call drive_mirror and debug: + +(gdb) +raw_open_common (bs=0x7f4b27259ab0, options=0x7f4b27480290, bdrv_flags=24674, open_flags=0, errp=0x7fff4a19f548) + at /opt/qemu/qemu-2.5.0/block/raw-posix.c:484 +484 s->fd = -1; +(gdb) n +485 fd = qemu_open(filename, s->open_flags, 0644); +(gdb) s +qemu_open (name=0x7f4b2642b5c0 "/dev/vg_bc_local/test", flags=2) at /opt/qemu/qemu-2.5.0/util/osdep.c:177 +177 int mode = 0; +(gdb) n +183 if (strstart(name, "/dev/fdset/", &fdset_id_str)) { +(gdb) +214 if (flags & O_CREAT) { +(gdb) +223 char arg[1000] = {0}; +(gdb) +227 ret = open(name, flags , mode); +(gdb) p name +$1 = 0x7f4b2642b5c0 "/dev/vg_bc_local/test" +(gdb) p flags +$2 = 2 +(gdb) p mode +$3 = 0 +(gdb) n +(gdb) p ret +$4 = -1 + +get system erroron is :Operation not permitted +!!!!!!!!!!!!!! + + +Re-run VM Directly and debug by gdb +/usr/local/qemu-2.5.0-20160720/bin/qemu-system-x86_64 -hda /tmp/image.raw -m 64 --enable-kvm -vnc :51 -monitor stdio +(qemu) info block +ide0-hd0 (#block135): /tmp/image.raw (raw) + Cache mode: writeback +(qemu) drive_mirror -n -f ide0-hd0 /dev/vg_bc_local/test raw + +gdb debug: +(gdb) i b +Num Type Disp Enb Address What +1 breakpoint keep y 0x00007f51d9e92cb1 in qmp_drive_mirror at /opt/qemu/qemu-2.5.0/blockdev.c:3310 +2 breakpoint keep y 0x00007f51da1252f2 in raw_open_common at /opt/qemu/qemu-2.5.0/block/raw-posix.c:457 +3 breakpoint keep y 0x00007f51da12500f in raw_parse_flags at /opt/qemu/qemu-2.5.0/block/raw-posix.c:358 +(gdb) +raw_open_common (bs=0x7f51dc15d350, options=0x7f51dc083110, bdrv_flags=24642, open_flags=0, errp=0x7fff5aaa9738) + at /opt/qemu/qemu-2.5.0/block/raw-posix.c:484 +484 s->fd = -1; +(gdb) n +485 fd = qemu_open(filename, s->open_flags, 0644); +(gdb) s +qemu_open (name=0x7f51dca09230 "/dev/vg_bc_local/test", flags=2) at /opt/qemu/qemu-2.5.0/util/osdep.c:177 +177 int mode = 0; +(gdb) n +183 if (strstart(name, "/dev/fdset/", &fdset_id_str)) { +(gdb) +214 if (flags & O_CREAT) { +(gdb) +223 char arg[1000] = {0}; +(gdb) +227 ret = open(name, flags , mode); +(gdb) p name +$1 = 0x7f51dca09230 "/dev/vg_bc_local/test" +(gdb) p flags +$2 = 2 +(gdb) p mode +$3 = 0 +(gdb) n +(gdb) p ret +$4 = 16 +(gdb) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1610368 b/results/classifier/gemma3:12b/permissions/1610368 new file mode 100644 index 00000000..a03b75e2 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1610368 @@ -0,0 +1,44 @@ + +qemu-system-x86_64 read acces DENIED in apparmor + +When starting a win8.1 VM in virt-manager I see theses errors in dmesg + +[ 185.210435] audit: type=1400 audit(1470419576.704:27): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" pid=4885 comm="apparmor_parser" +[ 185.220800] audit: type=1400 audit(1470419576.716:28): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4//qemu_bridge_helper" pid=4885 comm="apparmor_parser" +[ 185.356159] audit: type=1400 audit(1470419576.848:29): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:1" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356244] audit: type=1400 audit(1470419576.848:30): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:129" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356317] audit: type=1400 audit(1470419576.848:31): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:130" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356396] audit: type=1400 audit(1470419576.848:32): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:131" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356486] audit: type=1400 audit(1470419576.852:33): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:257" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356545] audit: type=1400 audit(1470419576.852:34): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:0" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 + + +the process 4912 is : + +libvirt+ 4912 1 36 19:52 ? 00:00:51 qemu-system-x86_64 -enable-kvm -name win8.1 -S -machine pc-i440fx-2.5,accel=kvm,usb=off -cpu Broadwell-noTSX,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid d694857f-577a-45d4-81d2-4f3672ae7bd4 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-win8.1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/TEMPO/VMS/win81.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:9d:db:21,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -k fr -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device usb-host,hostbus=2,hostaddr=10,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on + + +I have no visible problems with the VM but just wanted to signal this to developpers in case this is not normal behaviour. + +ProblemType: Bug +DistroRelease: Ubuntu 16.04 +Package: qemu-system-x86 1:2.5+dfsg-5ubuntu10.3 +ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13 +Uname: Linux 4.4.0-31-generic x86_64 +ApportVersion: 2.20.1-0ubuntu2.1 +Architecture: amd64 +CurrentDesktop: KDE +Date: Fri Aug 5 19:57:37 2016 +InstallationDate: Installed on 2016-05-14 (83 days ago) +InstallationMedia: Kubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) +ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.4.0-31-generic root=UUID=54def8c1-2495-44c4-b760-f8dbc15e25b1 ro rootflags=subvol=@ quiet splash vt.handoff=7 +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 02/24/2016 +dmi.bios.vendor: Intel Corporation +dmi.bios.version: RYBDWi35.86A.0355.2016.0224.1501 +dmi.board.name: NUC5i5RYB +dmi.board.vendor: Intel Corporation +dmi.board.version: H40999-504 +dmi.chassis.type: 3 +dmi.modalias: dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0355.2016.0224.1501:bd02/24/2016:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-504:cvn:ct3:cvr: \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1615 b/results/classifier/gemma3:12b/permissions/1615 new file mode 100644 index 00000000..e22c51ac --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1615 @@ -0,0 +1,12 @@ + +8.0.0: Crash when attempting to commit snapshot +Description of problem: +When trying to commit a snapshot to the backing store, qemu exits with the error: + +`qemu: qemu_mutex_unlock_impl: Operation not permitted` +Steps to reproduce: +1. Run qemu command above +2. Open the monitor virtual console (Ctrl-Alt-2) +3. Execute command: `commit os` +Additional information: +Attached are the [backtrace](/uploads/ba8f519e6b00eb054ba416054c782122/8.0.0-1-bt) and the [configure output](/uploads/17124b45e12b252bd01cf41e7a3d2ea4/8.0.0-1-conf.gz). This is a regression from 7.2.1 diff --git a/results/classifier/gemma3:12b/permissions/1626972 b/results/classifier/gemma3:12b/permissions/1626972 new file mode 100644 index 00000000..41cdf8ad --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1626972 @@ -0,0 +1,37 @@ + +QEMU memfd_create fallback mechanism change for security drivers + +And, when libvirt starts using apparmor, and creating apparmor profiles for every virtual machine created in the compute nodes, mitaka qemu (2.5 - and upstream also) uses a fallback mechanism for creating shared memory for live-migrations. This fall back mechanism, on kernels 3.13 - that don't have memfd_create() system-call, try to create files on /tmp/ directory and fails.. causing live-migration not to work. + +Trusty with kernel 3.13 + Mitaka with qemu 2.5 + apparmor capability = can't live migrate. + +From qemu 2.5, logic is on : + +void *qemu_memfd_alloc(const char *name, size_t size, unsigned int seals, int *fd) +{ + if (memfd_create)... ### only works with HWE kernels + + else ### 3.13 kernels, gets blocked by apparmor + tmpdir = g_get_tmp_dir + ... + mfd = mkstemp(fname) +} + +And you can see the errors: + +From the host trying to send the virtual machine: + +2016-08-15 16:36:26.160 1974 ERROR nova.virt.libvirt.driver [req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 133ebc3585c041aebaead8c062cd6511 - - -] [instance: 2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Migration operation has aborted +2016-08-15 16:36:26.248 1974 ERROR nova.virt.libvirt.driver [req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 133ebc3585c041aebaead8c062cd6511 - - -] [instance: 2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Live Migration failure: internal error: unable to execute QEMU command 'migrate': Migration disabled: failed to allocate shared memory + +From the host trying to receive the virtual machine: + +Aug 15 16:36:19 tkcompute01 kernel: [ 1194.356794] type=1400 audit(1471289779.791:72): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" pid=12565 comm="apparmor_parser" +Aug 15 16:36:19 tkcompute01 kernel: [ 1194.357048] type=1400 audit(1471289779.791:73): apparmor="STATUS" operation="profile_load" profile="unconfined" name="qemu_bridge_helper" pid=12565 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.877027] type=1400 audit(1471289780.311:74): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" pid=12613 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.904407] type=1400 audit(1471289780.343:75): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="qemu_bridge_helper" pid=12613 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.973064] type=1400 audit(1471289780.407:76): apparmor="DENIED" operation="mknod" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/memfd-tNpKSj" pid=12625 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 ouid=107 +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.979871] type=1400 audit(1471289780.411:77): apparmor="DENIED" operation="open" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/" pid=12625 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0 +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.979881] type=1400 audit(1471289780.411:78): apparmor="DENIED" operation="open" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/var/tmp/" pid=12625 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0 + +When leaving libvirt without apparmor capabilities (thus not confining virtual machines on compute nodes, the live migration works as expected, so, clearly, apparmor is stepping into the live migration). I'm sure that virtual machines have to be confined and that this isn't the desired behaviour... \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1649236 b/results/classifier/gemma3:12b/permissions/1649236 new file mode 100644 index 00000000..35220edb --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1649236 @@ -0,0 +1,20 @@ + +Commit snapshot fails with Permission denied when daemonized + +When running qemu with daemonize option it is impossible to run "commit all" in monitor. + +I run qemu 2.7.0 under gentoo 64 bit distribution with following command line: + +qemu-system-x86_64 -m 4096 -cpu host -smp 2 -enable-kvm -snapshot \ + -drive file=vm.img,if=virtio \ + -net nic,model=virtio,macaddr=11:11:11:11:11:11 \ + -net tap,ifname=tap$PORT,script=no,downscript=no \ + -vnc :1 -daemonize \ + -chardev vc,id=mon0 -mon chardev=mon0,mode=readline \ + -chardev socket,id=mon1,host=localhost,port=10001,server,nowait -mon chardev=mon1,mode=control + +I connect to vm through VNC viewer and press CTRL+ALT+2 and run "commit all" command. +Following error is shown: +`commit` error for `all`: Permission denied + +When I run my VM without `daemonize` option the command "commit all" works without errors. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1653577 b/results/classifier/gemma3:12b/permissions/1653577 new file mode 100644 index 00000000..7c009f25 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1653577 @@ -0,0 +1,4 @@ + +Ability to set umask for 9pfs + +We should be able to specify the umask for 9pfs so that files created by the guest can be accessed by other users on the host. Currently they're only accessible by the user running qemu (and of course, root). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1681688 b/results/classifier/gemma3:12b/permissions/1681688 new file mode 100644 index 00000000..428bc19b --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1681688 @@ -0,0 +1,14 @@ + +qemu live migration failed + +qemu live migration failed + +the dest qemu report this error. + +Receiving block device images +Completed 0 %^Mqemu-system-x86_64: block/io.c:1348: bdrv_aligned_pwritev: Assertion `child->perm & BLK_PERM_WRITE' failed. + +this bug is caused by this patch: +http://git.qemu-project.org/?p=qemu.git;a=commit;h=d35ff5e6b3aa3a706b0aa3bcf11400fac945b67a + +rollback this commit, the problem solved. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1700380 b/results/classifier/gemma3:12b/permissions/1700380 new file mode 100644 index 00000000..af7531d2 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1700380 @@ -0,0 +1,13 @@ + +commit snapshot image got Permission denied error + +qemu 2.9.0, adm64, start image with -snapshot param, make some changes in the image, then: + +$telnet localhost 7000 + +(qemu) commit virtio0 +'commit' error for 'virtio0': Permission denied + +Nerver met this problem before, commit is ok. I recently compiled v2.9.0, so is there some new param in qemu-qemu-system-x86_64 to avoid commit Permission denied? + +Regards. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1711 b/results/classifier/gemma3:12b/permissions/1711 new file mode 100644 index 00000000..f765a2f9 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1711 @@ -0,0 +1,2 @@ + +unable to set PWD with guest-exec without starting a shell diff --git a/results/classifier/gemma3:12b/permissions/1718295 b/results/classifier/gemma3:12b/permissions/1718295 new file mode 100644 index 00000000..bcea1e6b --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1718295 @@ -0,0 +1,60 @@ + +Live migration fails with qemu-img >= 2.10: "Failed to get shared "write" lock\nIs another process using the image?" + +Looks like this is pretty new: + +http://logs.openstack.org/01/503601/7/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/b19b77c/logs/screen-n-api.txt.gz?level=TRACE#_Sep_19_17_47_11_508623 + +Sep 19 17:47:11.508623 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: ERROR nova.api.openstack.extensions [None req-e31fde7b-317f-4db9-b225-10b6e11b2dff tempest-LiveMigrationTest-1678596498 tempest-LiveMigrationTest-1678596498] Unexpected exception in API method: MigrationError_Remote: Migration error: Disk info file is invalid: qemu-img failed to execute on /opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk : Unexpected error while running command. +Sep 19 17:47:11.508805 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Command: /usr/bin/python2 -m oslo_concurrency.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C qemu-img info /opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk +Sep 19 17:47:11.508946 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Exit code: 1 +Sep 19 17:47:11.509079 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Stdout: u'' +Sep 19 17:47:11.509233 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Stderr: u'qemu-img: Could not open \'/opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk\': Failed to get shared "write" lock\nIs another process using the image?\n' +Sep 19 17:47:11.509487 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Traceback (most recent call last): +Sep 19 17:47:11.509649 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 160, in _process_incoming +Sep 19 17:47:11.509789 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: res = self.dispatcher.dispatch(message) +Sep 19 17:47:11.510231 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 222, in dispatch +Sep 19 17:47:11.510418 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: return self._do_dispatch(endpoint, method, ctxt, args) +Sep 19 17:47:11.510555 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 192, in _do_dispatch +Sep 19 17:47:11.510687 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: result = func(ctxt, **new_args) +Sep 19 17:47:11.510829 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/exception_wrapper.py", line 76, in wrapped +Sep 19 17:47:11.510959 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: function_name, call_dict, binary) +Sep 19 17:47:11.511194 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ +Sep 19 17:47:11.511713 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: self.force_reraise() +Sep 19 17:47:11.511852 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise +Sep 19 17:47:11.512037 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: six.reraise(self.type_, self.value, self.tb) +Sep 19 17:47:11.512687 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/exception_wrapper.py", line 67, in wrapped +Sep 19 17:47:11.516811 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: return f(self, context, *args, **kw) +Sep 19 17:47:11.516966 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/compute/utils.py", line 876, in decorated_function +Sep 19 17:47:11.517110 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: return function(self, context, *args, **kwargs) +Sep 19 17:47:11.525392 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/compute/manager.py", line 217, in decorated_function +Sep 19 17:47:11.525526 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: kwargs['instance'], e, sys.exc_info()) +Sep 19 17:47:11.525654 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ +Sep 19 17:47:11.525783 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: self.force_reraise() +Sep 19 17:47:11.525909 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise +Sep 19 17:47:11.526057 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: six.reraise(self.type_, self.value, self.tb) +Sep 19 17:47:11.526186 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/compute/manager.py", line 205, in decorated_function +Sep 19 17:47:11.526314 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: return function(self, context, *args, **kwargs) +Sep 19 17:47:11.529795 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/compute/manager.py", line 5378, in check_can_live_migrate_source +Sep 19 17:47:11.529952 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: block_device_info) +Sep 19 17:47:11.530083 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 5960, in check_can_live_migrate_source +Sep 19 17:47:11.530446 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: block_device_info) +Sep 19 17:47:11.530587 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 6060, in _assert_dest_node_has_enough_disk +Sep 19 17:47:11.530720 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: disk_infos = self._get_instance_disk_info(instance, block_device_info) +Sep 19 17:47:11.531945 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 7254, in _get_instance_disk_info +Sep 19 17:47:11.532099 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: block_device_info) +Sep 19 17:47:11.532234 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 7222, in _get_instance_disk_info_from_config +Sep 19 17:47:11.532366 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: backing_file = libvirt_utils.get_disk_backing_file(path) +Sep 19 17:47:11.532496 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/libvirt/utils.py", line 197, in get_disk_backing_file +Sep 19 17:47:11.532627 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: backing_file = images.qemu_img_info(path, format).backing_file +Sep 19 17:47:11.532755 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: File "/opt/stack/new/nova/nova/virt/images.py", line 72, in qemu_img_info +Sep 19 17:47:11.532896 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: raise exception.InvalidDiskInfo(reason=msg) +Sep 19 17:47:11.533373 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: InvalidDiskInfo: Disk info file is invalid: qemu-img failed to execute on /opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk : Unexpected error while running command. +Sep 19 17:47:11.534451 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Command: /usr/bin/python2 -m oslo_concurrency.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C qemu-img info /opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk +Sep 19 17:47:11.534670 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Exit code: 1 +Sep 19 17:47:11.534902 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Stdout: u'' +Sep 19 17:47:11.541303 ubuntu-xenial-2-node-rax-ord-10997038 <email address hidden>[28339]: Stderr: u'qemu-img: Could not open \'/opt/stack/data/nova/instances/806812af-bf9e-4dc1-8e0c-11603ccd9f62/disk\': Failed to get shared "write" lock\nIs another process using the image?\n' + +http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Unexpected%20exception%20in%20API%20method%3A%20MigrationError_Remote%3A%20Migration%20error%3A%20Disk%20info%20file%20is%20invalid%3A%20qemu-img%20failed%20to%20execute%20on%5C%22%20AND%20tags%3A%5C%22screen-n-api.txt%5C%22&from=7d + +252 hits starting on 9/19, check and gate, all failures. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1719 b/results/classifier/gemma3:12b/permissions/1719 new file mode 100644 index 00000000..3c995300 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1719 @@ -0,0 +1,8 @@ + +Allow TCG plugins to read memory +Additional information: +* `include/qemu/plugin.h` +* `include/qemu/qemu-plugin.h` +* `plugin/api.c` + +PANDA implemented this already (not sure if this solution is acceptable for the mainline QEMU): https://github.com/qemu/qemu/commit/72c661a7f141ab41fbce5e95eb3593b69f40e246 diff --git a/results/classifier/gemma3:12b/permissions/1726394 b/results/classifier/gemma3:12b/permissions/1726394 new file mode 100644 index 00000000..3847e6b6 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1726394 @@ -0,0 +1,6 @@ + +Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) + +qemu-user passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) unmodified, but the third argument is an address to a BPF filter, causing an EFAULT. Now, the filter is architecture-specifc, so you can't just rewrite the addresses, so the safest bet is to just return an error here. + +I guess you should just return EINVAL, but not sure. I'd really like something that can be identified, so seccomp errors can be ignored when it's not supported. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1731957 b/results/classifier/gemma3:12b/permissions/1731957 new file mode 100644 index 00000000..1e3570d4 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1731957 @@ -0,0 +1,37 @@ + +qemu-kvm exits with console permission problems + +# rpm -qa | grep qemu +qemu-img-ev-2.9.0-16.el7_4.8.1.x86_64 +qemu-kvm-ev-2.9.0-16.el7_4.8.1.x86_64 +ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch +libvirt-daemon-driver-qemu-3.2.0-14.el7_4.3.x86_64 +qemu-kvm-common-ev-2.9.0-16.el7_4.8.1.x86_64 + +qemu.conf: +stdio_handler = "file" + +libvirtd runs as root with '/usr/sbin/libvirtd --listen' + +we run openstack, it creates an instance like this: + +2017-11-13 15:17:14.143+0000: starting up libvirt version: 3.2.0, package: 14.el7_4.3 (Unknown, 2017-09-05-02:55:29, x86-ol7-builder +-02.us.oracle.com), qemu version: 2.9.0(qemu-kvm-ev-2.9.0-16.el7_4.8.1), hostname: compute6 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOME=/root QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name guest=instance-00000016,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-instance-00000016/master-key.aes -machine pc-i440fx-rhel7.4.0,accel=kvm,usb=off,dump-guest-core=off -cpu Haswell-noTSX,vme=on,ss=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc_adjust=on,xsaveopt=on,abm=on,invpcid=off -m 64 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=13.0.0,serial=de115ee2-a86f-432d-96fe-bec91b0a5748,uuid=48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-instance-00000016/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot + strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:bf:f5:40,bus=pci.0,addr=0x3 -chardev pty,id=charserial0,logfile=/var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83 +a2ffdf/console.log,logappend=off -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:1 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg +timestamp=on + +With older qemu like 2.5 or 2.6 console log belongs to qemu:qemu and the process starts successfully. +With 2.9 it fails and console.log is left root:root : + +2017-11-13 15:17:14.173+0000: 26010: debug : qemuProcessHook:2738 : Hook complete ret=0 +2017-11-13 15:17:14.173+0000: 26010: debug : virExec:699 : Done hook 0 +2017-11-13 15:17:14.173+0000: 26010: debug : virExec:736 : Setting child uid:gid to 42427:42427 with caps 0 +2017-11-13 15:17:14.173+0000: 26010: debug : virCommandHandshakeChild:435 : Notifying parent for handshake start on 29 +2017-11-13 15:17:14.173+0000: 26010: debug : virCommandHandshakeChild:443 : Waiting on parent for handshake complete on 30 +2017-11-13 15:17:14.192+0000: 26010: debug : virFileClose:110 : Closed fd 29 +2017-11-13 15:17:14.192+0000: 26010: debug : virFileClose:110 : Closed fd 30 +2017-11-13 15:17:14.192+0000: 26010: debug : virCommandHandshakeChild:463 : Handshake with parent is done +2017-11-13T15:17:14.232713Z qemu-kvm: -chardev pty,id=charserial0,logfile=/var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf/console.log,logappend=off: Unable to open logfile /var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf/console.log: Permission denied +2017-11-13 15:17:14.321+0000: shutting down, reason=failed \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1749393 b/results/classifier/gemma3:12b/permissions/1749393 new file mode 100644 index 00000000..7691bbae --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1749393 @@ -0,0 +1,27 @@ + +sbrk() not working under qemu-user with a PIE-compiled binary? + +In Debian unstable, we recently switched bash to be a PIE-compiled binary (for hardening). Unfortunately this resulted in bash being broken when run under qemu-user (for all target architectures, host being amd64 for me). + +$ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash +bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated) + +bash has its own malloc implementation based on sbrk(): +https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c + +When we disable this internal implementation and rely on glibc's malloc, then everything is fine. But it might be that glibc has a fallback when sbrk() is not working properly and it might hide the underlying problem in qemu-user. + +This issue has also been reported to the bash upstream author and he suggested that the issue might be in qemu-user so I'm opening a ticket here. Here's the discussion with the bash upstream author: +https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080 + +You can find the problematic bash binary in that .deb file: +http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb + +The version of qemu I have been using is 2.11 (Debian package qemu-user-static version 1:2.11+dfsg-1) but I have had reports that the problem is reproducible with older versions (back to 2.8 at least). + +Here are the related Debian bug reports: +https://bugs.debian.org/889869 +https://bugs.debian.org/865599 + +It's worth noting that bash used to have this problem (when compiled as a PIE binary) even when run directly but then something got fixed in the kernel and now the problem only appears when run under qemu-user: +https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1757 b/results/classifier/gemma3:12b/permissions/1757 new file mode 100644 index 00000000..fcd9ed53 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1757 @@ -0,0 +1,2 @@ + +guest-agent: improve help for --allow-rpcs and --block-rpcs diff --git a/results/classifier/gemma3:12b/permissions/1763 b/results/classifier/gemma3:12b/permissions/1763 new file mode 100644 index 00000000..186bb3e7 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1763 @@ -0,0 +1,13 @@ + +ldd fails with qemu-aarch64 +Description of problem: +see the original issue for full details https://github.com/multiarch/qemu-user-static/issues/172 +Steps to reproduce: +1. docker run --rm -it arm64v8/ubuntu:16.04 ldd /bin/ls + +Also possible on other newer OSs (eg: Ubuntu:18.04) with different compiled binaries. +Additional information: +``` +WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested +ldd: exited with unknown exit code (139) +``` diff --git a/results/classifier/gemma3:12b/permissions/1779955 b/results/classifier/gemma3:12b/permissions/1779955 new file mode 100644 index 00000000..bc711e54 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1779955 @@ -0,0 +1,31 @@ + +qemu linux-user requires read permissions on memory passed to syscalls that should only need write access + +When read() function takes an mmap'ed address as output buffer, it returns EFAULT. The expected behavior is it should just work. + +The following code works for qemu-system-arm, but not for qemu-arm-static. + + + +Steps to reproduce (please substitute /path/to/qemu-arm-static with the path of the binary, and /tmp/a.cpp with the example source code attached): + +# First register binfmt_misc +[hidden]$ docker run --rm --privileged multiarch/qemu-user-static:register --reset + +# Compile the code and run +[hidden]$ docker run --rm -it -v /tmp/a.cpp:/tmp/a.cpp -v /path/to/qemu-arm-static:/usr/bin/qemu-arm-static arm32v7/ubuntu:18.04 bash -c '{ apt update -y && apt install -y g++; } >& /dev/null && g++ -std=c++14 /tmp/a.cpp -o /tmp/a.out && echo hehe > /tmp/haha.txt && /tmp/a.out' +ofd=3 +ftruncate=0 +mmap=0xff3f5000 +fd=4 +0xff3f5023 -1 14 + + + +The expected result in qemu-system-arm as well as natively on x86_64 host: +hidden$ ./a.out +ofd=3 +ftruncate=0 +mmap=0xb6fb7000 +fd=4 +0xb6fb7023 5 0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1782107 b/results/classifier/gemma3:12b/permissions/1782107 new file mode 100644 index 00000000..8969181b --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1782107 @@ -0,0 +1,12 @@ + +Random errors when emulating armv7 and using dh + +Howdy, +I'm encountering random errors when using qemu to cross-package my project using dh. In previous iterations of my project it would only fail once every two attempts. Now it fails every time. + +Example error included. + + + +If you'd like to try and replicate this error, a version of my project is publicly available with simple instructions on how to package it (using qemu) here: +https://github.com/Nadav-Ruskin/configsite \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1790260 b/results/classifier/gemma3:12b/permissions/1790260 new file mode 100644 index 00000000..ed6ca1b2 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1790260 @@ -0,0 +1,12 @@ + +binfmt support not working for x86 host and x86_64 guest + +this is a problem in the qemu-binfmt-conf.sh script and maybe somewhere else. the version i checked is the current github mirror https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh + +i am running linux mint 19 32bit on a 32bit x86 cpu and i want to run some applications that are only available as x86_64 packages. i use multiarch and qemu and it works for simple applications like cacafire. however i want to run the application natively from the shell without having to use qemu-x86_64 <path>. i also installed the binfmt-support package. when i run update-binfmts --display then an extry for x86_64 is missing and transparent execution is not working. + +the problem seems to be in the qemu-binfmt-conf.sh script. it disables the creation of entries for cpus of the same family. this is not a problem if you are using a 64bit cpu because 32bit binaries run on it natively but it doesnt work in the opposite way. hacking line 310 to + + if [ "$cpu" = "x86_64" ] || [ "$host_family" != "$family" ] ; then + +and running it with the --systemd ALL parameter causes a x86_64 config file to be created. it still doesnt work but that might have different causes. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1810400 b/results/classifier/gemma3:12b/permissions/1810400 new file mode 100644 index 00000000..9d6ebc5b --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1810400 @@ -0,0 +1,33 @@ + + Failed to make dirty bitmaps writable: Can't update bitmap directory: Operation not permitted + +blockcommit does not work if there is dirty block. + +virsh version +Compiled against library: libvirt 4.10.0 +Using library: libvirt 4.10.0 +Using API: QEMU 4.10.0 +Running hypervisor: QEMU 2.12.0 + +Scenario: +1. Create an instance +2. Add dirty bitmap to vm disk. +3. create a snapshot(external or internal) +4. revert snapshot or blockcommit disk + +virsh blockcommit rota-test vda --active +Active Block Commit started + +virsh blockjob rota-test vda --info +No current block job for vda + + +rota-test.log: + starting up libvirt version: 4.10.0, package: 1.el7 (CBS <email address hidden>, 2018-12-05-12:27:12, c1bk.rdu2.centos.org), qemu version: 2.12.0qemu-kvm-ev-2.12.0-18.el7_6.1.1, kernel: 4.1.12-103.9.7.el7uek.x86_64, hostname: vm-kvm07 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name guest=rota-test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-101-rota-test/master-key.aes -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off -cpu SandyBridge,hypervisor=on,xsaveopt=on -m 8192 -realtime mlock=off -smp 3,sockets=3,cores=1,threads=1 -uuid 50dec55c-a80a-4adc-a788-7ba23230064e -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=59,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/rota-0003,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -netdev tap,fd=61,id=hostnet0,vhost=on,vhostfd=62 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e8:09:94,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5902,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on +2019-01-03T07:50:43.810142Z qemu-kvm: -chardev pty,id=charserial0: char device redirected to /dev/pts/3 (label charserial0) +main_channel_link: add main channel client +red_qxl_set_cursor_peer: +inputs_connect: inputs channel client create +inputs_channel_detach_tablet: +#block339: Failed to make dirty bitmaps writable: Can't update bitmap directory: Operation not permitted \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1817846 b/results/classifier/gemma3:12b/permissions/1817846 new file mode 100644 index 00000000..6d4f603b --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1817846 @@ -0,0 +1,47 @@ + +Qemu 3.1 Aarch64 TLBI VAE1, x0 + +Hello, + +In my code I'm trying to remove some permissions to a 4KiB MMU descriptor. After that I invalidate the MMU with + +TLBI VAE1, x0 + +where x0 is the start of the address of the 4 KiB page. + +In Qemu 2.12 this did not work, but I worked around it with: + + + /* invalidate the address */ + TLBI VAE1, x0 + + + /*****************************************************************/ + /*****************************************************************/ + /* NOTE: THIS IS A TRICK FOR QEMU!!!!!!!!!!!! */ + /* Apparently we have to change the TTBR0_EL1 when we change a descriptor (especially to remove permissions) */ + /* Otherwise qemu (2.12) will continue with the same descriptor with permissions! **/ + /*****************************************************************/ + /*****************************************************************/ + + /* do a trick (in qemu) */ + mrs x1 , TTBR0_EL1 + + ldr x2 , =kernelTable0Table + + msr TTBR0_EL1 , x2 + + isb + + msr TTBR0_EL1 , x1 + + /* return from function */ + ret + + +That is, I just replaced the TTBR0_EL1 with a temporary value, and then restored it. (guess qemu 2.12 just needed to reload the values again). + +However, even this procedure is not working with qemu 3.1. (I just tested again with qemu 2.12 and the code works fine, with qemu 3.1 it does not). + +Thanks, +Pharos team \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1819 b/results/classifier/gemma3:12b/permissions/1819 new file mode 100644 index 00000000..2b13611c --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1819 @@ -0,0 +1,11 @@ + +segmentation fault for rpm -qa command on centos:centos7 linux/arm/v7 architecture for docker container in shell. +Description of problem: + +Steps to reproduce: +1. docker pull centos:centos7@sha256:6887440ab977f751d6675157b73e42428d8ac05cf244c5d09ba036cc22d40d13 //pull an image centos:centos7 linux/arm/v7 tag +2. docker run -it b22fdcc90005 //docker run in interactive mode just pulled image +3. on shell run command -\> rpm -qa. +4. docker run -it b22fdcc90005 + + WARNING: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/amd64) and no specific platform was requested \[root@e23bc92686e8 /\]# rpm -qa Segmentation fault (core dumped) diff --git a/results/classifier/gemma3:12b/permissions/1825311 b/results/classifier/gemma3:12b/permissions/1825311 new file mode 100644 index 00000000..b8fd0e4d --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1825311 @@ -0,0 +1,4 @@ + +mips_cpu_handle_mmu_fault renders all accessed pages executable + +On MIPS, data accesses to pages mapped in the TLB result in mips_cpu_handle_mmu_fault() marking the page unconditionally executable, even if the TLB entry has the XI bit set. Later on, when there is an attempt to execute this page, no exception is generated, even though TLBXI is expected. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1825452 b/results/classifier/gemma3:12b/permissions/1825452 new file mode 100644 index 00000000..2783d761 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1825452 @@ -0,0 +1,26 @@ + +Pulse audio backend doesn't work in v4.0.0-rc4 release + +Using Gentoo linux, build from source: qemu v4.0.0-rc4 release (eeba63fc7fface36f438bcbc0d3b02e7dcb59983) + +Pulse audio backend doesn't initialize because of the: +audio/paaudio.c: +- if (!popts->has_server) { +- char pidfile[64]; +- char *runtime; +- struct stat st; +- +- runtime = getenv("XDG_RUNTIME_DIR"); +- if (!runtime) { +- return NULL; +- } +- snprintf(pidfile, sizeof(pidfile), "%s/pulse/pid", runtime); +- if (stat(pidfile, &st) != 0) { +- return NULL; +- } +- } +XDG_RUNTIME_DIR is not set for me. There is no /run/user directory exist in my system. + +Also: +$ less ~/.pulse/client.conf +default-server = unix:/home/ivan/.pulse_server \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1832916 b/results/classifier/gemma3:12b/permissions/1832916 new file mode 100644 index 00000000..18ff6dd9 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1832916 @@ -0,0 +1,6 @@ + +linux-user does not check PROT_EXEC + +At no point do we actually verify that a page is PROT_EXEC before translating. All we end up verifying is that the page is readable. Not the same thing, obviously. + +The following test case should work for any architecture, though I've only validated it for x86_64 and aarch64. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1836763 b/results/classifier/gemma3:12b/permissions/1836763 new file mode 100644 index 00000000..dea3ac01 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1836763 @@ -0,0 +1,96 @@ + +Firebird crashes on qemu-m68k-user with pthread_mutex_init error + +Trying to use the Firebird database on qemu-m68k-user with a Debian chroot fails with the database crashing with "ConfigStorage: mutex pthread_mutex_init error, status = 95": + +(sid-m68k-sbuild)root@epyc:/# apt install firebird3.0-server +Reading package lists... Done +Building dependency tree +Reading state information... Done +The following packages were automatically installed and are no longer required: + cpio libip4tc0 +Use 'apt autoremove' to remove them. +The following additional packages will be installed: + firebird3.0-common firebird3.0-common-doc firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util +Suggested packages: + firebird3.0-doc +The following NEW packages will be installed: + firebird3.0-common firebird3.0-common-doc firebird3.0-server firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util +0 upgraded, 7 newly installed, 0 to remove and 4 not upgraded. +Need to get 4,051 kB of archives. +After this operation, 15.9 MB of additional disk space will be used. +Do you want to continue? [Y/n] +Get:1 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common-doc all 3.0.5.33100.ds4-3 [35.3 kB] +Get:2 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common all 3.0.5.33100.ds4-3 [14.5 kB] +Get:3 http://ftp.ports.debian.org/debian-ports unstable/main m68k libfbclient2 m68k 3.0.5.33100.ds4-3 [496 kB] +Get:4 http://ftp.ports.debian.org/debian-ports unstable/main m68k libib-util m68k 3.0.5.33100.ds4-3 [3,220 B] +Get:5 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server-core m68k 3.0.5.33100.ds4-3 [2,368 kB] +Get:6 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-utils m68k 3.0.5.33100.ds4-3 [770 kB] +Get:7 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server m68k 3.0.5.33100.ds4-3 [365 kB] +Fetched 4,051 kB in 2s (1,803 kB/s) +debconf: delaying package configuration, since apt-utils is not installed +E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device) +Selecting previously unselected package firebird3.0-common-doc. +(Reading database ... 33605 files and directories currently installed.) +Preparing to unpack .../0-firebird3.0-common-doc_3.0.5.33100.ds4-3_all.deb ... +Unpacking firebird3.0-common-doc (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-common. +Preparing to unpack .../1-firebird3.0-common_3.0.5.33100.ds4-3_all.deb ... +Unpacking firebird3.0-common (3.0.5.33100.ds4-3) ... +Selecting previously unselected package libfbclient2:m68k. +Preparing to unpack .../2-libfbclient2_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking libfbclient2:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package libib-util:m68k. +Preparing to unpack .../3-libib-util_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking libib-util:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-server-core:m68k. +Preparing to unpack .../4-firebird3.0-server-core_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-utils. +Preparing to unpack .../5-firebird3.0-utils_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-utils (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-server. +Preparing to unpack .../6-firebird3.0-server_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-server (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-common-doc (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-common (3.0.5.33100.ds4-3) ... +Setting up libib-util:m68k (3.0.5.33100.ds4-3) ... +Setting up libfbclient2:m68k (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-utils (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-server (3.0.5.33100.ds4-3) ... +debconf: unable to initialize frontend: Dialog +debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) +debconf: falling back to frontend: Readline +Password for firebird 3.0 +------------------------- + +Firebird has a special user named SYSDBA, which is the user that has access to all databases. SYSDBA can also create new databases and users. Because of this, it is +necessary to secure SYSDBA with a password. + +The password is stored in /etc/firebird/3.0/SYSDBA.password (readable only by root). You may modify it there (don't forget to update the security database too, using the +gsec utility), or you may use dpkg-reconfigure to update both. + +If you don't enter a password, a random one will be used (and stored in SYSDBA.password). + +Password for SYSDBA: + +adduser: Warning: The home directory `/var/lib/firebird' does not belong to the user you are currently creating. +ConfigStorage: mutex pthread_mutex_init error, status = 95 +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +dpkg: error processing package firebird3.0-server (--configure): + installed firebird3.0-server package post-installation script subprocess returned error exit status 134 +Processing triggers for systemd (241-6+b2) ... +Processing triggers for man-db (2.8.5-2) ... +Not building database; man-db/auto-update is not 'true'. +Processing triggers for libc-bin (2.28-10+qemu) ... +Errors were encountered while processing: + firebird3.0-server +E: Sub-process /usr/bin/dpkg returned an error code (1) +(sid-m68k-sbuild)root@epyc:/# SEC_SQL=/usr/share/firebird/3.0/security.sql T=/tmp/tmp.2kBDCgAevm T_SEC=/tmp/tmp.2kBDCgAevm/security.fdb isql-fb -q +SQL> create database '/tmp/tmp.2kBDCgAevm/security.fdb'; +ConfigStorage: mutex pthread_mutex_init error, status = 95 +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +(sid-m68k-sbuild)root@epyc:/# \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1838066 b/results/classifier/gemma3:12b/permissions/1838066 new file mode 100644 index 00000000..b94ecc0a --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1838066 @@ -0,0 +1,25 @@ + +unexpected error: raw_reconfigure_getfd(): qemu-system-x86_64: Could not reopen file + + Unexpected error in raw_reconfigure_getfd() at block/file-posix.c:923: + qemu-system-x86_64: Could not reopen file: Permission denied + Aborted + +Is what i sometimes (only) get, mostly for Linux guests i'd say (Arch just a few moments ago). +This is on CRUX-Linux, thus a self-compiled qemu 4.0.0 with default recipe, without special compiler flags (-O2 -march=x86-64 -pipe) on an Intel i5 laptop. +But what i do is running this via sudo: + + sudo='sudo --preserve-env=VMNAME,VMADDR' runas='-runas vm -chroot .' + fi + + VMADDR=$addr VMNAME=$vmname + export VMADDR VMNAME + eval exec $sudo qemu-system-x86_64 -name $vmname $runas \ + $host $accel $display $net $vmcustom $vmimg $redir + +the last run ends up like (via sudo) + + qemu-system-x86_64 -name arch-2019 -runas vm -chroot . -cpu host -m size=1984 -smp cpus=2 -enable-kvm -accel accel=kvm,thread=multi -display curses -net nic,netdev=net0,macaddr=.. -netdev tap,id=net0,script=./.ifup.sh,downscript=./.ifdown.sh,ifname=vm_arch-2019 + +vm is a user effectively living in the chroot only without any rights anywhere. +Hope this helps, thanks a lot for qemu!! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1854878 b/results/classifier/gemma3:12b/permissions/1854878 new file mode 100644 index 00000000..b6400474 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1854878 @@ -0,0 +1,33 @@ + +Physical USB thumbdrive treated as read-only + +So I have installed FreeDOS on my USB thumbdrive, by using Rufus. Everything goes as expected so far. That's good. + +When I run QEMU with this command line: +qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1 + +it of course is read-only, just like the resulting console message says: +WARNING: Image format was not specified for '\\.\PhysicalDrive1' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + + +So what I then did, was I ran QEMU with this command line: +qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw + +As expected, the above mentioned console message no longer appears. +However, beyond that, QEMU doesn't behave as it should regarding read-only status. When I try any operation that involves writing to the drive, it becomes quite clear that the drive is still read-only. Any writing operations to the drive result in FreeDOS giving me the error message: +Error writing to drive C: DOS area: sector not found. + +The above situation is clearly a bug. QEMU should not be treating it as read-only once I specify format=raw. + +Note that drive C is how the guest OS refers to the USB thumbdrive (it's drive E in my host OS, and drive C in my host OS is the actual system drive). + +And yes, it is a QEMU bug. It's not a FreeDOS bug I tested it with this command line, so that all changes would be written to a temporary snapshot file: +qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw,snapshot +That last drive option "snapshot" tells QEMU to create a temporary snapshot file, and to write all changes to that. When I do that, all write operations are successful. So it seems that there is a bug in QEMU where it keeps read-only mode in place for a physical drive, even when format=raw is specified. Please fix this bug. Thanks in advance. + +Here's my current setup. +Host OS: Windows 10 (64bit) +Guest OS: FreeDOS +QEMU version: 4.1.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1875139 b/results/classifier/gemma3:12b/permissions/1875139 new file mode 100644 index 00000000..9d4594cb --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1875139 @@ -0,0 +1,20 @@ + +Domain fails to start when 'readonly' device not writable + +This issue is introduced in QEMU 4.2.0 (4.1.0 is working fine) + +My root disk is a LVM2 volume thin snapshot that is marked as read-only +But when I try to start the domain (using virt-manager) I get the following error: + +Error starting domain: internal error: process exited while connecting to monitor: 2020-04-26T06:55:06.342700Z qemu-system-x86_64: -blockdev {"driver":"host_device","filename":"/dev/vg/vmroot-20200425","aio":"native","node-name":"libvirt-3-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} The device is not writable: Permission denied + +Changing the lvm snapshot to writeable allows me to start the domain. +(Making it changes possible during domain is running) + +I don't think QEMU should fail when it can't open a (block) device when the read-only option is set. +(why is write access needed?) + +Reproduce steps: +* Create LVM read-only volume (I don't think any data is needed) +* Create domain with read-only volume as block device +* Try to start the domain \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1880518 b/results/classifier/gemma3:12b/permissions/1880518 new file mode 100644 index 00000000..7aa97ed9 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1880518 @@ -0,0 +1,17 @@ + +issue while installing docker inside s390x container + +This is in reference to https://github.com/multiarch/qemu-user-static/issues/108. +I am facing issue while installing docker inside s390x container under qemu on Ubuntu 18.04 host running on amd64. +Following are the contents of /proc/sys/fs/binfmt_misc/qemu-s390x on Intel host after running +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +enabled +interpreter /usr/bin/qemu-s390x-static +flags: F +offset 0 +magic 7f454c4602020100000000000000000000020016 +mask ffffffffffffff00fffffffffffffffffffeffff +I could get docker service up with the following trick. +printf '{"iptables": false,"ip-masq": false,"bridge": "none" }' > /etc/docker/daemon.json +But even though docker service comes up, images are not getting pulled, docker pull fails with the following error. +failed to register layer: Error processing tar file(exit status 1): \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1884719 b/results/classifier/gemma3:12b/permissions/1884719 new file mode 100644 index 00000000..3798d87e --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1884719 @@ -0,0 +1,133 @@ + +Function not implemented when using libaio + +Hello + +I experience "Function not implemented" errors when trying to use Linux libaio library in foreign architecture, e.g. aarch64. + +I've faced this problem while using https://github.com/multiarch/qemu-user-static, i.e. Docker+QEMU. +I understand that I do not use plain QEMU and you may count this report as a "distribution of QEMU"! Just let me know what are the steps to test it with plain QEMU and I will test and update this ticket! + + +Here are the steps to reproduce the issue: + +1) On x86_64 machine register QEMU: + + `docker run -it --rm --privileged multiarch/qemu-user-static --reset --credential yes --persistent yes` + +2) Start a Docker image with foreign CPU architecture, e.g. aarch64 + + `docker run -it arm64v8/centos:8 bash` + +3) Inside the Docker container install GCC and libaio + + `yum install gcc libaio libaio-devel` + +4) Compile the following C program + +``` +#include <stdio.h> +#include <errno.h> +#include <libaio.h> +#include <stdlib.h> + +struct io_control { + io_context_t ioContext; +}; + +int main() { + int queueSize = 10; + + struct io_control * theControl = (struct io_control *) malloc(sizeof(struct io_control)); + if (theControl == NULL) { + printf("theControl is NULL"); + return 123; + } + + int res = io_queue_init(queueSize, &theControl->ioContext); + io_queue_release(theControl->ioContext); + free(theControl); + printf("res is: %d", res); +} +``` + + ``` + cat > test.c + [PASTE THE CODE ABOVE HERE] + ^D + ``` + + `gcc test.c -o out -laio && ./out` + + +When executed directly on aarch64 machine (i.e. without emulation) or on x86_64 Docker image (e.g. centos:8) it prints `res is: 0`, i.e. it successfully initialized a LibAIO queue. + +But when executed on Docker image with foreign/emulated CPU architecture it prints `res is: -38` (ENOSYS). `man io_queue_init` says that error ENOSYS is returned when "Not implemented." + +Environment: + +QEMU version: 5.0.0.2 (https://github.com/multiarch/qemu-user-static/blob/master/.travis.yml#L24-L28) +Container application: Docker +Output of `docker --version`: + +``` +Client: + Version: 19.03.8 + API version: 1.40 + Go version: go1.13.8 + Git commit: afacb8b7f0 + Built: Wed Mar 11 23:42:35 2020 + OS/Arch: linux/amd64 + Experimental: false + +Server: + Engine: + Version: 19.03.8 + API version: 1.40 (minimum version 1.12) + Go version: go1.13.8 + Git commit: afacb8b7f0 + Built: Wed Mar 11 22:48:33 2020 + OS/Arch: linux/amd64 + Experimental: false + containerd: + Version: 1.3.3-0ubuntu2 + GitCommit: + runc: + Version: spec: 1.0.1-dev + GitCommit: + docker-init: + Version: 0.18.0 + GitCommit: +``` + +Same happens with Ubuntu (arm64v8/ubuntu:focal). + +I've tried to `strace` it but : + +``` +/usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented +/usr/bin/strace: PTRACE_SETOPTIONS: Function not implemented +/usr/bin/strace: detach: waitpid(112): No child processes +/usr/bin/strace: Process 112 detached +``` + +Here are the steps to reproduce the problem with strace: + + ``` + docker run --rm -it --security-opt seccomp:unconfined --security-opt apparmor:unconfined --privileged --cap-add ALL arm64v8/centos:8 bash + + yum install -y strace` + + strace echo Test + ``` + +Note: I used --privileged, disabled seccomp and apparmor, and added all capabilities + +Disabling security solves the "Permission denied" problem but then comes the "Not implemented" one. + + +Any idea what could be the problem and how to work it around ? +I've googled a lot but I wasn't able to find any problems related to libaio on QEMU. + +Thank you! +Martin \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1886097 b/results/classifier/gemma3:12b/permissions/1886097 new file mode 100644 index 00000000..31822960 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1886097 @@ -0,0 +1,34 @@ + +Error in user-mode calculation of ELF program's brk + +There's a discrepancy between the way QEMU user-mode and Linux calculate the initial program break for statically-linked binaries. I have a binary with the following segments: + + Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x065a14 0x00075a14 0x00075a14 0x00588 0x00588 R 0x4 + PHDR 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 + LOAD 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 + LOAD 0x000000 0x00010000 0x00010000 0x65fa0 0x65fa0 R E 0x10000 + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x8 + GNU_RELRO 0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R 0x1 + LOAD 0x07e000 0x00089000 0x00089000 0x03ff4 0x03ff4 R E 0x1000 + LOAD 0x098000 0x00030000 0x00030000 0x01000 0x01000 RW 0x1000 + +The call to set_brk in Linux's binfmt_elf.c receives these arguments: + + set_brk(0xa3160, 0xa3160, 1) + +Whereas in QEMU, info->brk gets set to 0x88f00. When the binary is run in QEMU, it crashes on the second call to brk, whereas it runs fine on real ARM hardware. I think the trouble is that the program break is set to an address lower than the virtual address of a LOAD segment (the program headers, in this case). + +I believe that this discrepancy arises because in QEMU, info->brk is only incremented when the LOAD segment in question has PROT_WRITE. For this binary, the LOAD segment with write permissions and the highest virtual address is + + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + +which overlaps with the TLS segment: + + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + +However, the Linux kernel puts the program break after the loadable segment with the highest virtual address, regardless of flags. So I think the fix is for QEMU to do the same. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1889033 b/results/classifier/gemma3:12b/permissions/1889033 new file mode 100644 index 00000000..302eafcf --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1889033 @@ -0,0 +1,95 @@ + +qemu-img permission denied on vmdk creation on CIFS share + + +- on a CIFS mount qemu-img claims not to have permissions to write into a file. +- VMDK sparse file creation succeeds +- VMDK Flat file creation create the flat-file, but fails to write the description-file +- VMDK flat file creation succeeds on native linux mount such as ~/tmp or /tmp +- same effect as root or non-root +- same effect with selinux setenforce 0 + +a) I would have expected that the monolithic flat would have created only one large file just like sparse, but it seems to create a description file, in addition to the storing file. +b) I am aware that qemu-img may have problem opening very large files on CIFS, however, this file is not very large + +Windows-10 latest updated 2004 19041.388 +Linux VM, Fedora-32 in Virtualbox 6.1.12 +# rpm -qa | grep qemu-img +qemu-img-4.2.0-7.fc32.x86_64 + +mount options: +mount -t cifs //10.x,x,x/$shname /mnt/hshare -o defaults,username=gana,rw,uid=1000,gid=1000,vers=3.0 + +[root@fedora ~]# cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +qemu-img: test1.vmdk: Could not write description: Permission denied +[root@fedora createvmdk]# ls -l test1*.* +-rwxr-xr-x. 1 gana gana 104857600 Jul 26 23:02 test1-flat.vmdk +-rwxr-xr-x. 1 gana gana 0 Jul 26 23:02 test1.vmdk +[root@fedora createvmdk]# du -k test1*.* +0 test1-flat.vmdk +0 test1.vmdk +# (doesn't seem to be really flat) + +creation in /tmp works +# cd /tmp +[root@fedora tmp]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +[root@fedora tmp]# ls -l /tmp/test1*.* +-rw-r--r--. 1 root root 104857600 Jul 26 22:43 /tmp/test1-flat.vmdk +-rw-r--r--. 1 root root 313 Jul 26 22:43 /tmp/test1.vmdk +[root@fedora createvmdk]# du -k /tmp/test1*.* +4 /tmp/test1-flat.vmdk +4 /tmp/test1.vmdk + +[root@fedora createvmdk]# cat /tmp/test1.vmdk +# Disk DescriptorFile +version=1 +CID=5f13c13d +parentCID=ffffffff +createType="monolithicFlat" + +# Extent description +RW 204800 FLAT "test1-flat.vmdk" 0 + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" + + +On the other-hand creating a sparse file works +cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test2.vmdk 100M -o subformat=monolithicSparse +Formatting 'test2.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicSparse +[root@fedora createvmdk]# ls l test2*.* +-rwxr-xr-x. 1 gana gana 65536 Jul 26 22:52 test2.vmdk +[root@fedora createvmdk]# du -k /tmp/test2*.* +12 /tmp/test2.vmdk + +test2.vmdk is a binary file +inside it, located among garbled ascii characters is an embedded VMDK description +```` +# Disk DescriptorFile +version=1 +CID=cf302a20 +parentCID=ffffffff +createType="monolithicSparse" + +# Extent description +RW 204800 SPARSE "test2.vmdk" + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1890 b/results/classifier/gemma3:12b/permissions/1890 new file mode 100644 index 00000000..5f0eb282 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1890 @@ -0,0 +1,26 @@ + +qemu-arm 8.1.0 Error mapping file: Operation not permitted +Description of problem: +failed to execute the cortex-m binary hello_world, and says: +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +Steps to reproduce: +1. +``` +cat > hello_new.c <<EOF +#include <stdio.h> +int main() +{printf("hello world"); return 0;} +EOF +``` +2. +``` +arm-none-eabi-gcc -mcpu=cortex-m55 -g hello_world.c -o hello_world -specs=rdimon.specs +``` +3. +``` +qemu-arm -cpu cortex-m55 hello_world +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +``` +Additional information: +1, version 8.0.4 version is okay\ +2, arm-none-eabi-gcc version is 10.3.1 20210824 (release) diff --git a/results/classifier/gemma3:12b/permissions/1891748 b/results/classifier/gemma3:12b/permissions/1891748 new file mode 100644 index 00000000..f52d0552 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1891748 @@ -0,0 +1,15 @@ + +qemu-arm-static 5.1 can't run gcc + +Issue discovered while trying to build pikvm (1) + +Long story short: when using qemu-arm-static 5.1, gcc exits whith message: + +Allocating guest commpage: Operation not permitted + + +when using qemu-arm-static v5.0, gcc "works" + +Steps to reproduce will follow + +(1) https://github.com/pikvm/pikvm/blob/master/pages/building_os.md \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1892581 b/results/classifier/gemma3:12b/permissions/1892581 new file mode 100644 index 00000000..e904367e --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1892581 @@ -0,0 +1,43 @@ + +QEMU 5.1 no longer says anything about inaccessible devices + +Previously, with QEMU 5.0.0 running a VM with the following command: + +$ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb-ehci,id=ehci -device usb-host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio + +Would display something like the following: + +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied +libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied +libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. + +With insufficient permissions. + +QEMU 5.1.0 no longer displays anything. + +I did a git bisect and this is the result: + +[diego@thinkpad qemu]$ git bisect bad +9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit +commit 9f815e83e983d247a3cd67579d2d9c1765adc644 +Author: Gerd Hoffmann <email address hidden> +Date: Fri Jun 5 14:59:52 2020 +0200 + + usb: add hostdevice property to usb-host + + The new property allows to specify usb host device name. Uses standard + qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) + and file descriptor passing can be used. + + Requires libusb 1.0.23 or newer. The hostdevice property is only + present in case qemu is compiled against a new enough library version, + so the presence of the property can be used for feature detection. + + Signed-off-by: Gerd Hoffmann <email address hidden> + Message-Id: <email address hidden> + + hw/usb/host-libusb.c | 75 ++++++++++++++++++++++++++++++++++++++++++---------- + hw/usb/trace-events | 1 + + 2 files changed, 62 insertions(+), 14 deletions(-) +[diego@thinkpad qemu]$ \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1903833 b/results/classifier/gemma3:12b/permissions/1903833 new file mode 100644 index 00000000..bc5f97ff --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1903833 @@ -0,0 +1,12 @@ + +User mode qemu-aarch: SIGGSEGV signal handler works wrong + +I have a user mode qemu-aarch issue. Program with SIGSEGV signal handler works wrong under qemu-aarch: +once the progam handles the SEGV signal, qemu marks the program's page protected, and signal handler gets SEGV on each subsequent memory access instruction within a program. + +The issue is reproduced on WSL Ubuntu 20.04 under Windows 10, qemu-aarch64 version 5.1.50 +The issue is also reproducible on the latest upstream qemu-aarch build. + +The following workaround disables mprotect call and fixes the issue: https://github.com/BorisUlasevich/qemu/commit/3063d9a64f8395185d65c6b6710d28ee92cd8be5 + +The issue can be reproduced on OpenJDK which reports SIGSEGV immediately after start. The small reproducer program is attached. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1912107 b/results/classifier/gemma3:12b/permissions/1912107 new file mode 100644 index 00000000..6dbc2897 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1912107 @@ -0,0 +1,9 @@ + +Option to constrain linux-user exec() to emulated CPU only + +When trying to reproduce a bug someone reported on an actual AMD K10[1], I tried to directly throw `qemu_x86-64 -cpu +phenom path/to/wrongly-labelled-instruction-set/gcc 1.c` at the problem, but failed to get an "illegal instruction" as expected. A quick investigation reveals that the error is actually caused by one of gcc's child processess, and that the said process is being ran directly on the host. A similar problem happens with trying to call stuff with /usr/bin/env. + + [1]: https://github.com/Homebrew/brew/issues/1034 + +Since both the host and the guest are x86_64, I deemed binfmt inapplicable to my case. I believe that QEMU should offer a way to modify exec() and other spawning syscalls so that execution remains on an emulated CPU in such a case. Call it an extra layer of binfmt, if you must. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1914849 b/results/classifier/gemma3:12b/permissions/1914849 new file mode 100644 index 00000000..f1561ecd --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1914849 @@ -0,0 +1,55 @@ + +mprotect fails after MacOS 11.2 on arm mac + +I got the following error when I ran qemu on arm mac(MacOS 11.2). + +``` +$ ./qemu-system-x86_64 +qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied +** +ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +[1] 34898 abort ./qemu-system-x86_64 +``` + +I tested the same version of qemu on intel mac(MacOS 11.2), but it works fine. + +And my friend told me that they did not have this error with MacOS 11.1. + +So, I think it is CPU architecture or an OS version dependent error. + + +Environment: + +Qemu commit id: d0dddab40e472ba62b5f43f11cc7dba085dabe71 +OS: MacOS 11.2(20D64) +Hardware: MacBook Air (M1, 2020) + + +How to build: + +``` +mkdir build/ +cd build/ +../configure --target-list=aarch64-softmmu,x86_64-softmmu +make +``` + + +How to reproduce: + +``` +./qemu-system-x86_64 +``` + + +Error message: + +``` +$ ./qemu-system-x86_64 +qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied +** +ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +[1] 34898 abort ./qemu-system-x86_64 +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1918975 b/results/classifier/gemma3:12b/permissions/1918975 new file mode 100644 index 00000000..b6c1c656 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1918975 @@ -0,0 +1,6 @@ + +[Feature request] Propagate interpreter to spawned processes + +I want QEMU user static to propagate interpreter to spawned processes, for instances by adding -R recursive. + +I.e. if my program is interpreted by QEMU static than everything what it launches should be interpreted by it, too. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1922625 b/results/classifier/gemma3:12b/permissions/1922625 new file mode 100644 index 00000000..9f8acfa0 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1922625 @@ -0,0 +1,34 @@ + +qemu 5.2.0 configure script explodes when in read only directory + +I extracted the qemu 5.2.0 source as one user, and then tried to run `./configure --help` in that directory as a different user. Normal autoconf configure scripts have no problem with this but yours goes into an infinite loop printing nonsense: + +Using './build' as the directory for build output +mkdir: build: Permission denied +touch: build/auto-created-by-configure: No such file or directory +./configure: line 37: GNUmakefile: Permission denied +./configure: line 59: cd: build: No such file or directory +Using './build' as the directory for build output +mkdir: build: Permission denied +touch: build/auto-created-by-configure: No such file or directory +/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied +/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory +Using './build' as the directory for build output +mkdir: build: Permission denied +touch: build/auto-created-by-configure: No such file or directory +/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied +/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory +Using './build' as the directory for build output +mkdir: build: Permission denied +touch: build/auto-created-by-configure: No such file or directory +/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied +/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory +Using './build' as the directory for build output +mkdir: build: Permission denied +touch: build/auto-created-by-configure: No such file or directory +/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied +/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory +Using './build' as the directory for build output +mkdir: build: Permission denied + +etc. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1926246 b/results/classifier/gemma3:12b/permissions/1926246 new file mode 100644 index 00000000..0edb5e96 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1926246 @@ -0,0 +1,51 @@ + +chrome based apps can not be run under qemu user mode + +chrome uses /proc/self/exe to fork render process. +Here a simple code to reproduce the issue. It's output parent then child but failed with qemu: unknown option 'type=renderer'. + +Maybe we can modify exec syscall to replace /proc/self/exe to the real path. + +//gcc -o self self.c +#include <stdio.h> +#include <sys/types.h> +#include <unistd.h> +int main(int argc, char** argv) { + if(argc==1){ + printf ("parent\n"); + if ( fork() == 0 ) + { + return execl("/proc/self/exe","/proc/self/exe", "--type=renderer",NULL); + } + } else { + printf ("child\n"); + } + return 0; +} + +similar reports: +https://github.com/AppImage/AppImageKit/issues/965 +https://github.com/golang/go/issues/42080 + +Workardound: +compile chrome or your chrome based app with a patch to content/common/child_process_host_impl.cc:GetChildPath, get the realpath of /proc/self/exe: + +diff --git a/content/common/child_process_host_impl.cc b/content/common/child_process_host_impl.cc +index bc78aba80ac8..9fab74d3bae8 100644 +--- a/content/common/child_process_host_impl.cc ++++ b/content/common/child_process_host_impl.cc +@@ -60,8 +60,12 @@ base::FilePath ChildProcessHost::GetChildPath(int flags) { + #if defined(OS_LINUX) + // Use /proc/self/exe rather than our known binary path so updates + // can't swap out the binary from underneath us. +- if (child_path.empty() && flags & CHILD_ALLOW_SELF) +- child_path = base::FilePath(base::kProcSelfExe); ++ if (child_path.empty() && flags & CHILD_ALLOW_SELF) { ++ if (!ReadSymbolicLink(base::FilePath(base::kProcSelfExe), &child_path)) { ++ NOTREACHED() << "Unable to resolve " << base::kProcSelfExe << "."; ++ child_path = base::FilePath(base::kProcSelfExe); ++ } ++ } + #endif + + // On most platforms, the child executable is the same as the current \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/1951 b/results/classifier/gemma3:12b/permissions/1951 new file mode 100644 index 00000000..b431338b --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1951 @@ -0,0 +1,139 @@ + +MacOS requires root to pass through USB devices properly +Description of problem: +If I run qemu as a normal user, the PlutoSDR USB device will not work in the VM. For example, the umass device will remain attached to the host system, and will not appear in the guest system. The device will appear in the guest system, but it will fail to be configured: +``` +usb_alloc_device: Failure selecting configuration index 0:USB_ERR_STALLED, port 2, addr 2 (ignored) +``` + +I believe that similar issues are happening w/ guest OS's Ubuntu 20.04 and 22.04, but I have not tested them to confirm. + +There is no error message (that I noticed) that reports that this might be an issue and that you need to run qemu as root. +Steps to reproduce: +1. Run qemu like above +2. Plug in a PlutoSDR +3. See that the device appears in the guest, but does not attach completely +Additional information: +The confusing part is that a simple device, an RTL-SDR device will appear to work fine when passed through w/o running as root making things more confusing to debug. + +When run qemu as a normal user, the console (includes FreeBSD kernel messages: +``` +login: qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +usb_alloc_device: Failure selecting configuration index 0:USB_ERR_STALLED, port 2, addr 2 (ignored) +ugen1.2: <Analog Devices Inc. PlutoSDR (ADALM-PLUTO)> at usbus1 +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +``` + +It's not clear what action, if any needs to be taken w/ these error messages. At a minimum, qemu should complain loudly about needing to be run as root, but would be best if it didn't need to run as root, like other VM systems. + +If I run qemu as root (via sudo), it attachs as expected: +``` +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND] +ugen1.2: <Analog Devices Inc. PlutoSDR (ADALM-PLUTO)> at usbus1 +umass0 on uhub0 +umass0: <Mass Storage> on usbus1 +umass0: SCSI over Bulk-Only; quirks = 0x0000 +umass0:0:0: Attached to scbus0 +da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 +da0: <Linux File-Stor Gadget 0414> Removable Direct Access SCSI-2 device +da0: 40.000MB/s transfers +da0: 30MB (61441 512 byte sectors) +da0: quirks=0x2<NO_6_BYTE> +urndis0 on uhub0 +urndis0: <RNDIS Communications Control> on usbus1 +umodem0 on uhub0 +umodem0: <CDC Abstract Control Model (ACM)> on usbus1 +umodem0: data interface 4, has no CM over data, has no break +``` + +Trying root was inspired by: +https://github.com/libusb/libusb/issues/1014 + +From that issue, it appears that this is a qemu build issue and does not have the proper entitlements. diff --git a/results/classifier/gemma3:12b/permissions/1954 b/results/classifier/gemma3:12b/permissions/1954 new file mode 100644 index 00000000..e55a2133 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1954 @@ -0,0 +1,29 @@ + +guest-fsfreeze can't work well on windows +Description of problem: +I used qemu 5.0 to cross-compile windows gqa on the fedroa30 system.And install it on guest with windows10,but i can't work well. +Steps to reproduce: +1. ./configure --cross-prefix=x86_64-w64-mingw32- --enable-guest-agent-msi --with-vss-sdk=/root/vssdk/VSSSDK72 + + my vssdk download from:[vssdk](https://www.microsoft.com/en-us/download/details.aspx?id=23490),i install it on my pc and copy to /root/vssdk/VSSSDK72 + +2. make qemu-ga -j4 + +3. and then install qemu-ga-x86_64.msi on windows10,it report the error: +  + +4.then I ./configure not with "--with-vss-sdk",the qemu-ga-x86_64.msi can install successfully. + +5.So, I install gga first. Then ./configure with "--with-vss-sdk" to make get the qemu-ga.exe + +6.replace qemu-ga.exe and reboot gga service,then execute the command "virsh domfsfreeze" on host,but it report error: + + error: Unable to freeze filesystems + error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to add \\?\Volume{d1ee1072-0000-0000-0000-100000000000}\ to snapshot set: + + +**I looked at the windows Event Viewer,it get the error:** + + Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied. + +I have referred to this [document](https://www.ryadel.com/en/volume-shadow-copy-service-error-unexpected-error-querying-for-the-ivsswritercallback-interface-how-to-fix-that/),but it not work. diff --git a/results/classifier/gemma3:12b/permissions/1962 b/results/classifier/gemma3:12b/permissions/1962 new file mode 100644 index 00000000..6f151740 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/1962 @@ -0,0 +1,30 @@ + +systemd-tmpfiles-setup-dev-early.service fails in emulated systemd-nspawn container +Description of problem: +When booting a fresh `debootstrap`ed Debian Trixie/testing rootfs with foreign architecture via `systemd-nspawn` and `qemu-user-static`, invoked via `systemd-binfmt`, the `systemd-tmpfiles-setup-dev-early.service` service within the guest fails, which leads to `/dev` not existing (respectively no default content), so that several other guest system components fail as well, like any console/shell access: +``` +Starting systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully... +systemd-tmpfiles-setup-dev-early.service: Failed to set up credentials: Invalid argument +systemd-tmpfiles-setup-dev-early.service: Main process exited, code=exited, status=243/CREDENTIALS +systemd-tmpfiles-setup-dev-early.service: Failed with result 'exit-code'. +[FAILED] Failed to start systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully. +See 'systemctl status systemd-tmpfiles-setup-dev-early.service' for details. +Starting systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev... +systemd-tmpfiles-setup-dev.service: Failed to set up credentials: Invalid argument +systemd-tmpfiles-setup-dev.service: Main process exited, code=exited, status=243/CREDENTIALS +systemd-tmpfiles-setup-dev.service: Failed with result 'exit-code'. +[FAILED] Failed to start systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev. +See 'systemctl status systemd-tmpfiles-setup-dev.service' for details. +``` +Steps to reproduce: +1. `apt install debootstrap systemd-container qemu-user-static` +2. `systemctl restart systemd-binfmt` +3. `mkdir rootfs` +4. `debootstrap --variant=minbase --include=systemd-sysv --arch=arm64 trixie ./rootfs 'https://deb.debian.org/debian'` +5. `systemd-nspawn -bD rootfs` +Additional information: +On Bookworm guest systems and/or without QEMU emulation, this works without issues, so I guess systemd recently started to use a certain syscall for the `ImportCredential=tmpfiles.*` method in systemd units, which is not supported by QEMU, probably similar to https://github.com/systemd/systemd/pull/28954? + +I hope it is fine to report it here. Always difficult to decide whether to report to the distribution (Debian) or one, and in case which, of the related projects, which do not work together. + +Debian Trixie currently ships `systemd 254.4-1` btw. I am not sure whether the issue was introduced with 253 or 254, since the linked issue prevented booting such containers on an earlier stage with 253, which was fixed in 254, which has the here reported issue. diff --git a/results/classifier/gemma3:12b/permissions/2032 b/results/classifier/gemma3:12b/permissions/2032 new file mode 100644 index 00000000..665a8e91 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2032 @@ -0,0 +1,32 @@ + +qemu-guest-agent not starting +Description of problem: +Trace found in syslog : +``` +syslog:Dec 11 13:45:08 mail systemd[1]: dev-virtio\x2dports-org.qemu.guest_agent.0.device: Job dev-virtio\x2dports-org.qemu.guest_agent.0.device/start timed out. +syslog:Dec 11 13:45:08 mail systemd[1]: Timed out waiting for device /dev/virtio-ports/org.qemu.guest_agent.0. +syslog:Dec 11 13:45:08 mail systemd[1]: qemu-guest-agent.service: Job qemu-guest-agent.service/start failed with result 'dependency'. +syslog:Dec 11 13:45:08 mail systemd[1]: dev-virtio\x2dports-org.qemu.guest_agent.0.device: Job dev-virtio\x2dports-org.qemu.guest_agent.0.device/start failed with result 'timeout'. +``` +Steps to reproduce: +systemctl start qemu-guest-agent +Additional information: +Messages when installing the systemd unit : +``` +systemctl enable qemu-guest-agent +Synchronizing state of qemu-guest-agent.service with SysV service script with /lib/systemd/systemd-sysv-install. +Executing: /lib/systemd/systemd-sysv-install enable qemu-guest-agent +The unit files have no installation config (WantedBy=, RequiredBy=, Also=, +Alias= settings in the [Install] section, and DefaultInstance= for template +units). This means they are not meant to be enabled using systemctl. + +Possible reasons for having this kind of units are: +• A unit may be statically enabled by being symlinked from another unit's + .wants/ or .requires/ directory. +• A unit's purpose may be to act as a helper for some other unit which has + a requirement dependency on it. +• A unit may be started when needed via activation (socket, path, timer, + D-Bus, udev, scripted systemctl call, ...). +• In case of template units, the unit is meant to be enabled with some + instance name specified. + ``` diff --git a/results/classifier/gemma3:12b/permissions/2039 b/results/classifier/gemma3:12b/permissions/2039 new file mode 100644 index 00000000..11ef68e2 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2039 @@ -0,0 +1,12 @@ + +there is no 'write' lock checked when exec `qemu-img check lvqcow2` +Description of problem: +There is a difference between a qcow2 file image and a lvqcow2 img. + +'write' lock will be checked when using a normal qcow2-format image (/path/to/img/test.qcow2) to avoid some risky operations. However, when I create a qcow2 img on a lv, there is not any write lock checked when I perform `qemu-img check` on this lvqcow2 even though it was attached to a vm. +Steps to reproduce: +1. create a lvqcow2: `qemu-img create -f qcow2 /path/to/lv xxG` +2. create a vm using this lvqcow2 +3. exec `qemu-img check` on this lvqcow2, there is no any perm (such as 'write' lock) check and notifaction even though this lvqcow2 is using in qemu vm. +Additional information: + diff --git a/results/classifier/gemma3:12b/permissions/2060 b/results/classifier/gemma3:12b/permissions/2060 new file mode 100644 index 00000000..f398bb33 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2060 @@ -0,0 +1,4 @@ + +memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set +Additional information: +i'm using pve-qemu-kvm 8.1.2-6 on 6.5.11-7-pve kernel diff --git a/results/classifier/gemma3:12b/permissions/2123 b/results/classifier/gemma3:12b/permissions/2123 new file mode 100644 index 00000000..64c91320 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2123 @@ -0,0 +1,32 @@ + +Invalid subprocess commands spawns successfully when running under QEMU +Description of problem: +When executing a subprocess from with a non-existing command EQMU still spawns a process. + +Consider this small rust program for instance: +```rust +use std::process::Command; + +fn main() { + match Command::new("thisdoesnotexist").spawn() { + Ok(child) => { + println!("Child process id is {}", child.id()); + } + Err(_) => { + println!("This should happen"); + } + } +} +``` + +**Executing with `qemu-aarch64`:** +```shell +qemu-aarch64 ./rust-app +Child process id is 20182 +``` + +**Executing regularly:** +```shell +./rust-app +This should happen +``` diff --git a/results/classifier/gemma3:12b/permissions/2140 b/results/classifier/gemma3:12b/permissions/2140 new file mode 100644 index 00000000..1409826f --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2140 @@ -0,0 +1,2 @@ + +Compiling object tests/fp - Can't create tests/fp Is directory Centos 7 diff --git a/results/classifier/gemma3:12b/permissions/2191 b/results/classifier/gemma3:12b/permissions/2191 new file mode 100644 index 00000000..20f2c7c9 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2191 @@ -0,0 +1,2 @@ + +Support exposing exports based on authentication diff --git a/results/classifier/gemma3:12b/permissions/2324 b/results/classifier/gemma3:12b/permissions/2324 new file mode 100644 index 00000000..90eb4a6a --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2324 @@ -0,0 +1,48 @@ + +SELinux is preventing some qemu-kvm operations on CentOS Stream 9 +Description of problem: +Some operations are being denied by SELinux. + +First it was read access on file max_map_count, then open and getattr access on /proc/sys/vm/max_map_count (same file but with full path). + +All have been fixed by creating and applying a semodule with the TE policy shown on "Additional Information" below. + +``` +May 2 18:01:00 rd02 setroubleshoot[14757]: SELinux is preventing /usr/libexec/qemu-kvm from read access on the file max_map_count. For complete SELinux messages run: sealert -l c92d5506-0b40-4bc8-be6a-133fe360014d +May 2 18:01:00 rd02 setroubleshoot[14757]: SELinux is preventing /usr/libexec/qemu-kvm from read access on the file max_map_count.#012#012***** Plugin qemu_file_image (98.8 confidence) suggests *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t 'max_map_count'#012# restorecon -v 'max_map_count'#012#012***** Plugin catchall (2.13 confidence) suggests **************************#012#012If you believe that qemu-kvm should be allowed read access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012 + +--- + +May 3 10:24:58 rd02 setroubleshoot[3981]: SELinux is preventing /usr/libexec/qemu-kvm from open access on the file /proc/sys/vm/max_map_count. For complete SELinux messages run: sealert -l 655af27c-6bc7-4278-9aad-7fc99929d24b +May 3 10:24:58 rd02 setroubleshoot[3981]: SELinux is preventing /usr/libexec/qemu-kvm from open access on the file /proc/sys/vm/max_map_count.#012#012***** Plugin qemu_file_image (98.8 confidence) suggests *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t '/proc/sys/vm/max_map_count'#012# restorecon -v '/proc/sys/vm/max_map_count'#012#012***** Plugin catchall (2.13 confidence) suggests **************************#012#012If you believe that qemu-kvm should be allowed open access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012 + +--- + +May 3 10:41:17 rd02 setroubleshoot[6894]: SELinux is preventing /usr/libexec/qemu-kvm from getattr access on the file /proc/sys/vm/max_map_count. For complete SELinux messages run: sealert -l db78c5b9-3890-44d4-a40e-d4011ad42913 +May 3 10:41:17 rd02 setroubleshoot[6894]: SELinux is preventing /usr/libexec/qemu-kvm from getattr access on the file /proc/sys/vm/max_map_count.#012#012***** Plugin qemu_file_image (98.8 confidence) suggests *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t '/proc/sys/vm/max_map_count'#012# restorecon -v '/proc/sys/vm/max_map_count'#012#012***** Plugin catchall (2.13 confidence) suggests **************************#012#012If you believe that qemu-kvm should be allowed getattr access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012 + + +``` +Steps to reproduce: +1. On a CentOS Stream 9 system with a selinux enforced, create a VM and install an OS with cockpit or with virt-install. + - example with virt-install: + `virt-install --connect qemu:///system --os-variant centos-stream9 --reinstall ipa03 --wait -1 --location /mnt/CentOS-Stream9.iso` +2. Check the SELinux logs, either on cockpit or on /var/log/messages +Additional information: +TE module that solved the issue, created with `ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm` + +``` +module my-qemukvm 1.1; + +require { + type sysctl_vm_t; + type svirt_t; + class file { getattr open read }; +} + +#============= svirt_t ============== + +#!!!! This avc is allowed in the current policy +allow svirt_t sysctl_vm_t:file read; +allow svirt_t sysctl_vm_t:file { getattr open }; +``` diff --git a/results/classifier/gemma3:12b/permissions/2397 b/results/classifier/gemma3:12b/permissions/2397 new file mode 100644 index 00000000..753ad815 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2397 @@ -0,0 +1,2 @@ + +Restrict qemu_file_set_error_obj() to migration/ diff --git a/results/classifier/gemma3:12b/permissions/2449 b/results/classifier/gemma3:12b/permissions/2449 new file mode 100644 index 00000000..3bf68558 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2449 @@ -0,0 +1,2 @@ + +How to extract FIS (personal question) diff --git a/results/classifier/gemma3:12b/permissions/2461 b/results/classifier/gemma3:12b/permissions/2461 new file mode 100644 index 00000000..2fffe521 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2461 @@ -0,0 +1,57 @@ + +Qemu with -accel whpx doesn't set WRMSR permissions, which blocks nested virtualization +Description of problem: +This bug blocks https://gitlab.com/qemu-project/qemu/-/issues/628 + +Qemu doesn't set the host's Hyper-V permissions for WRMSR command to allow using SVM or VMX. Unset permissions lead to `unchecked MSR access error: WRMSR to 0xc0000080` inside Linux VM when trying to launch nested VM on real AMD cpu. Intel users do not see guest VMX feature at all. Please see **Additional info** section to understand how Hyper-V permissions for nested virtualization work in Windows. +Steps to reproduce: +1. Turn on VT-x (for Intel) or AMD-V virtualization in your real hardware BIOS/EFI. This was tested only on AMD cpu and Qemu 9, Intel \*may\* behave differently. + 2. Install any distro in qemu disk c:\\linux_disk.qcow2 with MSR enabled in kernel, for example, Ubuntu 22.04 LTS. + 3. Run qemu using `qemu-system-x86_64.exe -m 2048 -machine q35 -accel whpx -cpu Opteron_G5,check,+svm -hda c:\linux_disk.qcow2` + + To check if your distro has MSR mod enabled, run `grep -i msr /boot/config-$(uname -r)` and it should return `CONFIG_X86_MSR=m` or `CONFIG_X86_MSR=y`. If not, recompile and reinstall your kernel. + 4. Run `sudo modprobe msr` and then `sudo rdmsr 0xc0000080 #EFER`. You should see `d01` on modern AMD models. \[Untested\] For intel, run `sudo modprobe msr`, then `sudo rdmsr 0x3A`. You should see `5` or `0x5` or `0x100005`. d01 for AMD and 5 for Intel in output are necessary to enable nested VM. If RDMSR returns non-zero value, it means that qemu developers implemented this part of functionality and your Hyper-V on Windows is not broken. + 5. Run `cat /proc/cpuinfo | grep -c svm` on AMD cpu, which should output a positive digit. + 6. Run `sudo dmesg | grep kvm` and note: + + `[1.924036] kvm_amd: Nested Virtualization enabled` + + `[1.924038] kvm_amd: Nested Paging disabled`\ + `[1.924040] kvm_amd: PMU virtualization is disabled` + 7. This, in theory, is sufficient for KVM-acclelerated qemu to start a nested VM. + 8. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error + 9. Run `sudo qemu-system-x86_64 -accel kvm`. A black window with "Guest has not initialized the display (yet)." appears. +10. Run `sudo dmesg` and note qemu crash starting with `unchecked MSR access error: WRMSR` + + \* Steps 1-4 are only required for diagnostics, and KVM works (in native Windows Hyper-V manager) without the necessarity to enter these commands in usual usage scenarios. If you run <span dir="">`cat /proc/cpuinfo | grep -c vmx` on Intel cpu</span> on Step 5, you may get zero. See Step 5 of Additional Info to understand why. + + \ + Microsoft released useful info about how to look into Hyper-V MSR access problems:\ + WRMSR research in Hyper-V - https://msrc.microsoft.com/blog/2018/12/first-steps-in-hyper-v-research/ +Additional information: +By default, Hyper-V manager in Windows does not allow nested virtualization.\ +To see what happens, do the following: + + 1. Open Hyper-V manager built in the host Windows and create default Ubuntu 22.04 LTS suggested. Upon installation, shut down the VM. Note the name of the VM ("Ubuntu 22.04 LTS" by default). + 2. Open Powershell console in the host and run `Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $false` + 3. Launch guest Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. No output. + 4. Run `sudo rdmsr 0xc0000080 #EFER` that outputs d01, which means that Hyper-V manager allows this **ring 0 level** operation. + 5. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `0`. + 6. Shut the VM down. + 7. Now, Open Powershell console and `run Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $true` + 8. Launch Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. Output: + + `[2.369144] kvm: Nested Virtualization enabled` + + `[2.369146] SVM: kvm: Nested Paging enabled` + + `[2.369148] SVM: kvm: Hyper-V enlightened NPT TLB flush enabled` + + `[2.369149] SVM: kvm: Hyper-V Direct TLB flush enabled` + + `[2.369153] SVM: Virtual VMLOAD VMSAVE supported` + 9. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `1` or other positive digit, depending on the number of cpus you've assigned to the VM. +10. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error +11. Run `sudo qemu-system-x86_64 -accel kvm` and it successfully boots into qemu BIOS. +12. Running `sudo qemu-system-x86_64 -accel kvm` calls WRMSR in background, so if you see\ + booted qemu BIOS in KVM, wrmsr was successfully called. diff --git a/results/classifier/gemma3:12b/permissions/2624 b/results/classifier/gemma3:12b/permissions/2624 new file mode 100644 index 00000000..cbd1954f --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2624 @@ -0,0 +1,40 @@ + +qemu-system-aarch64: tpm-emulator: TPM result for CMD_INIT: 0x9 operation failed +Description of problem: +I'm using QEMU (compile from the latest source code) to simulate a tpm2 device with the above command, it just returns an error message: +``` +qemu-system-aarch64: tpm-emulator: TPM result for CMD_INIT: 0x9 operation failed +``` +swtpm start command: +``` +TPMSOCK=/tmp/swtpm-sock$$ +swtpm socket --tpm2 -t -d --tpmstate dir=$PWD/tpm --ctrl type=unixio,path=$TPMSOCK --log level=20 +``` +swtpm version: +``` +TPM emulator version 0.7.3, Copyright (c) 2014-2021 IBM Corp. +``` +Also tried the latest swtpm, encountered the same error. + +swtpm log (0.7.3): +``` +swtpm: Data client disconnected +swtpm: SWTPM_NVRAM_Lock_Dir: Could not open lockfile: Permission denied +swtpm: Error: Could not initialize libtpms. +swtpm: Error: Could not initialize the TPM +swtpm: Data client disconnected +``` + +swtpm log (0.10.0): +``` +swtpm: SWTPM_NVRAM_StoreData: Error (fatal) opening tpm/TMP2-00.permall for write failed, Permission denied +swtpm: SWTPM_NVRAM_Lock_Dir: Could not open lockfile: Permission denied +swtpm: Error: Could not initialize the TPM +swtpm: Data client disconnected +``` + +Any clues about this error? Best regrads. +Steps to reproduce: +Refer to [Description of problem](#description-of-problem) +Additional information: + diff --git a/results/classifier/gemma3:12b/permissions/2747 b/results/classifier/gemma3:12b/permissions/2747 new file mode 100644 index 00000000..03297273 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2747 @@ -0,0 +1,10 @@ + +External snapshots are created world-readable when connecting via qemu+ssh://root +Description of problem: +External snapshots are created with world-readable permissions when connecting via `qemu+ssh://root`. +Steps to reproduce: +1. Create a VM over `qemu+ssh://root@$SERVER/system` +2. Create an external snapshot via virt-manager or with `virsh snapshot-create-as --domain testvm --name test --disk-only --diskspec vda,file=/var/lib/libvirt/images/test.qcow2 --atomic` +3. `ls -l /var/lib/libvirt/images/test.qcow2` +Additional information: +Issue doesn't seem to go away by adding `umask 077` in `$HOME/.profile` diff --git a/results/classifier/gemma3:12b/permissions/2781 b/results/classifier/gemma3:12b/permissions/2781 new file mode 100644 index 00000000..c0baf3f2 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/2781 @@ -0,0 +1,2 @@ + +Open logfiles for append diff --git a/results/classifier/gemma3:12b/permissions/306 b/results/classifier/gemma3:12b/permissions/306 new file mode 100644 index 00000000..7689ea2a --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/306 @@ -0,0 +1,2 @@ + +Option to constrain linux-user exec() to emulated CPU only diff --git a/results/classifier/gemma3:12b/permissions/321 b/results/classifier/gemma3:12b/permissions/321 new file mode 100644 index 00000000..508cead0 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/321 @@ -0,0 +1,2 @@ + +qemu 5.2.0 configure script explodes when in read only directory diff --git a/results/classifier/gemma3:12b/permissions/326 b/results/classifier/gemma3:12b/permissions/326 new file mode 100644 index 00000000..5ee68500 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/326 @@ -0,0 +1,2 @@ + +QEMU-user ignores MADV_DONTNEED diff --git a/results/classifier/gemma3:12b/permissions/368 b/results/classifier/gemma3:12b/permissions/368 new file mode 100644 index 00000000..76501751 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/368 @@ -0,0 +1,2 @@ + +virtiofsd: doesn't garant write access at users allowed by group permission diff --git a/results/classifier/gemma3:12b/permissions/390 b/results/classifier/gemma3:12b/permissions/390 new file mode 100644 index 00000000..545488c9 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/390 @@ -0,0 +1,2 @@ + +target/ppc: atomic path of Load Quadword instruction require address with write permission diff --git a/results/classifier/gemma3:12b/permissions/416 b/results/classifier/gemma3:12b/permissions/416 new file mode 100644 index 00000000..0c8c6e39 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/416 @@ -0,0 +1,2 @@ + +Error handling: Audit unsafe usages of strerror() diff --git a/results/classifier/gemma3:12b/permissions/440 b/results/classifier/gemma3:12b/permissions/440 new file mode 100644 index 00000000..f7c09c58 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/440 @@ -0,0 +1,2 @@ + +/usr/share/applications/qemu.desktop should have an "Exec=" key. diff --git a/results/classifier/gemma3:12b/permissions/447 b/results/classifier/gemma3:12b/permissions/447 new file mode 100644 index 00000000..01e4a7ab --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/447 @@ -0,0 +1,2 @@ + +qemu-arm: Unable to reserve 0xffff0000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option) diff --git a/results/classifier/gemma3:12b/permissions/470 b/results/classifier/gemma3:12b/permissions/470 new file mode 100644 index 00000000..8b234248 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/470 @@ -0,0 +1,2 @@ + +qemu linux-user requires read permissions on memory passed to syscalls that should only need write access diff --git a/results/classifier/gemma3:12b/permissions/515 b/results/classifier/gemma3:12b/permissions/515 new file mode 100644 index 00000000..f20a395d --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/515 @@ -0,0 +1,32 @@ + +qemu-system-x86_64 fails to run with regular user after following arch wiki article +Description of problem: +When `qemu-system-x86_64` binary is run with a regular user, it fails with no output. No matter if it's run with `--help`, `--version` or any other parameter. By checking the resulting error code (`echo $?`) it is possible to see that it finished with error code 1. + +After seeing this [post](https://www.reddit.com/r/archlinux/comments/b9emxp/qemusystemx86_64_does_not_execute_how_can_i/ek47btb/) on reddit, it became clear that the reason was that my `/etc` directory had a subdirectory qemu, in which my regular user did not have access to. That is, qemu binary looks for `/etc/qemu/qemu.conf` and if it can't determine if the file is there or not, it fails. + +Here goes the logic: +strace showed the permission error (even though there was no output to indicate that). + +``` +$ strace /usr/bin/qemu-system-x86_64 +… +mmap(NULL, 4928, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE, 3, 0) = 0x7f4d01e6e000 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE, 3, 0x10000000) = 0x7f4d01e6c000 +eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 4 +sysinfo({uptime=92539, loads=[109952, 80640, 118144], totalram=16643309568, freeram=5314445312, sharedram=2590158848, bufferram=1301561344, totalswap=20479733760, freeswap=19551150080, procs=1202, totalhigh=0, freehigh=0, mem_unit=1}) = 0 +rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f4d01ad7960}, NULL, 8) = 0 +openat(AT_FDCWD, "/etc/qemu/qemu.conf", O_RDONLY) = -1 EACCES (Permission denied) +exit_group(1) = ? ++++ exited with 1 +++ +``` + +The thing was that initially that folder did not exist, and I created it to make the qemu bridges work, like indicated in this arch wiki [article](https://wiki.archlinux.org/title/QEMU#Bridged_networking_using_qemu-bridge-helper). I will be suggesting modifications to that article. + +When the directory did not exit, qemu noticed that the folder didn't exist and moved on, once it was created, in case the regular user had no access to it, it fails with no warning. + +I just gave access to the folder ant it worked again (if you delete the folder it works too). + +If you use libvirt, by using virsh for example, you may not notice this issue as it may be running as system (by setting the following system variable `export LIBVIRT_DEFAULT_URI='qemu:///system'`) + +So, to fix this issue, in my opinion a warning should be printed out to the stderr. Otherwise, qemu could move on if it doens't have access to `/etc/qemu/qemu.conf`. diff --git a/results/classifier/gemma3:12b/permissions/566 b/results/classifier/gemma3:12b/permissions/566 new file mode 100644 index 00000000..f0230bda --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/566 @@ -0,0 +1,2 @@ + +Fail to build linux-user on Alpine diff --git a/results/classifier/gemma3:12b/permissions/579 b/results/classifier/gemma3:12b/permissions/579 new file mode 100644 index 00000000..b18fa5bb --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/579 @@ -0,0 +1,51 @@ + +chown() fails when it should succeed in QEMU user mode on Linux/sparc64 +Description of problem: +The `chown()` function fails, instead of succeeding, in a particular situation. +Steps to reproduce: +[foo.c](/uploads/630d9b83671a071f4ded4da43b6c1b9b/foo.c) + +1. +``` +# apt install g++-10-sparc64-linux-gnu +# mkdir -p /usr/sparc64-linux-gnu/etc +# touch /usr/sparc64-linux-gnu/etc/ld.so.cache +``` +2. +``` +$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/bbab43a1b78e6d16ee13e0eff5e963a5/a.out) + +3. Transfer the a.out file to a Linux/sparc64 machine; execute these commands there: +``` +$ id +``` +Verify that you are in 2 or more groups. +``` +$ touch file +$ ln -s file link +$ ln -s link link2 +$ ./a.out; echo $? +``` +It prints `0`. + +4. +``` +$ id +``` +Verify that you are in 2 or more groups. +``` +$ touch file +$ ln -s file link +$ ln -s link link2 +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out; echo $? +``` +Expected: `0` +Actual: +``` +chown: Operation not permitted +1 +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/permissions/633 b/results/classifier/gemma3:12b/permissions/633 new file mode 100644 index 00000000..ec89b3f2 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/633 @@ -0,0 +1,33 @@ + +i686-arm-user-static - Allocating guest commpage: Operation not permitted +Steps to reproduce: +1. Run the test case linked earlier. +2. You'll see `apt update` failing: + +``` +Get:1 http://archive.raspberrypi.org/debian buster InRelease [32.6 kB] +Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB] +Err:1 http://archive.raspberrypi.org/debian buster InRelease + At least one invalid signature was encountered. +Err:2 http://raspbian.raspberrypi.org/raspbian buster InRelease + At least one invalid signature was encountered. +Reading package lists... Done +W: GPG error: http://archive.raspberrypi.org/debian buster InRelease: At least one invalid signature was encountered. +E: The repository 'http://archive.raspberrypi.org/debian buster InRelease' is not signed. +N: Updating from such a repository can't be done securely, and is therefore disabled by default. +N: See apt-secure(8) manpage for repository creation and user configuration details. +W: GPG error: http://raspbian.raspberrypi.org/raspbian buster InRelease: At least one invalid signature was encountered. +E: The repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' is not signed. +N: Updating from such a repository can't be done securely, and is therefore disabled by default. +N: See apt-secure(8) manpage for repository creation and user configuration details. +``` +Additional information: +Setting `sysctl vm.mmap_min_addr=53248` makes it work (as opposed to the system default of 65536). + +Bisecting the bug linked earlier also breaks this in a slightly different way. Everything works at 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1. After that, apt update appears to work, but the package lists end up empty, so nothing can be installed. Then after 975ac4559c4c00010e05f7a3e782eeb9497837ea, the output is as provided above. + +apt launches /usr/lib/apt/methods/gpgv and passes it some commands through stdin. gpgv launches /usr/bin/apt-key, which fails with `Allocating guest commpage: Operation not permitted`. Running gpgv directly and sending the same commands works without any issues. The problem only occurs when gpgv is run through apt. (I don't meant the normal system gpgv binary, but the transport method binary that comes with apt) + +Getting any output is tricky because by the time apt-key is launched, gpgv redirects stdout and stderr to /dev/null and communication takes place through fd 3. https://salsa.debian.org/apt-team/apt/-/blob/2.2.4/apt-pkg/contrib/gpgv.cc#L355 https://salsa.debian.org/apt-team/apt/-/blob/main/methods/gpgv.cc#L186 + +I had to do some ugly things with different versions of qemu and wrapper scripts to see the commpage error, but hopefully there's enough information provided here that it won't be necessary. diff --git a/results/classifier/gemma3:12b/permissions/690 b/results/classifier/gemma3:12b/permissions/690 new file mode 100644 index 00000000..18828678 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/690 @@ -0,0 +1,20 @@ + +32bit qemu-arm can't run GCC due to failure to allocate memory range for guest (Allocating guest commpage error) +Description of problem: +I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Since version 5.1 (include latest 6.1), QEMU cannot run GCC and some other things with an error `Allocating guest commpage: Operation not permitted`. The problem is NOT reproducible on QEMU 5.0, so probably the problem was caused by a [rework of init_guest_space or the following commits](https://gitlab.com/qemu-project/qemu/-/commit/ee94743034bfb443cf246eda4971bdc15d8ee066) a year ago. + +Also the problem is not reproducible for all users. It is known that it is reproduced on all Arch Linux host machines and some Debian, and probably depends on some kernel build parameters. + +The sysctl `vm.mmap_min_addr` parameter also affects the problem. The error varies depending on its value: +``` +[0 ... 53248] - No error at all +[53249 ... 61440] - Cannot allocate memory +[61441 ... 65536 and higher] - Operation not permitted +``` +Steps to reproduce: +1. Download and extract attached tarball: [qemu-test-gcc.tgz](/uploads/0031fdf6705183626f646b78a281dd2a/qemu-test-gcc.tgz) +2. `$ make # will build the docker container` +3. `$ make run # will enter the container` +4. Once in the container, run: `# /qemu-arm-static-50 /bin/bash /runme.sh` +Additional information: +A detailed description of the problem and feedback from other users is here: https://bugs.launchpad.net/qemu/+bug/1891748 diff --git a/results/classifier/gemma3:12b/permissions/701 b/results/classifier/gemma3:12b/permissions/701 new file mode 100644 index 00000000..fe2f71df --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/701 @@ -0,0 +1,2 @@ + +Setup a gitlab shared runner for linux-user testing diff --git a/results/classifier/gemma3:12b/permissions/739785 b/results/classifier/gemma3:12b/permissions/739785 new file mode 100644 index 00000000..e1999c8a --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/739785 @@ -0,0 +1,35 @@ + +qemu-i386 user mode can't fork (bash: fork: Invalid argument) + +Good time of day everybody, + +I have been trying to make usermode qemu on ARM with plugapps (archlinux) with archlinux i386 chroot to work. + +1. I installed arch linux in a virtuabox and created a chroot for it with mkarchroot. Transferred it to my pogo plug into /i386/ +2. I comiled qemu-i386 static and put it into /i386/usr/bin/ +./configure --static --disable-blobs --disable-system --target-list=i386-linux-user +make + +3. I also compiled linux kernel 2.6.38 with CONFIG_BINFMT_MISC=y and installed it. +uname -a +Linux Plugbox 2.6.38 #4 PREEMPT Fri Mar 18 22:19:10 CDT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux + +4. Added the following options into /etc/rc.local +/sbin/modprobe binfmt_misc +/bin/mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc +echo ':qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-i386:' >/proc/sys/fs/binfmt_misc/register + +5. Also copied ld-linux.so.3 (actually ld-2.13.so because ld-linux.so.3 is a link to that file) from /lib/ to /i386/lib/ + +6.Now i chroot into /i386 and I get this: +[root@Plugbox i386]# chroot . +[II aI hnve ao n@P /]# pacman -Suy +bash: fork: Invalid argument + +7.I also downloaded linux-user-test-0.3 from qemu website and ran the test: +[root@Plugbox linux-user-test-0.3]# make +./qemu-linux-user.sh +[qemu-i386] +../qemu-0.14.0/i386-linux-user/qemu-i386 -L ./gnemul/qemu-i386 i386/ls -l dummyfile +BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! +make: *** [test] Error 127 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/797905 b/results/classifier/gemma3:12b/permissions/797905 new file mode 100644 index 00000000..a83a0b0f --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/797905 @@ -0,0 +1,20 @@ + +virsh live migration + +Hi, +i do not manage to do a virsh migrate live command. +Using Ubuntu Server 10.04 x64 + +root@svr50abl:~# virsh list + Id Nome Estado +---------------------------------- + 18 Winxp executando + 19 teste executando + +root@svr50abl:~# sudo virsh migrate --live 19 qemu+ssh://10.1.5.1/system +root@10.1.5.1's password: +erro: unable to set user and group to '116:127' on '/var/lib/libvirt/images/teste.img': No such file or directory + +teste.img has root:root (xrw) + +10.1.5.1 is a functional kvm host too \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/798 b/results/classifier/gemma3:12b/permissions/798 new file mode 100644 index 00000000..8da1f944 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/798 @@ -0,0 +1,16 @@ + +The sandbox option elevelateprivileges=deny does not work with -daemonize +Description of problem: +qemu will not launch if `-sandbox on,elevateprivileges=deny` and `-daemonize` are set at the same time. +Steps to reproduce: +``` +qemu-system-x86_64 -sandbox on,elevateprivileges=deny -nodefaults -daemonize +``` +-> fails to launch + +``` +qemu-system-x86_64 -sandbox on -nodefaults -daemonize +``` +-> runs normally +Additional information: +[journal.txt](/uploads/c0e2a973e749011c3b1ac2158420a4e8/journal.txt) diff --git a/results/classifier/gemma3:12b/permissions/807893 b/results/classifier/gemma3:12b/permissions/807893 new file mode 100644 index 00000000..19cbdc2d --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/807893 @@ -0,0 +1,32 @@ + +qemu privilege escalation + +If qemu is started as root, with -runas, the extra groups is not dropped correctly + +/proc/`pidof qemu`/status +.. +Uid: 100 100 100 100 +Gid: 100 100 100 100 +FDSize: 32 +Groups: 0 1 2 3 4 6 10 11 26 27 +... + +The fix is to add initgroups() or setgroups(1, [gid]) where appropriate to os-posix.c. + +The extra gid's allow read or write access to other files (such as /dev etc). + +Emulating the qemu code: + +# python +... +>>> import os +>>> os.setgid(100) +>>> os.setuid(100) +>>> os.execve("/bin/sh", [ "/bin/sh" ], os.environ) +sh-4.1$ xxd /dev/sda | head -n2 +0000000: eb48 9000 0000 0000 0000 0000 0000 0000 .H.............. +0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ +sh-4.1$ ls -l /dev/sda +brw-rw---- 1 root disk 8, 0 Jul 8 11:54 /dev/sda +sh-4.1$ id +uid=100(qemu00) gid=100(users) groups=100(users),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/871 b/results/classifier/gemma3:12b/permissions/871 new file mode 100644 index 00000000..78aa0c8b --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/871 @@ -0,0 +1,15 @@ + +qemu-x86_64 don't support unshare(CLONE_NEWUSER) +Description of problem: +Why qemu-x86_64 call unshare(CLONE_NEWUSER) fail? +``` + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ qemu-x86_64 /bin/unshare --user /bin/bash + unshare: unshare failed: Invalid argument + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ /bin/unshare --user /bin/bash + nobody@ubuntu:~/Desktop/afl/AFLplusplus$ +``` +Steps to reproduce: +1.execute `qemu-x86_64 /bin/unshare --user /bin/bash` ,it will fail <br/> +2.execute `/bin/unshare --user /bin/bash` ,it will ok + +How i fix that? diff --git a/results/classifier/gemma3:12b/permissions/891625 b/results/classifier/gemma3:12b/permissions/891625 new file mode 100644 index 00000000..ee995719 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/891625 @@ -0,0 +1,5 @@ + +[qemu-kvm] add vhost-net to kvm group udev rules 65-kvm.rules + +Please consider authorizing the kvm group to access vhost-net device, similar to the kvm device. +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/905095 b/results/classifier/gemma3:12b/permissions/905095 new file mode 100644 index 00000000..0568aadf --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/905095 @@ -0,0 +1,61 @@ + +qemu-img can't convert vmdk file: Operation not permitted + +There is no reason why the vdmk image can't be converted. Even running it as root does not help. + +$ ls -lh +insgesamt 60G +-rw-rw-rw- 1 root root 479M 2011-09-10 17:47 freetz-linux-1.2.1-disk1.vmdk + +$ sudo qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw /tmp/freetz-linux-1.2.1-disk1.raw +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk' + +I get a similar Error when I try to rum vmdk images directly. After adding a new machine and adding vmdk disks with virt-manager, it tells me when I start the virtual machine: +Error starting domain: internal error process exited while connecting to monitor: char device redirected to /dev/pts/1 +kvm: -drive file=/var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk,if=none,id=drive-virtio-disk0,boot=on,format=qcow2: could not open disk image /var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk: Invalid argument + +Runnung raw images works perfectly for me. + +Hint: i have a symlink set: +/var/lib/libvirt$ ls -lh +insgesamt 12K +drwxr-xr-x 2 root root 4,0K 2011-07-26 14:30 boot +lrwxrwxrwx 1 root root 9 2011-08-19 10:47 images -> /home/vms +drwxr-xr-x 2 root root 4,0K 2011-08-19 09:38 network +drwxr-xr-x 5 libvirt-qemu kvm 4,0K 2011-12-16 04:34 qemu + +but this should not be the reason hopefully + +ProblemType: Bug +DistroRelease: Ubuntu 11.04 +Package: qemu-kvm 0.14.0+noroms-0ubuntu4.4 +ProcVersionSignature: Ubuntu 2.6.38-13.52-generic 2.6.38.8 +Uname: Linux 2.6.38-13-generic x86_64 +Architecture: amd64 +CheckboxSubmission: 8f12e98536291f59719792d89958b124 +CheckboxSystem: d00f84de8a555815fa1c4660280da308 +Date: Fri Dec 16 04:24:10 2011 +InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1) +KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UID PID PPID C SZ RSS PSR STIME TTY TIME CMD +MachineType: Dell Inc. Latitude E5510 +ProcEnviron: + LANGUAGE=de_DE:en + PATH=(custom, user) + LANG=de_DE.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-13-generic root=UUID=503213e4-5136-4e60-8a02-7cbd0123dca8 ro quiet splash vt.handoff=7 +SourcePackage: qemu-kvm +UpgradeStatus: Upgraded to natty on 2011-08-18 (119 days ago) +dmi.bios.date: 09/08/2011 +dmi.bios.vendor: Dell Inc. +dmi.bios.version: A11 +dmi.board.name: 023HKR +dmi.board.vendor: Dell Inc. +dmi.board.version: A00 +dmi.chassis.type: 9 +dmi.chassis.vendor: Dell Inc. +dmi.modalias: dmi:bvnDellInc.:bvrA11:bd09/08/2011:svnDellInc.:pnLatitudeE5510:pvr0001:rvnDellInc.:rn023HKR:rvrA00:cvnDellInc.:ct9:cvr: +dmi.product.name: Latitude E5510 +dmi.product.version: 0001 +dmi.sys.vendor: Dell Inc. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/permissions/95 b/results/classifier/gemma3:12b/permissions/95 new file mode 100644 index 00000000..9a670b7c --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/95 @@ -0,0 +1,2 @@ + +linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code) diff --git a/results/classifier/gemma3:12b/permissions/967 b/results/classifier/gemma3:12b/permissions/967 new file mode 100644 index 00000000..83022662 --- /dev/null +++ b/results/classifier/gemma3:12b/permissions/967 @@ -0,0 +1,225 @@ + +qemu 6.2 user mode memory leak when mmap + munmap is called +Description of problem: +Launch a program with qemu user mode emulator, +If this program calls mmap to allocate 40GB virtual memory and call munmap to free it later, the memory const of qemu user mode emulator grows to a very big value. + +Excepted behavior: qemu-x86_64 costs very less memory after munmap is called. +Observed behavior: qemu-x86_64 costs around 2.5GiB after munmap is called. Most of the memory is consumed by [heap]. +Steps to reproduce: +1.Compile this code with g++. +```shell +g++ -o main.bin main.cpp +``` +```cpp +#include <chrono> +#include <cstdio> +#include <sys/types.h> +#include <unistd.h> +#include <cstdlib> +#include <sys/mman.h> + +#include <thread> + +static constexpr size_t pageSize = 4096; + +int main(){ + constexpr size_t size = 1024*100*pageSize*1000; + + void* data = mmap(nullptr, size, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); + + if(data == nullptr){ + perror("mmap failed"); + exit(1); + } + + int error = munmap(data, size); + + if(error !=0){ + perror("munmap failed"); + exit(1); + } + + + printf("mmap munmap test done\n"); + while(true){ + std::this_thread::sleep_for(std::chrono::seconds(10000)); + } + + return 0; +} +``` +2. run main.bin with qemu-x86_64 +```shell +$ qemu-x86_64 ./main.bin +mmap munmap test done +``` +3. check memory usage by top +``` +$ top -p `pgrep "qemu"` +top - 16:00:39 up 6:41, 1 user, load average: 0.08, 0.12, 0.10 +Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie +%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +MiB Mem : 15969.1 total, 8249.3 free, 6048.2 used, 1671.5 buff/cache +MiB Swap: 2048.0 total, 1209.6 free, 838.4 used. 9544.3 avail Mem + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 38521 jcq 20 0 2634324 2.3g 7840 S 0.0 14.8 0:04.48 qemu-x86_64 +``` + +4. check memory usage by mmap. Heap is 5611ca5e0000-56125d125000, the size of heap is more than 2GiB. +```shell +$ cat /proc/38521/maps +4000000000-4000001000 r--p 00000000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000001000-4000002000 r--p 00001000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000002000-4000003000 r--p 00002000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000003000-4000004000 r--p 00002000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000004000-4000005000 rw-p 00003000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000005000-4000026000 rw-p 00000000 00:00 0 +4001005000-4001006000 ---p 00000000 00:00 0 +4001006000-4001806000 rw-p 00000000 00:00 0 +4001806000-400183d000 r--p 00000000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +400183d000-400183e000 ---p 00000000 00:00 0 +400183e000-4001840000 r--p 00037000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +4001840000-4001842000 rw-p 00039000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +4001842000-4001844000 rw-p 00000000 00:00 0 +4001863000-4001a78000 r--p 00000000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a78000-4001a7c000 r--p 00214000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a7c000-4001a7e000 rw-p 00218000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a7e000-4001a8d000 rw-p 00000000 00:00 0 +5611c96af000-5611c9734000 r--p 00000000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9734000-5611c9885000 r-xp 00085000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9885000-5611c9901000 r--p 001d6000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9902000-5611c993c000 r--p 00252000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c993c000-5611c9950000 rw-p 0028c000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9950000-5611c996e000 rw-p 00000000 00:00 0 +5611ca5e0000-56125d125000 rw-p 00000000 00:00 0 [heap] +7f2038000000-7f203ffff000 rwxp 00000000 00:00 0 +7f203ffff000-7f2040000000 ---p 00000000 00:00 0 +7f2040000000-7f2040021000 rw-p 00000000 00:00 0 +7f2040021000-7f2044000000 ---p 00000000 00:00 0 +7f2047def000-7f2047e70000 rw-p 00000000 00:00 0 +7f2047e70000-7f2047e71000 ---p 00000000 00:00 0 +7f2047e71000-7f2048676000 rw-p 00000000 00:00 0 +7f2048676000-7f2048678000 r--p 00000000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048678000-7f204867f000 r-xp 00002000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f204867f000-7f2048680000 r--p 00009000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048680000-7f2048681000 ---p 0000a000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048681000-7f2048682000 r--p 0000a000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048682000-7f2048683000 rw-p 0000b000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048683000-7f204868d000 r--p 00000000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f204868d000-7f20486ec000 r-xp 0000a000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f20486ec000-7f2048703000 r--p 00069000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048703000-7f2048704000 r--p 0007f000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048704000-7f2048705000 rw-p 00080000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048705000-7f204870d000 r--p 00000000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204870d000-7f2048720000 r-xp 00008000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f2048720000-7f204874a000 r--p 0001b000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874a000-7f204874b000 ---p 00045000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874b000-7f204874c000 r--p 00045000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874c000-7f204874d000 rw-p 00046000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874d000-7f2048757000 r--p 00000000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048757000-7f204877a000 r-xp 0000a000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f204877a000-7f2048790000 r--p 0002d000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048790000-7f2048792000 r--p 00042000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048792000-7f2048793000 rw-p 00044000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048793000-7f2048795000 rw-p 00000000 00:00 0 +7f2048795000-7f2048798000 r--p 00000000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f2048798000-7f20487a6000 r-xp 00003000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487a6000-7f20487aa000 r--p 00011000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487aa000-7f20487ab000 ---p 00015000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ab000-7f20487ac000 r--p 00015000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ac000-7f20487ad000 rw-p 00016000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ad000-7f20487be000 r--p 00000000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f20487be000-7f20487f4000 r-xp 00011000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f20487f4000-7f2048952000 r--p 00047000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048952000-7f2048956000 r--p 001a5000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048956000-7f2048957000 rw-p 001a9000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048957000-7f2048959000 r--p 00000000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048959000-7f204895d000 r-xp 00002000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f204895d000-7f2048976000 r--p 00006000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048976000-7f2048977000 r--p 0001e000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048977000-7f2048978000 rw-p 0001f000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048978000-7f20489a1000 r--p 00000000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f20489a1000-7f2048a45000 r-xp 00029000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048a45000-7f2048a9f000 r--p 000cd000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048a9f000-7f2048aa9000 r--p 00126000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048aa9000-7f2048ab3000 rw-p 00130000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048ab3000-7f2048ab5000 r--p 00000000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048ab5000-7f2048b0a000 r-xp 00002000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b0a000-7f2048b27000 r--p 00057000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b27000-7f2048b28000 r--p 00073000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b28000-7f2048b29000 rw-p 00074000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b29000-7f2048b51000 r--p 00000000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048b51000-7f2048ce6000 r-xp 00028000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048ce6000-7f2048d3e000 r--p 001bd000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d3e000-7f2048d42000 r--p 00214000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d42000-7f2048d44000 rw-p 00218000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d44000-7f2048d53000 rw-p 00000000 00:00 0 +7f2048d53000-7f2048d56000 r--p 00000000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d56000-7f2048d6d000 r-xp 00003000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d6d000-7f2048d71000 r--p 0001a000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d71000-7f2048d72000 r--p 0001d000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d72000-7f2048d73000 rw-p 0001e000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d73000-7f2048d81000 r--p 00000000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048d81000-7f2048dfd000 r-xp 0000e000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048dfd000-7f2048e58000 r--p 0008a000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e58000-7f2048e59000 r--p 000e4000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e59000-7f2048e5a000 rw-p 000e5000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e5a000-7f2048e8b000 r--p 00000000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2048e8b000-7f2048fb4000 r-xp 00031000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2048fb4000-7f2049031000 r--p 0015a000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049031000-7f2049041000 r--p 001d6000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049041000-7f2049043000 rw-p 001e6000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049043000-7f2049045000 rw-p 00000000 00:00 0 +7f2049045000-7f2049047000 r--p 00000000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f2049047000-7f2049049000 r-xp 00002000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f2049049000-7f204904a000 r--p 00004000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904a000-7f204904b000 r--p 00004000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904b000-7f204904c000 rw-p 00005000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904c000-7f2049069000 r--p 00000000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049069000-7f20490f8000 r-xp 0001d000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f20490f8000-7f2049182000 r--p 000ac000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049182000-7f2049183000 ---p 00136000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049183000-7f2049184000 r--p 00136000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049184000-7f2049185000 rw-p 00137000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049185000-7f2049186000 rw-p 00000000 00:00 0 +7f2049186000-7f2049188000 r--p 00000000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f2049188000-7f204918a000 r-xp 00002000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918a000-7f204918b000 r--p 00004000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918b000-7f204918c000 r--p 00004000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918c000-7f204918d000 rw-p 00005000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f20491ac000-7f20491ae000 rw-p 00000000 00:00 0 +7f20491ae000-7f20491b0000 r--p 00000000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491b0000-7f20491da000 r-xp 00002000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491da000-7f20491e5000 r--p 0002c000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491e6000-7f20491e8000 r--p 00037000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491e8000-7f20491ea000 rw-p 00039000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7fffe17ee000-7fffe1810000 rw-p 00000000 00:00 0 [stack] +7fffe19d1000-7fffe19d5000 r--p 00000000 00:00 0 [vvar] +7fffe19d5000-7fffe19d7000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] +``` +Additional information: +qemu is installed by ubuntu's apt. + +sudo apt install qemu-user + +compiler version: +``` +g++ --version +g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0 +Copyright (C) 2021 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +``` + +libc version: +``` +ldd --version +ldd (Ubuntu GLIBC 2.35-0ubuntu3) 2.35 +Copyright (C) 2022 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +Written by Roland McGrath and Ulrich Drepper. +``` |