All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Gotthard <petr.gotthard at centrum.cz>
To: tpm2@lists.01.org
Subject: [tpm2] Re: TPM2 provider stuck during handshake
Date: Wed, 08 Jun 2022 16:47:06 +0200	[thread overview]
Message-ID: <20220608164706.6DFEEE19@centrum.cz> (raw)
In-Reply-To: a2a22769-f6cb-7e5a-8db1-db1dd9f6e6e9@haproxy.com

[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]

Hi Rémi,
I can't think of any simple reason why you getting that error.
 
Do you use a TPM simulator (which?) or a real TPM chip? And do you use it with the abrmd manager, or not?
(In general, the abrmd is recommended for complex operations like PKI.)
 
 
Petr
 
______________________________________________________________
> Od: "Remi Tricot-Le Breton" <rlebreton(a)haproxy.com>
> Komu: tpm2(a)lists.01.org
> Datum: 08.06.2022 16:16
> Předmět: [tpm2] TPM2 provider stuck during handshake
>
Hello,
 
 I've been trying to make the TPM2 provider work in my environment 
 (Ubuntu 20.04) for quite some time and I did not succeed yet.
 
 I tried using the commands suggested in docs/certificates.md to create a 
 self signed certificate which I then used in an "openssl s_server" 
 instance but when I try to connect to this SSL server, the handshake 
 fails to complete.
 The three commands I used are the following:
     openssl req -provider tpm2 -x509 -subj "/C=GB/CN=foo" -keyout 
 testkey.pem -out testcert.pem
     openssl s_server -provider tpm2 -provider default -propquery 
 ?provider=tpm2 -accept 4443 -www -key testkey.pem -cert testcert.pem
     curl --cacert testcert.pem https://localhost:4443/ <https://localhost:4443/>
 
 The curl command ends in a timeout and the server remains stuck (without 
 raising errors).
 
 I rebuilt the tpm2 provider with the enable-debug=yes option added in 
 order to understand what was happening and I noticed that the server was 
 stuck when trying to duplicate a context ("DIGEST DUP" was dumped on the 
 server's standard output), and more specifically in the 
 Tss2_Sys_ExecuteFinish function which in turn calls tctildr_receive with 
 a -1 timeout (out of which we apparently never get out).
 
 Do any of you know if I missed something or if it is a bug ?
 I could provide the full standard output log or a complete backtrace of 
 the stuck server if needed but they might end up being unnecessary noise 
 if the bug comes from my wrong use of the provider.
 
 Thanks
 
 Rémi LB
 _______________________________________________
 tpm2 mailing list -- tpm2(a)lists.01.org
 To unsubscribe send an email to tpm2-leave(a)lists.01.org
 %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 3084 bytes --]

             reply	other threads:[~2022-06-08 14:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-08 14:47 Petr Gotthard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-06-08 14:47 [tpm2] Re: TPM2 provider stuck during handshake Roberts, William C
2022-06-08 16:46 Remi Tricot-Le Breton

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=20220608164706.6DFEEE19@centrum.cz \
    --to=tpm2@lists.01.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 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.