linux-kernel - Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170623015251.GA23574@kroah.com>
Date:   Fri, 23 Jun 2017 09:52:51 +0800
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Andy Lutomirski <luto@...nel.org>, Shuah Khan <shuah@...nel.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Brian Norris <computersforpeace@...il.com>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "# 3.4.x" <stable@...r.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        Shuah Khan <shuahkh@....samsung.com>
Subject: Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS
 testing with latest kselftests - some failures]

On Thu, Jun 22, 2017 at 10:50:43AM -0700, Kees Cook wrote:
> On Thu, Jun 22, 2017 at 10:49 AM, Andy Lutomirski <luto@...nel.org> wrote:
> > On Thu, Jun 22, 2017 at 10:09 AM, Shuah Khan <shuah@...nel.org> wrote:
> >> On 06/22/2017 10:53 AM, Kees Cook wrote:
> >>> On Thu, Jun 22, 2017 at 9:18 AM, Sumit Semwal <sumit.semwal@...aro.org> wrote:
> >>>> Hi Kees, Andy,
> >>>>
> >>>> On 15 June 2017 at 23:26, Sumit Semwal <sumit.semwal@...aro.org> wrote:
> >>>>> 3. 'seccomp ptrace hole closure' patches got added in 4.7 [3] -
> >>>>> feature and test together.
> >>>>> - This one also seems like a security hole being closed, and the
> >>>>> 'feature' could be a candidate for stable backports, but Arnd tried
> >>>>> that, and it was quite non-trivial. So perhaps  we'll need some help
> >>>>> from the subsystem developers here.
> >>>>
> >>>> Could you please help us sort this out? Our goal is to help Greg with
> >>>> testing stable kernels, and currently the seccomp tests fail due to
> >>>> missing feature (seccomp ptrace hole closure) getting tested via
> >>>> latest kselftest.
> >>>>
> >>>> If you feel the feature isn't a stable candidate, then could you
> >>>> please help make the test degrade gracefully in its absence?
> >>>
> >>> I don't really want to have that change be a backport -- it's quite
> >>> invasive across multiple architectures.
> >>>
> >>> I would say just add a kernel version check to the test. This is
> >>> probably not the only selftest that will need such things. :)
> >>
> >> Adding release checks to selftests is going to problematic for maintenance.
> >> Tests should fail gracefully if feature isn't supported in older kernels.
> >>
> >> Several tests do that now and please find a way to check for dependencies
> >> and feature availability and fail the test gracefully. If there is a test
> >> that can't do that for some reason, we can discuss it, but as a general
> >> rule, I don't want to see kselftest patches that check release.
> >
> > If a future kernel inadvertently loses the new feature and degrades to
> > the behavior of old kernels, that would be a serious bug and should be
> > caught.
> 
> Right. I really think stable kernels should be tested with their own
> selftests. If some test is needed in a stable kernel it should be
> backported to that stable kernel.

Well, ideally all new features added to the kernel should be able to be
detected by userspace somehow if they are present or not.

How do you expect a program to know if a feature has "failed" or is just
"not enabled/present in this kernel"?  Normally with syscalls this is
easy, same for sysfs changes.  Is seccomp in the bad state where there
is no way to detect the two different states here?  How is userspace
supposed to deal with that?

We make fun of glibc having a zillion crazy tests to determine kernel
features, and recently, just not wrapping new syscalls at all because
they are just frustrated at the compatibility issues over time.  Let's
not make their life any harder than it has to be please.

I don't see how any of the kselftest programs are any different than any
other userspace program that wants to use our kernel api, and as such,
any version of kselftest should be able to successfully run on any
kernel release.  If not, then we messed up in how we either wrote the
test, or how we added a new kernel api.  Neither is acceptable.

thanks,

greg k-h