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 CA615C433FE for ; Wed, 23 Nov 2022 15:58:43 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4NHQlj6ncJz3ccv for ; Thu, 24 Nov 2022 02:58:41 +1100 (AEDT) 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=mhiplsOi; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linuxfoundation.org (client-ip=145.40.68.75; helo=ams.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=mhiplsOi; dkim-atps=neutral Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) (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 4NHQkj3SZxz3045 for ; Thu, 24 Nov 2022 02:57:48 +1100 (AEDT) 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 ams.source.kernel.org (Postfix) with ESMTPS id 5D2C3B82141; Wed, 23 Nov 2022 15:57:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2E49C433C1; Wed, 23 Nov 2022 15:57:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1669219063; bh=Q0SEQR3uc6eCtl05I/8Xe29JQKDtlOnHtgnxpmvfeK0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mhiplsOioxUX4b7OWO/JF0jiV4e9OaOyeXb1vLr7BIXe2hSqp14HiG3LS60tfKiXR XYHklTI6LnIYJ+JdVdOx89JEMI34ZRFLWpqBlzMQsRqI8TmEAFjO9/8CnTgju7xKis AnxSbQ0zYNV4rEJno4YOqL/ulKqGxpwcGux1giIg= Date: Wed, 23 Nov 2022 16:57:40 +0100 From: Greg Kroah-Hartman To: Nayna Subject: Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs Message-ID: References: <20221106210744.603240-1-nayna@linux.ibm.com> <20221106210744.603240-3-nayna@linux.ibm.com> <8447a726-c45d-8ebb-2a74-a4d759631e64@linux.vnet.ibm.com> <20221119114234.nnfxsqx4zxiku2h6@riteshh-domain>

MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: Matthew Garrett , linux-efi@vger.kernel.org, Andrew Donnellan , Nayna Jain , "Ritesh Harjani \(IBM\)" , linux-kernel@vger.kernel.org, npiggin@gmail.com, Dov Murik , Dave Hansen , linux-security-module , Paul Mackerras , linux-fsdevel@vger.kernel.org, George Wilson , linuxppc-dev@lists.ozlabs.org, "Serge E. Hallyn" , Stefan Berger Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Nov 23, 2022 at 10:05:49AM -0500, Nayna wrote: > > On 11/22/22 18:21, Nayna wrote: > > > > From the perspective of our use case, we need to expose firmware > > security objects to userspace for management. Not all of the objects > > pre-exist and we would like to allow root to create them from userspace. > > > > From a unification perspective, I have considered a common location at > > /sys/firmware/security for managing any platform's security objects. And > > I've proposed a generic filesystem, which could be used by any platform > > to represent firmware security objects via /sys/firmware/security. > > > > Here are some alternatives to generic filesystem in discussion: > > > > 1. Start with a platform-specific filesystem. If more platforms would > > like to use the approach, it can be made generic. We would still have a > > common location of /sys/firmware/security and new code would live in > > arch. This is my preference and would be the best fit for our use case. > > > > 2. Use securityfs. This would mean modifying it to satisfy other use > > cases, including supporting userspace file creation. I don't know if the > > securityfs maintainer would find that acceptable. I would also still > > want some way to expose variables at /sys/firmware/security. > > > > 3. Use a sysfs-based approach. This would be a platform-specific > > implementation. However, sysfs has a similar issue to securityfs for > > file creation. When I tried it in RFC v1[1], I had to implement a > > workaround to achieve that. > > > > [1] https://lore.kernel.org/linuxppc-dev/20220122005637.28199-3-nayna@linux.ibm.com/ > > > Hi Greg, > > Based on the discussions so far, is Option 1, described above, an acceptable > next step? No, as I said almost a year ago, I do not want to see platform-only filesystems going and implementing stuff that should be shared by all platforms. thanks, greg k-h