From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Dan Williams" <dan.j.williams@intel.com>,
"James Bottomley" <James.Bottomley@hansenpartnership.com>,
<dhowells@redhat.com>
Cc: "Brijesh Singh" <brijesh.singh@amd.com>,
"Kuppuswamy Sathyanarayanan"
<sathyanarayanan.kuppuswamy@linux.intel.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
"Dionna Amalie Glaze" <dionnaglaze@google.com>,
"Borislav Petkov" <bp@alien8.de>,
"Samuel Ortiz" <sameo@rivosinc.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
<linux-coco@lists.linux.dev>, <keyrings@vger.kernel.org>,
<x86@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports
Date: Thu, 10 Aug 2023 17:50:10 +0300 [thread overview]
Message-ID: <CUOY5SZYGRV4.1FN39XMJ2I3VP@wks-101042-mac.ad.tuni.fi> (raw)
In-Reply-To: <64d17f5728fbc_5ea6e2943f@dwillia2-xfh.jf.intel.com.notmuch>
On Tue Aug 8, 2023 at 2:33 AM EEST, Dan Williams wrote:
> James Bottomley wrote:
> > On Fri, 2023-08-04 at 19:37 -0700, Dan Williams wrote:
> > > James Bottomley wrote:
> > > [..]
> > > > > This report interface on the other hand just needs a single ABI
> > > > > to retrieve all these vendor formats (until industry
> > > > > standardization steps in) and it needs to be flexible (within
> > > > > reason) for all the TSM-specific options to be conveyed. I do not
> > > > > trust my ioctl ABI minefield avoidance skills to get that right.
> > > > > Key blob instantiation feels up to the task.
> > > >
> > > > To repeat: there's nothing keylike about it.
> > >
> > > From that perspective there's nothing keylike about user-keys either.
> >
> > Whataboutism may be popular in politics at the moment, but it shouldn't
> > be a justification for API abuse: Just because you might be able to
> > argue something else is an abuse of an API doesn't give you the right
> > to abuse it further.
>
> That appears to be the disagreement, that the "user" key type is an
> abuse of the keyctl subsystem. Is that the general consensus that it was
> added as a mistake that is not be repeated?
>
> Otherwise there is significant amount of thought that has gone into
> keyctl including quotas, permissions, and instantiation flows.
I would focus on just fixing known obvious issues in the patch set and
improve the description what it does.
This looks like a discussion where the patch set is not advertised in
a way that it is understandable, not necessarily that it is all wrong.
E.g. why not name the key type as attestation key or something more
intuitive rather than three letter acronym?
I don't think this will converge to anything with argumentation in the
current state of where we are right now.
BR, Jarkko
prev parent reply other threads:[~2023-08-10 14:50 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 19:30 [PATCH 0/4] keys: Introduce a keys frontend for attestation reports Dan Williams
2023-07-28 19:30 ` [PATCH 1/4] keys: Introduce tsm keys Dan Williams
2023-07-28 19:40 ` Jarkko Sakkinen
2023-07-31 16:33 ` Peter Gonda
2023-07-31 17:48 ` Dan Williams
2023-07-31 18:14 ` Peter Gonda
2023-07-31 18:41 ` Dan Williams
2023-07-31 19:09 ` Dionna Amalie Glaze
2023-07-31 20:10 ` Dan Williams
2023-08-04 16:34 ` Peter Gonda
2023-08-04 22:24 ` Dan Williams
2023-08-05 5:11 ` Dan Williams
2023-08-01 18:01 ` Jarkko Sakkinen
2023-08-04 2:40 ` Dan Williams
2023-08-04 16:37 ` Dionna Amalie Glaze
2023-08-04 16:46 ` James Bottomley
2023-08-04 17:07 ` Dionna Amalie Glaze
2023-08-04 17:12 ` James Bottomley
2023-07-28 19:31 ` [PATCH 2/4] virt: sevguest: Prep for kernel internal {get, get_ext}_report() Dan Williams
2023-07-28 19:31 ` [PATCH 3/4] mm/slab: Add __free() support for kvfree Dan Williams
2023-07-28 19:31 ` [PATCH 4/4] virt: sevguest: Add TSM key support for SNP_{GET, GET_EXT}_REPORT Dan Williams
2023-07-31 16:45 ` Peter Gonda
2023-07-31 18:05 ` Dan Williams
2023-07-31 18:28 ` Peter Gonda
2023-07-28 19:34 ` [PATCH 0/4] keys: Introduce a keys frontend for attestation reports Jarkko Sakkinen
2023-07-28 19:44 ` Dan Williams
2023-07-31 10:09 ` Jarkko Sakkinen
2023-07-31 17:33 ` Dan Williams
2023-07-31 22:41 ` Huang, Kai
2023-08-01 18:48 ` Jarkko Sakkinen
2023-07-29 18:17 ` James Bottomley
2023-07-30 4:56 ` Dan Williams
2023-07-30 12:59 ` James Bottomley
2023-07-31 17:24 ` Dan Williams
2023-08-01 11:45 ` Huang, Kai
2023-08-01 12:03 ` James Bottomley
2023-08-01 12:30 ` James Bottomley
2023-08-02 0:10 ` Huang, Kai
2023-08-02 12:41 ` James Bottomley
2023-08-02 23:13 ` Huang, Kai
2023-08-04 3:53 ` Dan Williams
2023-08-04 2:22 ` Dan Williams
2023-08-04 16:19 ` Daniel P. Berrangé
2023-08-04 21:49 ` Huang, Kai
2023-08-05 11:05 ` James Bottomley
2023-08-05 2:37 ` Dan Williams
2023-08-05 13:30 ` James Bottomley
2023-08-07 23:33 ` Dan Williams
2023-08-08 14:19 ` James Bottomley
2023-08-08 14:53 ` Peter Gonda
2023-08-08 14:54 ` Sathyanarayanan Kuppuswamy
2023-08-08 15:48 ` Dan Williams
2023-08-08 16:07 ` Dionna Amalie Glaze
2023-08-08 16:43 ` Dan Williams
2023-08-08 17:21 ` Dionna Amalie Glaze
2023-08-08 18:17 ` Dan Williams
2023-08-08 23:32 ` Huang, Kai
2023-08-09 3:27 ` Dan Williams
2023-08-09 16:14 ` Peter Gonda
2023-08-08 18:16 ` James Bottomley
2023-08-08 18:48 ` Dionna Amalie Glaze
2023-08-08 19:37 ` James Bottomley
2023-08-08 20:04 ` Dionna Amalie Glaze
2023-08-08 21:46 ` James Bottomley
2023-08-08 22:33 ` Dionna Amalie Glaze
2023-08-08 15:14 ` Dan Williams
2023-08-10 14:50 ` Jarkko Sakkinen [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=CUOY5SZYGRV4.1FN39XMJ2I3VP@wks-101042-mac.ad.tuni.fi \
--to=jarkko@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dhowells@redhat.com \
--cc=dionnaglaze@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sameo@rivosinc.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).