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:

quoted

On Thu, 2021-09-02 at 14:57 +0200, Greg KH wrote:
[...]

quoted

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.

quoted

quoted

 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.

James