linux-kernel - Re: [PATCH 0/3] Allow access to confidential computing secret area in SEV guests

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: <61212d923295203173b1a8c3c24b6dd19835c57e.camel@linux.ibm.com>
Date:   Thu, 02 Sep 2021 09:19:13 -0700
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Dov Murik <dovmurik@...ux.ibm.com>, linux-efi@...r.kernel.org,
        Borislav Petkov <bp@...e.de>,
        Ashish Kalra <ashish.kalra@....com>,
        Brijesh Singh <brijesh.singh@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Andi Kleen <ak@...ux.intel.com>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        Tobin Feldman-Fitzthum <tobin@...ux.ibm.com>,
        Jim Cadden <jcadden@....com>, linux-coco@...ts.linux.dev,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Allow access to confidential computing secret area
 in SEV guests

On Thu, 2021-09-02 at 18:09 +0200, Greg KH wrote:
> On Thu, Sep 02, 2021 at 08:19:51AM -0700, James Bottomley wrote:
> > On Thu, 2021-09-02 at 17:05 +0200, Greg KH wrote:
> > > On Thu, Sep 02, 2021 at 07:35:10AM -0700, James Bottomley wrote:
> > > > On Thu, 2021-09-02 at 14:57 +0200, Greg KH wrote:
> > > > [...]
> > > > > Wait, why are you using securityfs for this?
> > > > > 
> > > > > securityfs is for LSMs to use. 
> > > > 
> > > > No it isn't ... at least not exclusively; we use it for non LSM
> > > > security purposes as well, like for the TPM BIOS log and for
> > > > IMA.  What makes you think we should start restricting
> > > > securityfs to LSMs only?  That's not been the policy up to now.
> > > 
> > > Well that was the original intent of the filesystem when it was
> > > created, but I guess it's really up to the LSM maintainers now
> > > what they want it for.
> > > 
> > > > >  If you want your own filesystem to play around with stuff
> > > > > like this, great, write your own, it's only 200 lines or less
> > > > > these days.  We used to do it all the time until people
> > > > > realized they should just use sysfs for driver stuff.
> > > > 
> > > > This is a security purpose (injected key retrieval), so
> > > > securityfs seems to be the best choice.  It's certainly
> > > > possible to create a new filesystem, but I really think things
> > > > with a security purpose should use securityfs so people know
> > > > where to look for them.
> > > 
> > > knowing where to look should not be an issue, as that should be
> > > documented in Documentation/ABI/ anyway, right?
> > > 
> > > It's just the overlap / overreach of using an existing filesystem
> > > for things that don't seem to be LSM-related that feels odd to
> > > me.
> > > 
> > > Why not just make a cocofs if those people want a filesystem
> > > interface?
> > > It's 200 lines or so these days, if not less, and that way you
> > > only mount what you actually need for the system.
> > 
> > Secrets transfer is actually broader than confidential computing,
> > although confidential computing is a first proposed use, so I think
> > cocofs would be too narrow.
> > 
> > > Why force this into securityfs if it doesn't have to be?
> > 
> > It's not being forced.  Secrets transfer is a security function in
> > the same way the bios log is.
> 
> Is the bios log in securityfs today?

Yes. It's under /sys/kernel/security/tpm0/  All the ima policy control
and its log is under /sys/kernel/security/ima/  that's why I think
declaring securityfs as being for anything security related is already
our de facto (if not de jure) policy.

> Anyway, it's up to the securityfs maintainer (i.e. not me), but
> personally, I think this should be a separate filesystem as that
> would probably make things easier in the long run...

I know Al likes this business of loads of separate filesystems, but
personally I'm not in favour.  For every one you do, you not only have
to document it all, you also have to find a preferred mount point that
the distributions can agree on and also have them agree to enable the
mount for, which often takes months of negotiation.  Having fewer
filesystems grouped by common purpose which have agreed mount points
that distros actually mount seems a far easier approach to enablement.

James