Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752471AbaF0UIo (ORCPT ); Fri, 27 Jun 2014 16:08:44 -0400 Received: from mail-la0-f48.google.com ([209.85.215.48]:45339 "EHLO mail-la0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751496AbaF0UIm (ORCPT ); Fri, 27 Jun 2014 16:08:42 -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> From: Andy Lutomirski Date: Fri, 27 Jun 2014 13:08:20 -0700 Message-ID: Subject: Re: [PATCH v8 5/9] seccomp: split mode set routines To: Oleg Nesterov Cc: Kees Cook , 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 ? Yes, which is more or less the whole point of that patch series. I rewrote part of the TIF_SECCOMP-but-no-tracing case in assembly :) I'm playing with rewriting it in C, but it's looking like it'll be a bit more far-reaching than I was hoping. --Andy -- 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/