From: Greg KH <firstname.lastname@example.org> To: James Bottomley <email@example.com> Cc: Dov Murik <firstname.lastname@example.org>, email@example.com, Borislav Petkov <firstname.lastname@example.org>, Ashish Kalra <email@example.com>, Brijesh Singh <firstname.lastname@example.org>, Tom Lendacky <email@example.com>, Ard Biesheuvel <firstname.lastname@example.org>, James Morris <email@example.com>, "Serge E. Hallyn" <firstname.lastname@example.org>, Andi Kleen <email@example.com>, "Dr. David Alan Gilbert" <firstname.lastname@example.org>, Tobin Feldman-Fitzthum <email@example.com>, Jim Cadden <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH 0/3] Allow access to confidential computing secret area in SEV guests Date: Thu, 2 Sep 2021 17:05:47 +0200 [thread overview] Message-ID: <YTDoS5XycY3gO4MM@kroah.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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. Why force this into securityfs if it doesn't have to be? thanks, greg k-h
next prev parent reply other threads:[~2021-09-02 15:05 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 [this message] 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
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=YTDoS5XycY3gO4MM@kroah.com \ --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).