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