Closed stefanberger closed 2 years ago
I'll have to get a Fedora 34 machine configured, but I just ran this on my Ubuntu 20.04 machine and it seems fine:
while [ 1 ]; do p11tool --list-tokens || break; done;
I know FAPI has had some fixes... let me start by re-creating and see if it fails with master.
I'm suffering from this problem, too. The culprit seems to be that indeed the number of connections to tpm2-abrmd
gets exhausted. I didn't look into detail, but looking at active connections
# sudo lsof -c tpm2-abrmd -E -a -U
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
...
tpm2-abrm 1608 tss 11u unix 0x0000000047bff185 0t0 57631 type=STREAM ->INO=57630 3407,gsd-smart,14u (CONNECTED)
tpm2-abrm 1608 tss 12u unix 0x000000000e4bce5d 0t0 57633 type=STREAM ->INO=57632 3407,gsd-smart,16u (CONNECTED)
tpm2-abrm 1608 tss 13u unix 0x00000000c41b9cee 0t0 57657 type=STREAM ->INO=57656 3407,gsd-smart,17u (CONNECTED)
tpm2-abrm 1608 tss 14u unix 0x0000000010b7faab 0t0 74469 type=STREAM ->INO=74468 5670,ssh-pkcs1,10u (CONNECTED)
tpm2-abrm 1608 tss 15u unix 0x00000000bf4205f8 0t0 74471 type=STREAM ->INO=74470 5670,ssh-pkcs1,12u (CONNECTED)
tpm2-abrm 1608 tss 16u unix 0x00000000f91f08cc 0t0 74473 type=STREAM ->INO=74472 5670,ssh-pkcs1,13u (CONNECTED)
tpm2-abrm 1608 tss 17u unix 0x000000000a2345c7 0t0 90056 type=STREAM ->INO=90055 7483,seahorse,17u (CONNECTED)
tpm2-abrm 1608 tss 18u unix 0x00000000948ab5d0 0t0 90058 type=STREAM ->INO=90057 7483,seahorse,19u (CONNECTED)
tpm2-abrm 1608 tss 19u unix 0x00000000fede29aa 0t0 90060 type=STREAM ->INO=90059 7483,seahorse,20u (CONNECTED)
tpm2-abrm 1608 tss 20u unix 0x00000000af52defa 0t0 90858 type=STREAM ->INO=90857 7709,firefox,111u (CONNECTED)
tpm2-abrm 1608 tss 21u unix 0x000000008988bac8 0t0 95688 type=STREAM ->INO=95687 7709,firefox,113u (CONNECTED)
tpm2-abrm 1608 tss 22u unix 0x00000000d595a6f4 0t0 95690 type=STREAM ->INO=95689 7709,firefox,114u (CONNECTED)
tpm2-abrm 1608 tss 23u unix 0x00000000e65a4a47 0t0 94126 type=STREAM ->INO=94125 8020,Web Conte,24u (CONNECTED)
tpm2-abrm 1608 tss 24u unix 0x0000000088230508 0t0 96159 type=STREAM ->INO=96158 8020,Web Conte,26u (CONNECTED)
tpm2-abrm 1608 tss 25u unix 0x000000003180df6f 0t0 96161 type=STREAM ->INO=96160 8020,Web Conte,27u (CONNECTED)
tpm2-abrm 1608 tss 26u unix 0x00000000dba782b5 0t0 102170 type=STREAM ->INO=102169 8682,Web Conte,22u (CONNECTED)
tpm2-abrm 1608 tss 27u unix 0x00000000248cda07 0t0 102172 type=STREAM ->INO=102171 8682,Web Conte,24u (CONNECTED)
tpm2-abrm 1608 tss 28u unix 0x00000000d5f93eb4 0t0 102174 type=STREAM ->INO=102173 8682,Web Conte,25u (CONNECTED)
tpm2-abrm 1608 tss 29u unix 0x000000002e6a964e 0t0 111927 type=STREAM ->INO=111926 9060,Web Conte,22u (CONNECTED)
tpm2-abrm 1608 tss 30u unix 0x00000000e1f94b0d 0t0 111929 type=STREAM ->INO=111928 9060,Web Conte,24u (CONNECTED)
tpm2-abrm 1608 tss 31u unix 0x000000004db90aa8 0t0 111931 type=STREAM ->INO=111930 9060,Web Conte,25u (CONNECTED)
tpm2-abrm 1608 tss 32u unix 0x0000000021423cd5 0t0 112324 type=STREAM ->INO=112323 9463,Web Conte,22u (CONNECTED)
tpm2-abrm 1608 tss 33u unix 0x000000009a6c2af6 0t0 112326 type=STREAM ->INO=112325 9463,Web Conte,24u (CONNECTED)
tpm2-abrm 1608 tss 34u unix 0x00000000b510de79 0t0 112328 type=STREAM ->INO=112327 9463,Web Conte,25u (CONNECTED)
tpm2-abrm 1608 tss 35u unix 0x0000000018b9c85e 0t0 133594 type=STREAM ->INO=133593 10452,Web Conte,22u (CONNECTED)
tpm2-abrm 1608 tss 36u unix 0x000000008b610b02 0t0 133596 type=STREAM ->INO=133595 10452,Web Conte,24u (CONNECTED)
tpm2-abrm 1608 tss 37u unix 0x000000000931778e 0t0 131476 type=STREAM ->INO=131475 10452,Web Conte,25u (CONNECTED)
suggests that
With more than half a dozen open tabs (i.e. always) the limit is exhausted.
1. every client establishes and holds open 3 socket connections
With a bit of tracing, indeed even a simple p11tool --list-tokens
establishes 3 tarbmd connections on the following code paths:
backend_init
backend_fapi_init
Fapi_Initialize
... Tss2_TctiLdr_Initialize
... Tss2_Tcti_Tabrmd_Init
backend_get_tokens
backend_esysdb_get_tokens
db_get_tokens
token_min_init
backend_ctx_new
backend_esysdb_ctx_new
tpm_ctx_new
Tss2_TctiLdr_Initialize
... Tss2_Tcti_Tabrmd_Init
backend_get_tokens
token_min_init
backend_ctx_new
backend_esysdb_ctx_new
tpm_ctx_new
Tss2_TctiLdr_Initialize
... Tss2_Tcti_Tabrmd_Init
There are no matching *_Finalize
calls at all.
1. every client establishes and holds open 3 socket connections
With a bit of tracing, indeed even a simple
p11tool --list-tokens
establishes 3 tarbmd connections on the following code paths: [...] There are no matching*_Finalize
calls at all.
Setting TPM2_PKCS11_BACKEND=fapi
results in exactly one Tss2_TctiLdr_Initialize
call via Fapi_Initialize
, and a matching Fapi_Finalize
-> Tss2_TctiLdr_Finalize
.
My FAPI isn't properly provisioned though so it doesn't work (yet).
Also, without explicitly specifying the backend (i.e. using esysdb
), but pruning ~/.tpm2_pkcs11/tpm2_pkcs11.sqlite3
results in only two tarbmd
connections, but my previously set up key disappearing from the list. I.e. every token consumes a connection.
With a bit of tracing, indeed even a simple
p11tool --list-tokens
establishes 3 tarbmd connections on the following code paths: [...] There are no matching*_Finalize
calls at all.Setting
TPM2_PKCS11_BACKEND=fapi
results in exactly oneTss2_TctiLdr_Initialize
call viaFapi_Initialize
, and a matchingFapi_Finalize
->Tss2_TctiLdr_Finalize
.My FAPI isn't properly provisioned though so it doesn't work (yet).
Interestingly, after tss2_provision
*_Finalize
stopped appearing in the traces, and so did the log message at the top of backend_destroy
.
UPD: this appears to be an artifact of p11tool
which doesn't call C_Finalize
on loaded modules.
I just realized I misinterpreted the original issue; my comments aren't probably relevant for that problem.
I guess I should rather create a separate issue.
So are their 3 problems here?
#1
, or is it a different issue when initialize fails?1. gerror memory not initialized?
Yes, seems to come from the pkcs11 module.
[Sorry for closing. Wrong button, due to too much or not enough coffee.]
1. gerror memory not initialized?
Yes, seems to come from the pkcs11 module.
[Sorry for closing. Wrong button, due to too much or not enough coffee.]
I think that's fixed here:
If you apply that patch do your segfaults go away?
@stefanberger did the fix in the tpm2-abrmd TCTI code (https://github.com/tpm2-software/tpm2-abrmd/commit/6af641bfa46130670a8462d1031f9276aeb0af1f) fix your issue?
On Fedora 36 with tpm2-abrmd-2.4.1-1.fc36.x86_64 installed the loop, that previously caused the failure, now works fine.
while :; do p11tool --list-tokens || break; done
Thanks!
while :; do p11tool --list-tokens || break; done
I am using the GnuTLS p11tool to list tokens and I occasionally get crashes like this one:
There's no token setup related to the TPM 2 so I would expect this output here:
The easiest way to recreate it seems to be the following (softhsm need not be installed on the system):
It will eventually terminate like this: