From: James Bottomley <email@example.com> To: Greg KH <firstname.lastname@example.org> Cc: Dov Murik <email@example.com>, firstname.lastname@example.org, Borislav Petkov <email@example.com>, Ashish Kalra <firstname.lastname@example.org>, Brijesh Singh <email@example.com>, Tom Lendacky <firstname.lastname@example.org>, Ard Biesheuvel <email@example.com>, James Morris <firstname.lastname@example.org>, "Serge E. Hallyn" <email@example.com>, Andi Kleen <firstname.lastname@example.org>, "Dr. David Alan Gilbert" <email@example.com>, Tobin Feldman-Fitzthum <firstname.lastname@example.org>, Jim Cadden <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH 0/3] Allow access to confidential computing secret area in SEV guests Date: Thu, 02 Sep 2021 08:19:51 -0700 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <YTDoS5XycY3gO4MM@kroah.com> 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. James
next prev parent reply other threads:[~2021-09-02 15:20 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 [this message] 2021-09-02 16:09 ` Greg KH 2021-09-02 16:19 ` James Bottomley 2021-09-02 16:31 ` Greg KH
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).