linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: James Bottomley <jejb@linux.ibm.com>
Cc: Dov Murik <dovmurik@linux.ibm.com>,
	linux-efi@vger.kernel.org, Borislav Petkov <bp@suse.de>,
	Ashish Kalra <ashish.kalra@amd.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Andi Kleen <ak@linux.intel.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Tobin Feldman-Fitzthum <tobin@linux.ibm.com>,
	Jim Cadden <jcadden@ibm.com>,
	linux-coco@lists.linux.dev,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] Allow access to confidential computing secret area in SEV guests
Date: Thu, 2 Sep 2021 18:31:58 +0200	[thread overview]
Message-ID: <YTD8fkAfjutR8G/o@kroah.com> (raw)
In-Reply-To: <61212d923295203173b1a8c3c24b6dd19835c57e.camel@linux.ibm.com>

On Thu, Sep 02, 2021 at 09:19:13AM -0700, James Bottomley wrote:
> 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,

Wait, why would you not have to document your new files no matter what?
That should not be an issue either way.

> 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,

You create that yourself, just like tracefs does, and set the standard
right away, not an issue.

> which often takes months of negotiation.

Enabling it does take time, which is good because if they do not think
it should be present because they do not want to use it, then it will
not be, which means either they do not need your new feature, or you
have not made it useful enough.

So again, not an issue.
And you can even mount it yourself from the kernel if you insist on it
always being present.

> Having fewer
> filesystems grouped by common purpose which have agreed mount points
> that distros actually mount seems a far easier approach to enablement.

The issue is that random things gets added to those filesystems,
exposing stuff that perhaps some systems do NOT want exposed to
userspace.  Making it explicit as to what they have to mount to get
access to that is a good thing because you have less of an "attack
surface" and all of that.

So again, this should not be an issue.  If coco stuff is so important
that people need it, then having them have to add it to their init
scripts just to mount the filesystem is not an issue as there are other
userspace components of all of this mess that they had to install
anyway.  Just make it part of the userspace tools that are going to be
accessing these files because you have to get those onto the systems no
matter what.

greg k-h

      reply	other threads:[~2021-09-02 16:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-09 19:01 Dov Murik
2021-08-09 19:01 ` [PATCH 1/3] efi/libstub: Copy confidential computing secret area Dov Murik
2021-08-09 19:01 ` [PATCH 2/3] efi: Reserve " Dov Murik
2021-08-09 19:01 ` [PATCH 3/3] virt: Add sev_secret module to expose confidential computing secrets Dov Murik
2021-08-13 13:05   ` Andrew Scull
2021-08-16  9:56     ` Ard Biesheuvel
2021-08-19 13:02       ` Andrew Scull
2021-08-20 18:36         ` Dov Murik
2021-08-23 19:21           ` Andrew Scull
2021-09-02 12:59   ` Greg KH
2021-09-02 18:14     ` Dov Murik
2021-09-02 12:57 ` [PATCH 0/3] Allow access to confidential computing secret area in SEV guests Greg KH
2021-09-02 14:35   ` James Bottomley
2021-09-02 15:05     ` Greg KH
2021-09-02 15:19       ` James Bottomley
2021-09-02 16:09         ` Greg KH
2021-09-02 16:19           ` James Bottomley
2021-09-02 16:31             ` Greg KH [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YTD8fkAfjutR8G/o@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=ak@linux.intel.com \
    --cc=ardb@kernel.org \
    --cc=ashish.kalra@amd.com \
    --cc=bp@suse.de \
    --cc=brijesh.singh@amd.com \
    --cc=dgilbert@redhat.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=jcadden@ibm.com \
    --cc=jejb@linux.ibm.com \
    --cc=jmorris@namei.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=thomas.lendacky@amd.com \
    --cc=tobin@linux.ibm.com \
    --subject='Re: [PATCH 0/3] Allow access to confidential computing secret area in SEV guests' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).