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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 5 Jul 2017 20:29:37 +0530
From:   Sumit Semwal <sumit.semwal@...aro.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Shuah Khan <shuah@...nel.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]

Hi Andy,

On 24 June 2017 at 10:13, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> On Thu, Jun 22, 2017 at 07:40:49PM -0700, Andy Lutomirski wrote:
>> Greg, for context, the issue here is that we made what was arguably a
>> design error in seccomp's interaction with ptrace.  After determining
>> that fixing it solved a bunch of problems and didn't break any user
>> programs, we fixed it.  There might be new code that relies on the fix
>> being present in the sense that it would be insecure without the fix.
>>
>> The problem is that the fix is moderately intrusive and doesn't seem
>> like a great candidate for backporting, although we could plausibly do
>> it.
>
> That's fine, not all bugfixes that tests are created to find, should be
> backported.  That's up to the stable maintainers, or someone who has a
> device/vendor tree based on that kernel if they want to do that or not.
>
> That has nothing to do with the fact that the test should fail or
> gracefully degrade.  Tests should fail if the action that they are
> testing fails.  They should degrade and not run if the _feature_ they
> are testing is not present.

So, any updates on this yet - getting the seccomp tests to degrade
gracefully? I realise you mentioned that the fix could be intrusive;
just wanted to know if it was on your radar still.
>
> Yes, sometimes this is hard, like with the seccomp stuff, and will not
> always work, but that's the rule for our userspace api independant of
> any testing framework or code.
>
> Look at xfstests, no one gets mad when it adds a new test that old
> kernels fail at.  It's up to someone else to either backport the kernel
> change, if they want it fixed in an old kernel, not to have xfstests
> just not run it at all!  There's nothing different here either.
>
> thanks,
>
> greg k-h

Thanks much,
Sumit.