From: David Woodhouse <dwmw2@infradead.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-integrity@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.ibm.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
keyrings@vger.kernel.org, David Howells <dhowells@redhat.com>
Subject: Re: [PATCH 0/4] Trusted Key policy for TPM 2.0
Date: Fri, 21 May 2021 18:53:46 +0100 [thread overview]
Message-ID: <2f786037cf125393758c6b7be36d55c5ff01f2c6.camel@infradead.org> (raw)
In-Reply-To: <9244313e34910f17664a6a0320e5b96b4e80d56d.camel@HansenPartnership.com>
[-- Attachment #1: Type: text/plain, Size: 960 bytes --]
On Fri, 2021-05-21 at 09:17 -0700, James Bottomley wrote:
> I'm not so sure we want to encourage that. The persistent handle space
> is really limited in TPM 2.0. We just ran into a real world situation
> where the TPM ran out after a handful. It was an application that
> loaded files into persistent handles ("because it's easier") and then
> made use of them ... we're currently fixing it not to use persistent
> handles because it doesn't need to.
Makes sense. We should fix StrongSwan then, because they're doing the
same thing.
https://wiki.strongswan.org/projects/strongswan/wiki/TpmPlugin
Of course, if we document the file format and make it ubiquitously
supported (including making an OpenSSL *provider* to replace the
obsolete ENGINEs, and chasing it into GnuTLS in
https://gitlab.com/gnutls/gnutls/-/issues/594 ), that will go a long
way towards encouraging applications to use keys wrapped in files
instead of NVRAM...
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
next prev parent reply other threads:[~2021-05-21 17:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 0:43 [PATCH 0/4] Trusted Key policy for TPM 2.0 James Bottomley
2021-05-21 0:43 ` [PATCH 1/4] security: keys: trusted: add PCR policy to TPM2 keys James Bottomley
2021-05-22 22:38 ` Jarkko Sakkinen
2021-05-21 0:43 ` [PATCH 2/4] security: keys: trusted: add ability to specify arbitrary policy James Bottomley
2021-05-22 22:40 ` Jarkko Sakkinen
2021-05-21 0:44 ` [PATCH 3/4] security: keys: trusted: implement counter/timer policy James Bottomley
2021-05-21 0:44 ` [PATCH 4/4] security: keys: trusted: implement authorization policy James Bottomley
2021-05-21 13:48 ` [PATCH 0/4] Trusted Key policy for TPM 2.0 David Woodhouse
2021-05-21 14:28 ` James Bottomley
2021-05-21 15:22 ` David Woodhouse
2021-05-21 15:55 ` James Bottomley
2021-05-21 16:12 ` David Woodhouse
2021-05-21 16:17 ` James Bottomley
2021-05-21 17:53 ` David Woodhouse [this message]
2021-05-22 22:45 ` Jarkko Sakkinen
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=2f786037cf125393758c6b7be36d55c5ff01f2c6.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=dhowells@redhat.com \
--cc=jarkko@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=zohar@linux.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.