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-rhevAssignee: Miroslav Rezanina <mrezanin>
Status: CLOSED ERRATA QA Contact: FuXiangChun <xfu>
Severity: high Docs Contact:
Priority: high    
Version: 7.1CC: 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:
Description Flags
gdb none

Description Yang Yang 2014-12-26 03:40:28 UTC
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.

Comment 2 Yang Yang 2014-12-26 05:28:14 UTC
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

Comment 3 Luyao Huang 2015-01-04 10:20:23 UTC
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

Comment 5 Markus Armbruster 2015-05-06 15:44:16 UTC
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?

Comment 6 Paul Moore 2015-05-06 16:39:46 UTC
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?

Comment 7 Markus Armbruster 2015-05-19 09:07:08 UTC
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?

Comment 8 Miroslav Rezanina 2015-05-19 10:09:05 UTC
(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?

Comment 9 Elio Maldonado Batiz 2015-05-19 14:55:32 UTC
(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} <---------------------------------
 ..............

Comment 10 Miroslav Rezanina 2015-09-08 08:40:40 UTC
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.

Comment 13 Yang Yang 2016-02-15 03:07:59 UTC
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

Comment 15 Yang Yang 2016-03-07 07:46:41 UTC
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
......

Comment 17 Yang Yang 2016-03-21 09:37:03 UTC
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

Comment 19 FuXiangChun 2016-09-06 14:54:05 UTC
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.

Comment 21 errata-xmlrpc 2016-11-07 20:18:59 UTC
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