linux-kernel - Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <88111914afc6204b2a3fb82ded5d9bfb6420bca6.camel@HansenPartnership.com>
Date:   Sun, 20 Nov 2022 22:14:26 -0500
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Nayna <nayna@...ux.vnet.ibm.com>
Cc:     Nayna Jain <nayna@...ux.ibm.com>, linuxppc-dev@...ts.ozlabs.org,
        linux-fsdevel@...r.kernel.org, linux-efi@...r.kernel.org,
        linux-security-module <linux-security-module@...r.kernel.org>,
        linux-kernel@...r.kernel.org,
        Michael Ellerman <mpe@...erman.id.au>, npiggin@...il.com,
        christophe.leroy@...roup.eu, Dov Murik <dovmurik@...ux.ibm.com>,
        George Wilson <gcwilson@...ux.ibm.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Russell Currey <ruscur@...sell.cc>,
        Andrew Donnellan <ajd@...ux.ibm.com>,
        Stefan Berger <stefanb@...ux.ibm.com>
Subject: Re: [PATCH 2/4] fs: define a firmware security filesystem named
 fwsecurityfs

On Sun, 2022-11-20 at 17:13 +0100, Greg Kroah-Hartman wrote:
> On Sat, Nov 19, 2022 at 01:20:09AM -0500, Nayna wrote:
> > 
> > On 11/17/22 16:27, Greg Kroah-Hartman wrote:
> > > On Mon, Nov 14, 2022 at 06:03:43PM -0500, Nayna wrote:
> > > > On 11/10/22 04:58, Greg Kroah-Hartman wrote:
[...]
> > > > > I do not understand, sorry.  What does namespaces have to do
> > > > > with this?
> > > > > sysfs can already handle namespaces just fine, why not use
> > > > > that?
> > > > Firmware objects are not namespaced. I mentioned it here as an
> > > > example of the difference between firmware and kernel objects.
> > > > It is also in response to the feedback from James Bottomley in
> > > > RFC v2 [
> > > > https://lore.kernel.org/linuxppc-dev/41ca51e8db9907d9060cc38ad
> > > > b59a66dcae4c59b.camel@...senPartnership.com/].
> > > I do not understand, sorry.  Do you want to use a namespace for
> > > these or not?  The code does not seem to be using namespaces. 
> > > You can use sysfs with, or without, a namespace so I don't
> > > understand the issue here.
> > > 
> > > With your code, there is no namespace.
> > 
> > You are correct. There's no namespace for these.
> 
> So again, I do not understand.  Do you want to use filesystem
> namespaces, or do you not?

Since this seems to go back to my email quoted again, let me repeat:
the question isn't if this patch is namespaced; I think you've agreed
several times it isn't.  The question is if the exposed properties
would ever need to be namespaced.  This is a subtle and complex
question which isn't at all explored by the above interchange.

> How again can you not use sysfs or securityfs due to namespaces? 
> What is missing?

I already explained in the email that sysfs contains APIs like
simple_pin_... which are completely inimical to namespacing.  Currently
securityfs contains them as well, so in that regard they're both no
better than each other.  The point I was making is that securityfs is
getting namespaced by the IMA namespace rework (which is pretty complex
due to having to replace the simple_pin_... APIs), so when (perhaps if)
the IMA namespace is accepted, securityfs will make a good home for
quantities that need namespacing.  That's not to say you can't
namespace things in sysfs, you can, in the same way that you can get a
round peg into a square hole if you bang hard enough.

So perhaps we could get back to the original question of whether these
quantities would ever be namespaced ... or, conversely, whether they
would never need namespacing.

James