From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751158AbdFXEnx (ORCPT ); Sat, 24 Jun 2017 00:43:53 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:45004 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766AbdFXEnw (ORCPT ); Sat, 24 Jun 2017 00:43:52 -0400 Date: Sat, 24 Jun 2017 06:43:43 +0200 From: Greg Kroah-Hartman To: Andy Lutomirski Cc: Kees Cook , Shuah Khan , Sumit Semwal , Brian Norris , "Luis R. Rodriguez" , LKML , "# 3.4.x" , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan Subject: Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures] Message-ID: <20170624044343.GC10973@kroah.com> References: <334e6a92-2d41-c9e1-c807-19e493f1af83@kernel.org> <20170623015251.GA23574@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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