Bug 1425007

The upstream libseccomp project has supported ppc, ppc64, and ppc64le since libseccomp v2.3.0 which was released on February 29th, 2016.  Enabling support for RHEL-7.x is more of a business decision than a technical hurdle (as you found out be removing the build restriction).

I'm setting the devel_ack flag, and I'm going to ping PM/management to see what needs to be done.  If you can escalate this on your end to get the necessary approvals that would be helpful too.

* https://github.com/seccomp/libseccomp/releases/tag/v2.3.0

Excellent, thanks! mclasen said he'd bring this up at a meeting with pm on Wednesday.

(In reply to Paul Moore from comment #2)
> The upstream libseccomp project has supported ppc, ppc64, and ppc64le since
> libseccomp v2.3.0 which was released on February 29th, 2016.  Enabling
> support for RHEL-7.x is more of a business decision than a technical hurdle
> (as you found out be removing the build restriction).
> 
> I'm setting the devel_ack flag, and I'm going to ping PM/management to see
> what needs to be done.  If you can escalate this on your end to get the
> necessary approvals that would be helpful too.
> 
> * https://github.com/seccomp/libseccomp/releases/tag/v2.3.0

Hi, Paul

Could I know what testing need to be done for virt for the ppc arch? Since currently only ppc64 (guest side) and ppc64le (host and guest) will be covered for kvm feature testing.  Thanks!

Hello,

Unfortunately I don't know how libseccomp is tested here inside RH.  To be honest the testing responsibilities probably shouldn't reside solely with the virt team as libseccomp now has a number of users beyond virtualization, flatpack is just one example.

Upstream we have a bundled test suite with both simulated and live tests (see the "tests" directory) and we've recently added Travis CI builds that execute the test suite as well as the clang and Coverity static analyzers.

I'm sorry this probably doesn't answer your question very well ...

Hi, Paul

Thanks for your explanation, I would ack this bug now and will do the following test as verification result:
(1) check whether the expected build appears in brewweb.
(2) make sure it's included in the install tree.

So, if this is not enough pls help inform related team for extra testing. It sounds great for the test suite in Travis CI builds.

(In reply to Qunfang Zhang from comment #6)
> Hi, Paul
> 
> Thanks for your explanation, I would ack this bug now and will do the
> following test as verification result:
> (1) check whether the expected build appears in brewweb.
> (2) make sure it's included in the install tree.
> 
> So, if this is not enough pls help inform related team for extra testing. It
> sounds great for the test suite in Travis CI builds.

While we run the simulated tests as part of the RPM build process, we don't run the "live" tests for a variety of reasons.  If you have the time, it might be helpful to download the associated release tarball from upstream and verify the live tests on a ppc64/ppc64le system.  You can do that with the following commands (assuming you have downloaded and unpacked the tarball already):

  # ./configure
  # make check-build
  # cd tests
  # ./regression -T live

If you have any questions, let me know.

Hi Paul,

A. We have done sandybox(syscall filter) testing with package libseccomp-2.3.1-3.el7.ppc64le.rpm installed in host(has been added to compose). No regression bug found. So I think it's ok for virt side.

B. I did  regression live test with our internal package. steps and results are as follows:
  step1: wget libseccomp-2.3.1-3.el7.src.rpm from our brew web.
  step2: # rpm2cpio libseccomp-2.3.1-3.el7.src.rpm | cpio -div
  step3: unzip the tar file generated in step2
         #tar -zxvf libseccomp-2.3.1.tar.gz
  step4: #cd libseccomp-2.3.1
  step5: #./configure; make check-build
  step6: #cd tests
  step7: #./regression -T live
1 of 6 runs tested failed, 5 others passed. I will attach the full result.

I am not sure whether the failed cases matter so much or not.
what's your opinion, Paul? If that does not matter or be expected. I will set the bug verified.

I tried with uptream package. got the same result.

Created attachment 1284371 [details]
Regression live test result

Hi Zhengtong,

That single failure is expected on RHEL-7.x since the current RHEL-7.x kernels do not currently support the SECCOMP_FILTER_FLAG_TSYNC functionality.  This is a kernel issue and not a libseccomp issue.

I went ahead and created a RFE BZ for the seccomp-bpf TSYNC functionality:

* https://bugzilla.redhat.com/show_bug.cgi?id=1458278

Thanks Paul. then verified the bug.

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/RHEA-2017:2165