From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1CDAC433EF for ; Mon, 27 Jun 2022 07:37:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233004AbiF0Hhi (ORCPT ); Mon, 27 Jun 2022 03:37:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232965AbiF0Hhe (ORCPT ); Mon, 27 Jun 2022 03:37:34 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D5A760D5; Mon, 27 Jun 2022 00:37:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EA81561369; Mon, 27 Jun 2022 07:37:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A45D7C341C8; Mon, 27 Jun 2022 07:37:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656315451; bh=DsZDqRgytXwZKzppv5E+EkTb1K4NGGC2jAstmBQ31VE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i3ldFsiGRWyUL2/7EHUzj3ADKKVrTcF+8yJXjybLKY3QJPs/zZsAplrMS1PPI5PYs 4Q5txUsaV5n7fPa9vtZErhohoGy5ahsFShlfNq5dXajY7pEAtLxWvu5a2waWGEX43C Whe69Fv6I/yDBYJrkHxRnOpS0OVtoN/TI1fMRHN0= Date: Mon, 27 Jun 2022 09:37:28 +0200 From: Greg Kroah-Hartman To: Mimi Zohar Cc: James Bottomley , Nayna Jain , linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-efi@vger.kernel.org, linux-security-module , linux-kernel@vger.kernel.org, Michael Ellerman , Dov Murik , George Wilson , gjoyce@ibm.com, Matthew Garrett , Dave Hansen , Benjamin Herrenschmidt , Paul Mackerras Subject: Re: [RFC PATCH v2 2/3] fs: define a firmware security filesystem named fwsecurityfs Message-ID: References: <20220622215648.96723-1-nayna@linux.ibm.com> <20220622215648.96723-3-nayna@linux.ibm.com> <41ca51e8db9907d9060cc38adb59a66dcae4c59b.camel@HansenPartnership.com> <54af4a92356090d88639531413ea8cb46837bd18.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54af4a92356090d88639531413ea8cb46837bd18.camel@linux.ibm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jun 26, 2022 at 11:48:06AM -0400, Mimi Zohar wrote: > On Thu, 2022-06-23 at 09:23 -0400, James Bottomley wrote: > > On Thu, 2022-06-23 at 10:54 +0200, Greg Kroah-Hartman wrote: > > [...] > > > > diff --git a/fs/fwsecurityfs/inode.c b/fs/fwsecurityfs/inode.c > > > > new file mode 100644 > > > > index 000000000000..5d06dc0de059 > > > > --- /dev/null > > > > +++ b/fs/fwsecurityfs/inode.c > > > > @@ -0,0 +1,159 @@ > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > +/* > > > > + * Copyright (C) 2022 IBM Corporation > > > > + * Author: Nayna Jain > > > > + */ > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > + > > > > +#include "internal.h" > > > > + > > > > +int fwsecurityfs_remove_file(struct dentry *dentry) > > > > +{ > > > > + drop_nlink(d_inode(dentry)); > > > > + dput(dentry); > > > > + return 0; > > > > +}; > > > > +EXPORT_SYMBOL_GPL(fwsecurityfs_remove_file); > > > > + > > > > +int fwsecurityfs_create_file(const char *name, umode_t mode, > > > > + u16 filesize, struct dentry > > > > *parent, > > > > + struct dentry *dentry, > > > > + const struct file_operations > > > > *fops) > > > > +{ > > > > + struct inode *inode; > > > > + int error; > > > > + struct inode *dir; > > > > + > > > > + if (!parent) > > > > + return -EINVAL; > > > > + > > > > + dir = d_inode(parent); > > > > + pr_debug("securityfs: creating file '%s'\n", name); > > > > > > Did you forget to call simple_pin_fs() here or anywhere else? > > > > > > And this can be just one function with the directory creation file, > > > just check the mode and you will be fine. Look at securityfs as an > > > example of how to make this simpler. > > > > Actually, before you go down this route can you consider the namespace > > ramifications. In fact we're just having to rework securityfs to pull > > out all the simple_pin_... calls because simple_pin_... is completely > > inimical to namespaces. > > > > The first thing to consider is if you simply use securityfs you'll > > inherit all the simple_pin_... removal work and be namespace ready. It > > could be that creating a new filesystem that can't be namespaced is the > > right thing to do here, but at least ask the question: would we ever > > want any of these files to be presented selectively inside containers? > > If the answer is "yes" then simple_pin_... is the wrong interface. > > Greg, the securityfs changes James is referring to are part of the IMA > namespacing patch set: > https://lore.kernel.org/linux-integrity/20220420140633.753772-1-stefanb@linux.ibm.com/ > > I'd really appreciate your reviewing the first two patches: > [PATCH v12 01/26] securityfs: rework dentry creation > [PATCH v12 02/26] securityfs: Extend securityfs with namespacing > support Looks like others have already reviewed them, they seem sane to me if they past testing. thanks, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AB58FC43334 for ; Mon, 27 Jun 2022 07:38:13 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4LWfj022gzz3cgH for ; Mon, 27 Jun 2022 17:38:12 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=i3ldFsiG; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linuxfoundation.org (client-ip=2604:1380:4641:c500::1; helo=dfw.source.kernel.org; envelope-from=gregkh@linuxfoundation.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=i3ldFsiG; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4LWfhH5bYFz2yn5 for ; Mon, 27 Jun 2022 17:37:35 +1000 (AEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E8ABF61348; Mon, 27 Jun 2022 07:37:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A45D7C341C8; Mon, 27 Jun 2022 07:37:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656315451; bh=DsZDqRgytXwZKzppv5E+EkTb1K4NGGC2jAstmBQ31VE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i3ldFsiGRWyUL2/7EHUzj3ADKKVrTcF+8yJXjybLKY3QJPs/zZsAplrMS1PPI5PYs 4Q5txUsaV5n7fPa9vtZErhohoGy5ahsFShlfNq5dXajY7pEAtLxWvu5a2waWGEX43C Whe69Fv6I/yDBYJrkHxRnOpS0OVtoN/TI1fMRHN0= Date: Mon, 27 Jun 2022 09:37:28 +0200 From: Greg Kroah-Hartman To: Mimi Zohar Subject: Re: [RFC PATCH v2 2/3] fs: define a firmware security filesystem named fwsecurityfs Message-ID: References: <20220622215648.96723-1-nayna@linux.ibm.com> <20220622215648.96723-3-nayna@linux.ibm.com> <41ca51e8db9907d9060cc38adb59a66dcae4c59b.camel@HansenPartnership.com> <54af4a92356090d88639531413ea8cb46837bd18.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54af4a92356090d88639531413ea8cb46837bd18.camel@linux.ibm.com> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dov Murik , linux-efi@vger.kernel.org, Matthew Garrett , Nayna Jain , linux-kernel@vger.kernel.org, James Bottomley , Dave Hansen , linux-security-module , Paul Mackerras , linux-fsdevel@vger.kernel.org, George Wilson , linuxppc-dev@lists.ozlabs.org, gjoyce@ibm.com Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Sun, Jun 26, 2022 at 11:48:06AM -0400, Mimi Zohar wrote: > On Thu, 2022-06-23 at 09:23 -0400, James Bottomley wrote: > > On Thu, 2022-06-23 at 10:54 +0200, Greg Kroah-Hartman wrote: > > [...] > > > > diff --git a/fs/fwsecurityfs/inode.c b/fs/fwsecurityfs/inode.c > > > > new file mode 100644 > > > > index 000000000000..5d06dc0de059 > > > > --- /dev/null > > > > +++ b/fs/fwsecurityfs/inode.c > > > > @@ -0,0 +1,159 @@ > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > +/* > > > > + * Copyright (C) 2022 IBM Corporation > > > > + * Author: Nayna Jain > > > > + */ > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > + > > > > +#include "internal.h" > > > > + > > > > +int fwsecurityfs_remove_file(struct dentry *dentry) > > > > +{ > > > > + drop_nlink(d_inode(dentry)); > > > > + dput(dentry); > > > > + return 0; > > > > +}; > > > > +EXPORT_SYMBOL_GPL(fwsecurityfs_remove_file); > > > > + > > > > +int fwsecurityfs_create_file(const char *name, umode_t mode, > > > > + u16 filesize, struct dentry > > > > *parent, > > > > + struct dentry *dentry, > > > > + const struct file_operations > > > > *fops) > > > > +{ > > > > + struct inode *inode; > > > > + int error; > > > > + struct inode *dir; > > > > + > > > > + if (!parent) > > > > + return -EINVAL; > > > > + > > > > + dir = d_inode(parent); > > > > + pr_debug("securityfs: creating file '%s'\n", name); > > > > > > Did you forget to call simple_pin_fs() here or anywhere else? > > > > > > And this can be just one function with the directory creation file, > > > just check the mode and you will be fine. Look at securityfs as an > > > example of how to make this simpler. > > > > Actually, before you go down this route can you consider the namespace > > ramifications. In fact we're just having to rework securityfs to pull > > out all the simple_pin_... calls because simple_pin_... is completely > > inimical to namespaces. > > > > The first thing to consider is if you simply use securityfs you'll > > inherit all the simple_pin_... removal work and be namespace ready. It > > could be that creating a new filesystem that can't be namespaced is the > > right thing to do here, but at least ask the question: would we ever > > want any of these files to be presented selectively inside containers? > > If the answer is "yes" then simple_pin_... is the wrong interface. > > Greg, the securityfs changes James is referring to are part of the IMA > namespacing patch set: > https://lore.kernel.org/linux-integrity/20220420140633.753772-1-stefanb@linux.ibm.com/ > > I'd really appreciate your reviewing the first two patches: > [PATCH v12 01/26] securityfs: rework dentry creation > [PATCH v12 02/26] securityfs: Extend securityfs with namespacing > support Looks like others have already reviewed them, they seem sane to me if they past testing. thanks, greg k-h