Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754035AbaF0U4u (ORCPT ); Fri, 27 Jun 2014 16:56:50 -0400 Received: from mail-ob0-f175.google.com ([209.85.214.175]:43235 "EHLO mail-ob0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753348AbaF0U4r (ORCPT ); Fri, 27 Jun 2014 16:56:47 -0400 MIME-Version: 1.0 In-Reply-To: <20140627195559.GA31661@redhat.com> References: <20140625173245.GA17695@redhat.com> <20140625175136.GA18185@redhat.com> <20140627192753.GA30752@redhat.com> <20140627195559.GA31661@redhat.com> Date: Fri, 27 Jun 2014 13:56:46 -0700 X-Google-Sender-Auth: pUW8GcfQARe8nbSPsvc5-gYYfhQ Message-ID: Subject: Re: [PATCH v8 5/9] seccomp: split mode set routines From: Kees Cook To: Oleg Nesterov Cc: Andy Lutomirski , LKML , "Michael Kerrisk (man-pages)" , Alexei Starovoitov , Andrew Morton , Daniel Borkmann , Will Drewry , Julien Tinnes , David Drysdale , Linux API , "x86@kernel.org" , "linux-arm-kernel@lists.infradead.org" , linux-mips@linux-mips.org, linux-arch , linux-security-module Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 27, 2014 at 12:55 PM, Oleg Nesterov wrote: > On 06/27, Andy Lutomirski wrote: >> >> On Fri, Jun 27, 2014 at 12:27 PM, Oleg Nesterov wrote: >> > On 06/27, Kees Cook wrote: >> >> >> >> It looks like SMP ARM issues dsb for rmb, which seems a bit expensive. >> >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204g/CIHJFGFE.htm >> >> >> >> ... >> >> >> >> I really want to avoid adding anything to the secure_computing() >> >> execution path. :( >> > >> > I must have missed something but I do not understand your concerns. >> > >> > __secure_computing() is not trivial, and we are going to execute the >> > filters. Do you really think rmb() can add the noticeable difference? >> > >> > Not to mention that we can only get here if we take the slow syscall >> > enter path due to TIF_SECCOMP... >> > >> >> On my box, with my fancy multi-phase seccomp patches, the total >> seccomp overhead for a very short filter is about 13ns. Adding a full >> barrier would add several ns, I think. > > I am just curious, does this 13ns overhead include the penalty from the > slow syscall enter path triggered by TIF_SECCOMP ? > >> Admittedly, this is x86, not ARM, so comparisons here are completely >> bogus. And that read memory barrier doesn't even need an instruction >> on x86. But still, let's try to keep this fast. > > Well, I am not going to insist... > > But imo it would be better to make it correct in a most simple way, then > we can optimize this code and see if there is a noticeable difference. > > Not only we can change the ordering, we can remove the BUG_ON's and just > accept the fact the __secure_computing() can race with sys_seccomp() from > another thread. > > If nothing else, it would be much simpler to discuss this patch if it comes > as a separate change. Yeah, the way I want to go is to add the rmb() for now (it gets us "correctness"), and then later deal with any potential performance problems on ARM at a later time. (At present, I'm unable to perform any timings on ARM -- maybe next week.) I will send the v9 series in a moment here... -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/