Description of problem: When seccomp_register() determines the host lacks TSYNC capability, any use of -seccomp crashes. This should not normally happen. However, it does under valgrind for me. I think we should backport the fix from upstream, because having valgrind fail that way is bound to waste time when investigating bugs. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. valgrind qemu-kvm -sandbox off -monitor stdio Actual results: --2164-- WARNING: unhandled amd64-linux syscall: 317 --2164-- You may be able to write your own handler. --2164-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --2164-- Nevertheless we consider this a bug. Please report --2164-- it at http://valgrind.org/support/bug_reports.html. avs8-qemu-kvm: -sandbox off: There is no option group 'sandbox' avs8-qemu-kvm: -sandbox off: There is no option group 'sandbox' ==2164== Invalid read of size 8 ==2164== at 0x7891B6: opts_parse (qemu-option.c:888) ==2164== by 0x789644: qemu_opts_parse_noisily (qemu-option.c:950) ==2164== by 0x3FD234: main (vl.c:3938) ==2164== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==2164== ==2164== ==2164== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==2164== Access not within mapped region at address 0x8 ==2164== at 0x7891B6: opts_parse (qemu-option.c:888) ==2164== by 0x789644: qemu_opts_parse_noisily (qemu-option.c:950) ==2164== by 0x3FD234: main (vl.c:3938) ==2164== If you believe this happened as a result of a stack ==2164== overflow in your program's main thread (unlikely but ==2164== possible), you can try to increase the size of the ==2164== main thread stack using the --main-stacksize= flag. ==2164== The main thread stack size used in this run was 8388608. ==2164== ==2164== HEAP SUMMARY: ==2164== in use at exit: 331,489 bytes in 2,713 blocks ==2164== total heap usage: 3,520 allocs, 807 frees, 548,858 bytes allocated ==2164== ==2164== LEAK SUMMARY: ==2164== definitely lost: 0 bytes in 0 blocks ==2164== indirectly lost: 0 bytes in 0 blocks ==2164== possibly lost: 2,236 bytes in 39 blocks ==2164== still reachable: 329,253 bytes in 2,674 blocks ==2164== of which reachable via heuristic: ==2164== newarray : 1,536 bytes in 16 blocks ==2164== suppressed: 0 bytes in 0 blocks ==2164== Rerun with --leak-check=full to see details of leaked memory ==2164== ==2164== For lists of detected and suppressed errors, rerun with: -s ==2164== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault Expected results: qemu-kvm starts fine under valgrind, and prints the monitor prompt "(qemu)". Additional info: Fixed upstream in commit 2bb814a45be0bffb2f2499245a22fe72225c34ac "vl: fix -sandbox parsing crash when seccomp support is disabled".
what's the version of qemu?
Assuming it is qemu-kvm-2.12 of rhel8 and rhel8.1, The fix will "only" change a crash to a exit(1). I can send the following backport: diff --git a/vl.c b/vl.c index c7785940f5..a3176f8195 100644 --- a/vl.c +++ b/vl.c @@ -4056,8 +4056,12 @@ int main(int argc, char **argv, char **envp) qtest_log = optarg; break; case QEMU_OPTION_sandbox: - opts = qemu_opts_parse_noisily(qemu_find_opts("sandbox"), - optarg, true); + olist = qemu_find_opts("sandbox"); + if (!olist) { + exit(1); + } + + opts = qemu_opts_parse_noisily(olist, optarg, true); if (!opts) { exit(1); }
Note product "Red Hat Enterprise Linux Advanced Virtualization". I'm at git tag qemu-kvm-4.0.0-3.module+el8.1.0+3265+26c4ed71. The upstream fix applies cleanly.
Fixed upstream and will be inherited by rebase, so changing to POST and updating flags.
Reproduced with qemu-kvm-core-4.0.0-3.module+el8.1.0+3265+26c4ed71.x86_64 as [1]. Verified with qemu-kvm-core-4.2.0-1.module+el8.2.0+4793+b09dd2fb.x86_64 as [2]. Hi Marc-Andre, Segmentation fault disappears, but the process quits without printing the monitor prompt "(qemu)". I think this is expected. Is that enough for the verification? Thanks, yduan [1]: # valgrind /usr/libexec/qemu-kvm -sandbox off -monitor stdio ==21826== Memcheck, a memory error detector ==21826== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==21826== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==21826== Command: /usr/libexec/qemu-kvm -sandbox off -monitor stdio ==21826== --21826-- WARNING: unhandled amd64-linux syscall: 317 --21826-- You may be able to write your own handler. --21826-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --21826-- Nevertheless we consider this a bug. Please report --21826-- it at http://valgrind.org/support/bug_reports.html. qemu-kvm: -sandbox off: There is no option group 'sandbox' ==21826== Invalid read of size 8 ==21826== at 0x764FE8: ??? (in /usr/libexec/qemu-kvm) ==21826== by 0x765463: qemu_opts_parse_noisily (in /usr/libexec/qemu-kvm) ==21826== by 0x3FAF04: main (in /usr/libexec/qemu-kvm) ==21826== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==21826== ==21826== ==21826== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==21826== Access not within mapped region at address 0x8 ==21826== at 0x764FE8: ??? (in /usr/libexec/qemu-kvm) ==21826== by 0x765463: qemu_opts_parse_noisily (in /usr/libexec/qemu-kvm) ==21826== by 0x3FAF04: main (in /usr/libexec/qemu-kvm) ==21826== If you believe this happened as a result of a stack ==21826== overflow in your program's main thread (unlikely but ==21826== possible), you can try to increase the size of the ==21826== main thread stack using the --main-stacksize= flag. ==21826== The main thread stack size used in this run was 8388608. ==21826== ==21826== HEAP SUMMARY: ==21826== in use at exit: 331,078 bytes in 2,710 blocks ==21826== total heap usage: 3,490 allocs, 780 frees, 545,473 bytes allocated ==21826== ==21826== LEAK SUMMARY: ==21826== definitely lost: 0 bytes in 0 blocks ==21826== indirectly lost: 0 bytes in 0 blocks ==21826== possibly lost: 2,220 bytes in 39 blocks ==21826== still reachable: 328,858 bytes in 2,671 blocks ==21826== of which reachable via heuristic: ==21826== newarray : 1,536 bytes in 16 blocks ==21826== suppressed: 0 bytes in 0 blocks ==21826== Rerun with --leak-check=full to see details of leaked memory ==21826== ==21826== For lists of detected and suppressed errors, rerun with: -s ==21826== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault (core dumped) # [2]: # valgrind /usr/libexec/qemu-kvm -sandbox off -monitor stdio ==22440== Memcheck, a memory error detector ==22440== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==22440== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==22440== Command: /usr/libexec/qemu-kvm -sandbox off -monitor stdio ==22440== --22440-- WARNING: unhandled amd64-linux syscall: 317 --22440-- You may be able to write your own handler. --22440-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --22440-- Nevertheless we consider this a bug. Please report --22440-- it at http://valgrind.org/support/bug_reports.html. qemu-kvm: -sandbox off: There is no option group 'sandbox' ==22440== ==22440== HEAP SUMMARY: ==22440== in use at exit: 360,178 bytes in 2,994 blocks ==22440== total heap usage: 4,045 allocs, 1,051 frees, 589,486 bytes allocated ==22440== ==22440== LEAK SUMMARY: ==22440== definitely lost: 0 bytes in 0 blocks ==22440== indirectly lost: 0 bytes in 0 blocks ==22440== possibly lost: 1,832 bytes in 19 blocks ==22440== still reachable: 358,346 bytes in 2,975 blocks ==22440== of which reachable via heuristic: ==22440== newarray : 1,536 bytes in 16 blocks ==22440== suppressed: 0 bytes in 0 blocks ==22440== Rerun with --leak-check=full to see details of leaked memory ==22440== ==22440== For lists of detected and suppressed errors, rerun with: -s ==22440== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) #
(In reply to yduan from comment #6) > Reproduced with qemu-kvm-core-4.0.0-3.module+el8.1.0+3265+26c4ed71.x86_64 as > [1]. > Verified with qemu-kvm-core-4.2.0-1.module+el8.2.0+4793+b09dd2fb.x86_64 as > [2]. > > Hi Marc-Andre, > > Segmentation fault disappears, but the process quits without printing the > monitor prompt "(qemu)". > I think this is expected. > Is that enough for the verification? Hi, yes, that should be fine. thanks
(In reply to Marc-Andre Lureau from comment #7) > (In reply to yduan from comment #6) > > Reproduced with qemu-kvm-core-4.0.0-3.module+el8.1.0+3265+26c4ed71.x86_64 as > > [1]. > > Verified with qemu-kvm-core-4.2.0-1.module+el8.2.0+4793+b09dd2fb.x86_64 as > > [2]. > > > > Hi Marc-Andre, > > > > Segmentation fault disappears, but the process quits without printing the > > monitor prompt "(qemu)". > > I think this is expected. > > Is that enough for the verification? > > Hi, yes, that should be fine. Thank you. > > thanks
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2017