Received-SPF: pass (google.com: domain of linux-kernel+bounces-178648-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 14 May 2024 15:09:44 +0300
Message-Id: <D19CUF0H9Q3S.3L5Y5S9553S5@kernel.org>
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Ignat Korchagin" <ignat@cloudflare.com>
Cc: "James Bottomley" <James.Bottomley@hansenpartnership.com>, "Mimi Zohar"
 <zohar@linux.ibm.com>, "David Howells" <dhowells@redhat.com>, "Paul Moore"
 <paul@paul-moore.com>, "James Morris" <jmorris@namei.org>,
 <serge@hallyn.com>, <linux-integrity@vger.kernel.org>,
 <keyrings@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
 <kernel-team@cloudflare.com>
Subject: Re: [RFC PATCH 0/2] TPM derived keys
References: <20240503221634.44274-1-ignat@cloudflare.com>
 <CALrw=nGhgRrhJ5mWWC6sV2WYWoijvD9WgFzMfOe6mHmqnza-Hw@mail.gmail.com>
 <D18XXJ373C2V.2M6AOMKD1B89W@kernel.org>
 <CALrw=nHGLN=dn3fbyAcXsBufw0tAWUT1PKVHDK5RZkHcdd3CUw@mail.gmail.com>
In-Reply-To: <CALrw=nHGLN=dn3fbyAcXsBufw0tAWUT1PKVHDK5RZkHcdd3CUw@mail.gmail.com>

On Tue May 14, 2024 at 1:05 PM EEST, Ignat Korchagin wrote:
> On Tue, May 14, 2024 at 1:28=E2=80=AFAM Jarkko Sakkinen <jarkko@kernel.or=
g> wrote:
> >
> > On Mon May 13, 2024 at 8:11 PM EEST, Ignat Korchagin wrote:
> > > On Fri, May 3, 2024 at 11:16=E2=80=AFPM Ignat Korchagin <ignat@cloudf=
lare.com> wrote:
> > > I would like to point out to myself I was wrong: it is possible to as=
k
> > > the kernel to generate a trusted key inside the kernel locally with
> > > "keyctl add trusted kmk "new 32" @u"
> >
> > Not in a full-time kernel position ATM as I'm working as contract
> > researcher up until beginning of Oct (took some industry break after
> > a startup went down of business), so please, politely asking, write
> > a bit more compact descriptions ;-) I'm trying to find a new position b=
y
> > the beginning of Oct but right now I'd appreciate a bit more thought ou=
t
> > text descriptions.
> >
> > I'm working out a small patch set with James Prestwood to add asymmetri=
c
> > TPM2 keys based on his old patch set [1] but laid out on top of the
> > existing baseline.
> >
> > I did already the key type shenanigans etc. for it and James P is layin=
g
> > his pre-existing RSA code and new ECDSA on top of that. So this will
>
> This is great. Perhaps we can finally have ECDSA software signature
> support as well, which I have been trying to get in for some time now
> [1]

Yes exactly both.

>
> > give x.509 compatibility [2]. This patch set will be out soon and likel=
y
> > part of 6.11 (or almost guaranteed as most of it is done).
> >
> > So by plain guess this might be along the lines what you might want?
>
> I don't think so. I have seen this patchset, but unless the new
> version is fundamentally different, it looks to me that the asymmetric
> TPM keys are the same as trusted keys except they are asymmetric
> instead of being symmetric. That is, they are still of limited use on
> stateless systems and are subject to the same restrictions I described
> in my revised cover description.

OK, hmm... can you an "apples and oranges" example what would be
most trivial use case where these don't cut?


> On top of that I'm not sure they would be widely used as "leaf" keys
> by applications, maybe more as root/intermediate keys in some kind of
> key hierarchy. TPMs are slow and I don't see a high-performance
> web-server, for example, using asymmetric TPM keys for TLS operations.
> Also, as we learned the hard way operating many TPMs in production,
> some TPMs are quite unreliable and fail really fast, if you "spam"
> them with a lot of crypto ops. I understand this is a HW/TPM vendor
> problem, but in practice we're trying to build systems, where TPM is
> used to protect/generate other keys, but most of the "leaf" crypto
> operations are done in software, so we don't make the TPM do too much
> crypto.

So what about SGX/SNP/TDX?

TPM is definitely not made for workloads :-)

> Just to clarify - I'm not arguing about the usefulness of TPM
> asymmetric keys in the kernel. I would really want to see this
> building block available as well, but I think it just serves a
> different purpose/use case from what I'm trying to figure out in this
> RFC thread.

Got it :-) NP

BR, Jarkko