Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3275103imm; Sun, 30 Sep 2018 16:25:50 -0700 (PDT) X-Google-Smtp-Source: ACcGV620HjtC/PCodgmms+lp4G/pye05YXFQn1KrYs4gEhguSHoMPsAnrK0E3G1SvvWdHOEXcr0t X-Received: by 2002:a62:42d4:: with SMTP id h81-v6mr7277340pfd.0.1538349950219; Sun, 30 Sep 2018 16:25:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538349950; cv=none; d=google.com; s=arc-20160816; b=paAiwtoKUzKpw+Pfy6gVhlJKnDxZe+qnQIlVczQS24r4XwhGyL+lHnD5iBwgdS6lKO RyFud9IW9h5y09UlWotxdwrguZGoRzyvnOFB6Lwefl9UzhETdzwEaZgOE7iTgiUaIthU sQrtOXXOzRCzM63BHSyjrhwFBoTD0IW/Kxdi3kZcFx86EW0T9O+OHvo3uvPhUI471IAx PQ11FedT+w2pwbJHvAGNj4fmg32yx2E8rY+0gt6m6leO0AZ9yo/wj8PoWcUoDUF38jSc VCQ8e0+lh07rJDwdHn3MEipt62pKQwFw97pVwhU3Hz+m7AzreuJLDjYEezrWmY1Ee/iH he2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=RtADkcxQvf7pXZGGkIH/4OOQehaLE+/E8VPwtX5UFhA=; b=S31PK0JGEd0F5Vjr1/q5aId7t0df4tU1pvf5NrpjEd6wH8ASS1S0G4Z+ySRfRRpptW MyQwy3XyuN1fCZffYh+eUAkxnA/8kTwYYlk+RaCCl/ebEFIjjqBvitccC1sof5kg5Fcs deiXOyiM7jeCPt7jW9F+PnwtH95JL8ROa2jp5Yvp+eudd1q/WTkXcrscyTiFpN4IDPXV EVMiV/cxvnzYKnZSkoa7TxWQEb6A3G6umB8MW1JBqS5icGqxSLm+x6yprYTZbJOrcNto cnn2GPvLZFwTFV0MGdWR3UgBbsO7sLe/Lx9NaMT4l7lmURDPm+ZQIk1daX3whE+QCtH+ TDFw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y27-v6si10721660pgl.479.2018.09.30.16.25.34; Sun, 30 Sep 2018 16:25:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726930AbeJAGAZ (ORCPT + 99 others); Mon, 1 Oct 2018 02:00:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:57258 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726261AbeJAGAZ (ORCPT ); Mon, 1 Oct 2018 02:00:25 -0400 Received: from vmware.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 439DF20666; Sun, 30 Sep 2018 23:25:28 +0000 (UTC) Date: Sun, 30 Sep 2018 19:25:26 -0400 From: Steven Rostedt To: Kees Cook Cc: James Morris , "Serge E. Hallyn" , Abderrahmane Benbachir , linux-security-module , Casey Schaufler , John Johansen , Tetsuo Handa , Paul Moore , Stephen Smalley , "Schaufler, Casey" , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML Subject: Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing Message-ID: <20180930192526.4480231c@vmware.local.home> In-Reply-To: References: <20180925001832.18322-1-keescook@chromium.org> <20180925001832.18322-5-keescook@chromium.org> <20180926123522.4080d9eb@vmware.local.home> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 26 Sep 2018 11:35:21 -0700 Kees Cook wrote: > On Wed, Sep 26, 2018 at 9:35 AM, Steven Rostedt wrote: > > On Mon, 24 Sep 2018 17:18:07 -0700 > > Kees Cook wrote: > > > >> This partially reverts commit 58eacfffc417 ("init, tracing: instrument > >> security and console initcall trace events") since security init calls > >> are about to no longer resemble regular init calls. > > > > I'm not against the change, but how much are they going to "no longer > > resemble regular init calls"? > > My take on "regular" init calls is that they're always run, link-time > ordered, etc. The changes proposed here will make it so not all > initialization are run depending on runtime configurations, ordering > will be flexible, etc. > Will it still be a good idea to have a tracepoint for those calls? Perhaps not an initcall tracepoint but some other kind? -- Steve