[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <D1A7BZNCNPW8.281BRWPJVW0JX@kernel.org>
Date: Wed, 15 May 2024 15:03:15 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jarkko Sakkinen" <jarkko@...nel.org>, "Ignat Korchagin"
<ignat@...udflare.com>
Cc: "James Bottomley" <James.Bottomley@...senpartnership.com>, "Mimi Zohar"
<zohar@...ux.ibm.com>, "David Howells" <dhowells@...hat.com>, "Paul Moore"
<paul@...l-moore.com>, "James Morris" <jmorris@...ei.org>,
<serge@...lyn.com>, <linux-integrity@...r.kernel.org>,
<keyrings@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<kernel-team@...udflare.com>
Subject: Re: [RFC PATCH 2/2] KEYS: implement derived keys
On Wed May 15, 2024 at 3:00 PM EEST, Jarkko Sakkinen wrote:
> I did as much clarification as I possibly can.
>
> Also, if you look at confidential computing platforms there's exactly
> two assets that they use lock into machine:
>
> - Binary
> - CPU material
>
> Only carved into stone immutable material for key derivation.
>
> You can use mm_struct->exe_file binary if that will work out for you.
> I'm done with this version.
Pretty good case for having SGX, TDX and SNP in something else than just
Xeon's and EPYC's ;-)
But yeah within time limits I have I've used more quota for this
than I should have.
I look at +1 (if there is one).
BR, Jarkko
Powered by blists - more mailing lists