Bug 1800495

Summary:	Missing valgrind seccomp support causes qemu guest failed to boot up with “-sandbox=on”
Product:	Red Hat Enterprise Linux 8	Reporter:	Yiqian Wei <yiwei>
Component:	valgrind	Assignee:	Mark Wielaard <mjw>
valgrind sub component:	system-version	QA Contact:	qe-baseos-tools-bugs
Status:	CLOSED CANTFIX	Docs Contact:
Severity:	low
Priority:	low	CC:	chayang, coli, ehabkost, fweimer, jakub, jinzhao, juzhang, ohudlick, virt-maint, xfu, yiwei
Version:	---	Keywords:	FutureFeature, Triaged
Target Milestone:	rc	Flags:	pm-rhel: mirror+
Target Release:	8.0
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-02-19 10:01:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Yiqian Wei 2020-02-07 09:32:09 UTC

Description of problem:
Guest failed to boot up with valgrind tool and “-sandbox=on”

Version-Release number of selected component (if applicable):
host version:
qemu-kvm-4.2.0-8.module+el8.2.0+5607+dc756904.x86_64
kernel-4.18.0-175.el8.x86_64
seabios-1.13.0-1.module+el8.2.0+5520+4e5817f3.x86_64
valgrind-3.15.0-10.el8.x86_64

How reproducible:
100%

Steps to Reproduce:
1.start a guest with valgrind tool and "-sandbox=on"
cmd:  
valgrind  /usr/libexec/qemu-kvm -vnc :1 -monitor stdio  -m 384 -sandbox on

Actual results:Guest failed to boot up

# valgrind /usr/libexec/qemu-kvm -sandbox on -vnc :1 -monitor stdio  -m 384 
==32337== Memcheck, a memory error detector
==32337== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==32337== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==32337== Command: /usr/libexec/qemu-kvm -sandbox on -vnc :1 -monitor stdio -m 384
==32337== 
--32337-- WARNING: unhandled amd64-linux syscall: 317
--32337-- You may be able to write your own handler.
--32337-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--32337-- Nevertheless we consider this a bug.  Please report
--32337-- it at http://valgrind.org/support/bug_reports.html.
qemu-kvm: -sandbox on: There is no option group 'sandbox'
==32337== 
==32337== HEAP SUMMARY:
==32337==     in use at exit: 363,168 bytes in 3,021 blocks
==32337==   total heap usage: 4,096 allocs, 1,075 frees, 594,029 bytes allocated
==32337== 
==32337== LEAK SUMMARY:
==32337==    definitely lost: 0 bytes in 0 blocks
==32337==    indirectly lost: 0 bytes in 0 blocks
==32337==      possibly lost: 1,832 bytes in 19 blocks
==32337==    still reachable: 361,336 bytes in 3,002 blocks
==32337==                       of which reachable via heuristic:
==32337==                         newarray           : 1,536 bytes in 16 blocks
==32337==         suppressed: 0 bytes in 0 blocks
==32337== Rerun with --leak-check=full to see details of leaked memory
==32337== 
==32337== For lists of detected and suppressed errors, rerun with: -s
==32337== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


Expected results:
Guest can boot up with valgrind tool and "-sandbox=on"

Additional info:
1)with valgrind tool and "-sandbox=off",reproduce this bug.

Comment 1 Yiqian Wei 2020-02-07 10:18:54 UTC

1. didn't reproduce it only with "sandbox=on/off" 
2. it's not a regression issue since can reproduce it on "qemu-kvm-4.1.0-23.module+el8.1.1+5467+ba2d821b.x86_64" version

Comment 3 Dr. David Alan Gilbert 2020-02-12 09:27:08 UTC

The unhandled syscall is coming from valgrind and 317 is seccomp.

QEMU probes to see if it has seccomp and fails, so doesn't add the sandbox options which is why we get the error:

'qemu-kvm: -sandbox on: There is no option group 'sandbox''

so from QEMU's point of view this is just missing sandbox support.

So it looks like Valgrind is missing seccomp support.
I see an upstream valgrind bug; https://bugs.kde.org/show_bug.cgi?id=380183
But really this is a feature request for it.

I'll flip this to valgrind - NOT_A_QEMU_BUG.

Comment 4 Mark Wielaard 2020-02-12 09:49:16 UTC

seccomp is a little tricky for valgrind since valgrind itself might use system calls not used by the application running under valgrind (they share the same process and address space). And the arguments are also tricky to interpret since depending on operation and flags this might be an arbitrary BPF program. We could simply return ENOSYS for seccomp and not produce the error/warning message. But I assume that doesn't really help in this case.

Comment 5 Eduardo Habkost 2020-02-12 19:07:58 UTC

Marking as feature request, lowering priority and severity.

Comment 6 Mark Wielaard 2020-02-19 10:01:18 UTC

Marking this closed cantfix because it is not clear how to provide this feature. There is an upstream bug that has more discussion: https://bugs.kde.org/show_bug.cgi?id=345414

Please do reopen this bug if you really need this feature.