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 B1DCEC4332F for ; Mon, 21 Nov 2022 18:13:38 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4NGFrK0JTvz3cR7 for ; Tue, 22 Nov 2022 05:13:37 +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=ev62ZYHq; 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=ev62ZYHq; 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 4NGFqK1b82z2xDv for ; Tue, 22 Nov 2022 05:12:45 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 3ED98613DC; Mon, 21 Nov 2022 18:12:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 092D4C433D7; Mon, 21 Nov 2022 18:12:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1669054360; bh=3hKMiUWSJlNUwha4kRCYF6DVvlsHYc9XldvHrQoGMS0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ev62ZYHqi31e22gyDngGK7EIfQceHN+E3DDkSWP1G3IXOBeCWfQmDmemGbtRgLukA PMGWLB5QgVoQQljqfoH29fsa4KLSPEWOOnpn5Aiaqd8e5vxAhXnoElRuLtbWLwGYMI TyhDZXlGf4swVfntlNQFIjIo5U9cdNUCbgZf9t6c= Date: Mon, 21 Nov 2022 19:12:36 +0100 From: Greg Kroah-Hartman To: James Bottomley Subject: Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs Message-ID: References: <44191f02-7360-bca3-be8f-7809c1562e68@linux.vnet.ibm.com>

<88111914afc6204b2a3fb82ded5d9bfb6420bca6.camel@HansenPartnership.com> <10c85b8f4779700b82596c4a968daead65a29801.camel@HansenPartnership.com> <94fe007e8eab8bc7ae3f56b88ad94646b4673657.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <94fe007e8eab8bc7ae3f56b88ad94646b4673657.camel@HansenPartnership.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: Matthew Garrett , linux-efi@vger.kernel.org, Nayna , Andrew Donnellan , Nayna Jain , 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, Stefan Berger Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Nov 21, 2022 at 12:33:55PM -0500, James Bottomley wrote: > On Mon, 2022-11-21 at 16:05 +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 21, 2022 at 09:03:18AM -0500, James Bottomley wrote: > > > On Mon, 2022-11-21 at 12:05 +0100, Greg Kroah-Hartman wrote: > > > > On Sun, Nov 20, 2022 at 10:14:26PM -0500, James Bottomley wrote: > [...] > > > > > I already explained in the email that sysfs contains APIs like > > > > > simple_pin_... which are completely inimical to namespacing. > > > > > > > > Then how does the networking code handle the namespace stuff in > > > > sysfs? That seems to work today, or am I missing something? > > > > > > have you actually tried? > > > > > > jejb@lingrow:~> sudo unshare --net bash > > > lingrow:/home/jejb # ls /sys/class/net/ > > > lo tun0 tun10 wlan0 > > > lingrow:/home/jejb # ip link show > > > 1: lo: mtu 65536 qdisc noop state DOWN mode DEFAULT > > > group > > > default qlen 1000 > > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > > > > > So, as you see, I've entered a network namespace and ip link shows > > > me the only interface I can see in that namespace (a down loopback) > > > but sysfs shows me every interface on the system outside the > > > namespace. > > > > Then all of the code in include/kobject_ns.h is not being used? We > > have a whole kobject namespace set up for networking, I just assumed > > they were using it. If not, I'm all for ripping it out. > > Hm, looking at the implementation, it seems to trigger off the > superblock (meaning you have to remount inside a mount namespace) and > it only works to control visibility in label based namespaces, so this > does actually work > > jejb@lingrow:~/git/linux> sudo unshare --net --mount bash > lingrow:/home/jejb # mount -t sysfs none /sys > lingrow:/home/jejb # ls /sys/class/net/ > lo > > The label based approach means that any given file can be shown in one > and only one namespace, which works for net, but not much else > (although it probably could be adapted). Great, thanks for verifying it works properly. No other subsystem other than networking has cared about adding support for namespaces to their sysfs representations. But the base logic is all there if they want to do so. thanks, greg k-h