Bug 1177309
Summary: | Guest using rbd based image as disk failed to start when sandbox was enabled | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Yang Yang <yanyang> | ||||
Component: | qemu-kvm-rhev | Assignee: | Miroslav Rezanina <mrezanin> | ||||
Status: | CLOSED ERRATA | QA Contact: | FuXiangChun <xfu> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 7.1 | CC: | dyuan, emaldona, huding, juzhang, lhuang, mrezanin, mzhan, pmoore, virt-maint, xfu, xuzhang, yanyang | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | QEMU 2.6 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1177318 (view as bug list) | Environment: | |||||
Last Closed: | 2016-11-07 20:18:59 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: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1177318, 1288337 | ||||||
Attachments: |
|
Comment on attachment 973103 [details]
gdb
Add the version of librados2 and librbd1
librados2-0.80.7-2.el7.x86_64
librbd1-0.80.7-2.el7.x86_64
after talking with juli, we found cannot reproduce this issue with: nss-softokn-3.16.2-12.el7.x86_64 and meet this issue with: nss-softokn.3.16.2.3-4.el7 Paul, I'm a seccomp ignoramus, and could use your advice. It looks like at least some versions of some library we link with use sysinfo(), see comment#3. Should we add sysinfo() to upstream's seccomp_whitelist[]? If yes, should we backport it even though we can only reproduce the denial with an older version of nss-softokn? If current, or *close* to current, versions of nss-softokn make use of the sysinfo() syscall I would recommend adding it to the upstream whitelist. As far as RHEL is concerned, if you can't require a version of the nss-softokn library that doesn't use sysinfo() then it sounds like you'll need to add sysinfo() to the QEMU syscall whitelist. Make sense? Thanks, Paul. According to comment#3, nss-softokn-3.16.2-12.el7.x86_64 uses sysinfo(), but nss-softokn.3.16.2.3-4.el7 appears not to. The tags in https://hg.mozilla.org/projects/nss/tags show 3.16 released in March 2014, and 3.16.2 in June 2014. Current is 3.19, April 2015. Does this qualify for *close* to current? I don't know. Upstream QEMU's configure suggests 3.12.8 is supposed to work. We don't know which versions call sysinfo(). Any that do won't work when combining --sandbox with options pulling in NSS and making it call sysinfo(). We could find out, but the necessary detective work is hard to justify. I'm leaning towards letting sleeping dogs lie, unless we need to disturb them downstream anyway. Mirek, can we require a more recent version of nss? (In reply to Markus Armbruster from comment #7) > Thanks, Paul. > > According to comment#3, nss-softokn-3.16.2-12.el7.x86_64 uses > sysinfo(), but nss-softokn.3.16.2.3-4.el7 appears not to. > > The tags in https://hg.mozilla.org/projects/nss/tags show 3.16 > released in March 2014, and 3.16.2 in June 2014. Current is 3.19, > April 2015. > > Does this qualify for *close* to current? I don't know. > > Upstream QEMU's configure suggests 3.12.8 is supposed to work. We > don't know which versions call sysinfo(). Any that do won't work when > combining --sandbox with options pulling in NSS and making it call > sysinfo(). > > We could find out, but the necessary detective work is hard to > justify. I'm leaning towards letting sleeping dogs lie, unless we > need to disturb them downstream anyway. > > Mirek, can we require a more recent version of nss? We can add requirement to spec file. But I can't see nss-softokn-3.16.2-12.el7.x86_64 in brew. Latest build is nss-softokn-3.16.2.3-9.el7. Elio, will be required version available for RHEL 7.2? (In reply to Miroslav Rezanina from comment #8) > (In reply to Markus Armbruster from comment #7) > > We can add requirement to spec file. But I can't see > nss-softokn-3.16.2-12.el7.x86_64 in brew. Latest build is > nss-softokn-3.16.2.3-9.el7. > > Elio, will be required version available for RHEL 7.2? Yes, and for RHEL-7.2, and upcoming 7.1.Z, are changing nss.pec file to require a specific nss-softokn build. Extracts from a patch I'm currently working on. diff --git a/nss.spec b/nss.spec index e162476..60ce017 100644 --- a/nss.spec +++ b/nss.spec @@ -3,6 +3,8 @@ # adjust to the version that gets submitted for FIPS validation %global nss_softokn_fips_version 3.16.2 %global nss_softokn_version 3.16.2.3 +%global required_softokn_build_version -10 <------------------------ new + %global unsupported_tools_directory %{_libdir}/nss/unsupported-tools %global allTools "certutil cmsutil crlutil derdump modutil pk12util pp signtool signver ssltap vfychain vfyserv" @@ -21,14 +23,14 @@ Summary: Network Security Services Name: nss Version: 3.18.0 ............ Requires: nspr >= %{nspr_version} Requires: nss-util >= %{nss_util_version} # TODO: revert to same version as nss once we are done with the merge -Requires: nss-softokn%{_isa} >= %{nss_softokn_version} +Requires: nss-softokn%{_isa} >= %{nss_softokn_version}%{required_softokn_build_version} <--------------------------- Requires: nss-system-init Requires(post): %{_sbindir}/update-alternatives Requires(postun): %{_sbindir}/update-alternatives @@ -36,7 +38,7 @@ BuildRoot: {_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: nspr-devel >= %{nspr_version} # TODO: revert to same version as nss once we are done with the merge # Using '>=' but on RHEL the requires should be '=' -BuildRequires: nss-softokn-devel >= %{nss_softokn_version} +BuildRequires: nss-softokn-devel >= %{nss_softokn_version}%{required_softokn_build_version} <--------------------------------- .............. We have to whitelist sysinit call to be able to use rbd in sandbox mode. Moving to 7.3 as we won't be able to fix this in 7.2 timeframe. I can still reproduce it on qemu-kvm-rhev-2.3.0-31.el7.x86_64 and nss-softokn-3.16.2.3-14.el7.x86_64 Hi Miroslav, It passed on the scratch build. # rpm -q qemu-kvm-rhev qemu-kvm-rhev-2.5.0-1.el7.base.x86_64 # /usr/libexec/qemu-kvm -drive file=rbd:yy/rbd1.img:auth_supported=none:mon_host=10.73.75.54,if=none,id=drive-virtio-disk1,rerror=stop,format=raw,werror=stop -device virtio-blk-pci,drive=drive-virtio-disk1,id=sys-img -monitor stdio -spice port=5931,disable-ticketing -boot menu=on -m 2G -sandbox on QEMU 2.5.0 monitor - type 'help' for more information (qemu) info info balloon -- show balloon information info block [-n] [-v] [device] -- show info of one block device or all block devices (-n: show named nodes; -v: show details) info block-jobs -- show progress of ongoing block device operations ...... Hi Miroslav, Test results are as following. Feel free to let me know if you want much more info. # rpm -q qemu-kvm-rhev qemu-kvm-rhev-2.5.0-1.el7.base.x86_64 # strace -e trace=sysinfo /usr/libexec/qemu-kvm -drive file=rbd:yy/rbd1.img:auth_supported=none:mon_host=10.73.75.54,if=none,id=drive-virtio-disk1,rerror=stop,format=raw,werror=stop -device virtio-blk-pci,drive=drive-virtio-disk1,id=sys-img -monitor stdio -spice port=5931,disable-ticketing -boot menu=on -m 2G -sandbox on sysinfo({uptime=12574, loads=[192, 960, 2976] totalram=8077160448, freeram=6515691520, sharedram=0, bufferram=962560} totalswap=0, freeswap=0, procs=394}) = 0 sysinfo({uptime=12574, loads=[192, 960, 2976] totalram=8077160448, freeram=6515691520, sharedram=0, bufferram=962560} totalswap=0, freeswap=0, procs=394}) = 0 QEMU 2.5.0 monitor - type 'help' for more information (qemu) warning: host doesn't support requested feature: CPUID.80000001H:ECX.abm [bit 5] warning: host doesn't support requested feature: CPUID.80000001H:ECX.sse4a [bit 6] (qemu) Thanks verified the bug with qemu-kvm-rhev-2.6.0-22.el7.x86_64. /usr/libexec/qemu-kvm -drive file=rbd:libvirt-pool/rhel.raw:mon_host=10.66.144.26,if=none,id=drive-virtio-disk1,rerror=stop,format=raw,werror=stop -device virtio-blk-pci,drive=drive-virtio-disk1,id=sys-img -monitor stdio -boot menu=on -m 2G -vnc :1 -sandbox on guest and qemu-kvm-rhev work well. so,this bug is fixed. 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://rhn.redhat.com/errata/RHBA-2016-2673.html |
Created attachment 973103 [details] gdb Description of problem: Guest using rbd based image as disk failed to start when sandbox was enabled Version-Release number of selected component (if applicable): libvirt-1.2.8-11.el7.x86_64 qemu-kvm-rhev-2.1.2-17.el7.x86_64 3.10.0-219.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.try to start vm with sandbox enabled # /usr/libexec/qemu-kvm -drive file=rbd:libvirt-pool/yy1.img:auth_supported=none:mon_host=$ip,if=none,id=drive-virtio-disk1,rerror=stop,format=raw,werror=stop -device virtio-blk-pci,drive=drive-virtio-disk1,id=sys-img -monitor stdio -spice port=5931,disable-ticketing -boot menu=on -m 2G -sandbox on 1>out 2>err # cat out # cat err No output Actual results: qemu hang Expected results: Additional info: from audit.log: type=SECCOMP msg=audit(1419517736.701:315758): auid=0 uid=0 gid=0 ses=1227 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=19319 comm="qemu-kvm" sig=31 arch=c000003e syscall=99 compat=0 ip=0x7ffff0a7bae7 code=0x0 lhuang found that qemu uses seccomp_sandbox and set white system call list in qemu-seccomp.c. and when qemu call rados_connect(not a qemu func) in qemu_rbd_open, and after a loooot of func, GiveSystemInfo use sysinfo which is not in seccomp_whitelist[]. so qemu-kvm have been killed because use a syscall out of whitelist.