Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date:   Thu, 10 Aug 2023 17:50:10 +0300
Message-Id: <CUOY5SZYGRV4.1FN39XMJ2I3VP@wks-101042-mac.ad.tuni.fi>
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation
 reports
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>
References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> <a507ef3302d3afff58d82528ee17e82df1f21de0.camel@HansenPartnership.com> <64c5ed6eb4ca1_a88b2942a@dwillia2-xfh.jf.intel.com.notmuch> <c6576d1682b576ba47556478a98f397ed518a177.camel@HansenPartnership.com> <64cdb5f25c56_2138e294f1@dwillia2-xfh.jf.intel.com.notmuch> <1180481830431165d49c5e64b92b81c396ebc9b1.camel@HansenPartnership.com> <64d17f5728fbc_5ea6e2943f@dwillia2-xfh.jf.intel.com.notmuch>
In-Reply-To: <64d17f5728fbc_5ea6e2943f@dwillia2-xfh.jf.intel.com.notmuch>
Precedence: bulk

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.
> > > >=20
> > > > To repeat: there's nothing keylike about it.
> > >=20
> > > From that perspective there's nothing keylike about user-keys either.
> >=20
> > 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