From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751861AbdGEPAC (ORCPT ); Wed, 5 Jul 2017 11:00:02 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:33159 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751716AbdGEO77 (ORCPT ); Wed, 5 Jul 2017 10:59:59 -0400 MIME-Version: 1.0 In-Reply-To: <20170624044343.GC10973@kroah.com> References: <334e6a92-2d41-c9e1-c807-19e493f1af83@kernel.org> <20170623015251.GA23574@kroah.com> <20170624044343.GC10973@kroah.com> From: Sumit Semwal Date: Wed, 5 Jul 2017 20:29:37 +0530 Message-ID: Subject: Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures] To: Greg Kroah-Hartman Cc: Andy Lutomirski , Kees Cook , Shuah Khan , Brian Norris , "Luis R. Rodriguez" , LKML , "# 3.4.x" , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andy, On 24 June 2017 at 10:13, Greg Kroah-Hartman 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.