Environment:
Host: Linux 5.4.199 aarch64
Secure element: SE050F2 (OEM ID: A9 2A)
Middleware: 04.01.01, built with the following flags:
-DPTMW_Log=Verbose
-DPTMW_SE05X_Auth=None \
-DPTMW_SCP=None \
-DPTMW_SMCOM=JRCP_V1_AM
-DWithAccessMgr_UnixSocket:BOOL=ON \
-DPTMW_Host=Raspbian \
-DPTMW_Applet=SE05X_A \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_TOOLCHAIN_FILE=../scripts/armgcc_force_cpp.cmake \
-DPTMW_HostCrypto=OPENSSL
- OpenSSL: 1.1.1l
OpenSSL config attached (openssl-sss-se050.cnf, put in /etc/)
- HaProxy: 2.4.* (I'm using 2.4.22 but reproduced on recent 2.4.24 too)
HaProxy config attached (haproxy_dynamic.conf, put in /tmp/)
Prerequisites:
- EC secp384r1 key generated, stored in secure element and exported to /tmp/private_key
- Some HTTP server running on *:37777
Basic Boost ASIO server attached (server.zip)
Steps to reproduce:
- Generate a certificate for HaProxy:
export OPENSSL_CONF=/etc/openssl-sss-se050.cnf
openssl req -new -key /tmp/private_key -out /tmp/servercert.csr -subj "/CN="
openssl x509 -req -days 365 -in /tmp/servercert.csr -signkey /tmp/private_key -out /tmp/servercert.crt
cat /tmp/private_key /tmp/servercert.crt > /tmp/servercert.pem
- Run HaProxy:
./haproxy -f /tmp/haproxy_dynamic.conf
- Run script from another host to spam TLS handshake:
Script attached (spam_tls.py)
python spam_tls.py <IP_address>
- After some time (1-10 minutes), the following log can be seen in HaProxy process:
I've modified the middleware source code to also show errno, so we can see the first recv errno is 4 (EINTR Interrupted system call)
ssse-flw: EmbSe_Simple_Compute_Key invoked (ecdh)
ssse-dbg: ** nid = 715 **
ssse-flw: EmbSe_Simple_Compute_Key invoked (ecdh)
ssse-dbg: ** nid = 715 **
ssse-flw: No matching key in SE. Invoking OpenSSL API: ECDH_compute_key.
ssse-flw: No matching key in SE. Invoking OpenSSL API: ECDH_compute_key.
smCom :WARN :Client: recv() failed: error -1--4
smCom :WARN :nxEnsure:'0' failed. At Line:323 Function:smComSocket_TransceiveRawFD
sss :WARN :nxEnsure:'retStatus == SM_OK' failed. At Line:6987 Function:sss_se05x_channel_txn
sss :WARN :nxEnsure:'ret == SM_OK' failed. At Line:6884 Function:sss_se05x_TXn
sss :ERROR:Error in Se05x_API_CheckObjectExists
ssse-err: sss_key_object_get_handle for keyPair failed
- From now on, each request will generate the following error:
Each recv() call yields errno 11 (EAGAIN Try again)
ssse-flw: ECDH_compute_key by OpenSSL PASS
ssse-dbg: Using keyId=0x00000001
ssse-dbg: shaAlgo: 772
ssse-flw: SSS based sign (keyId=0x00000001, dgstLen=48)
APDU :DEBUG:CheckObjectExists []
APDU :DEBUG:kSE05x_TAG_1 [object id] = 0x1
smCom :DEBUG:Cmd (Len=11)
80 04 00 27 06 41 04 00 00 00 01
smCom :WARN :Client: recv() failed: error -1--11
smCom :WARN :nxEnsure:'0' failed. At Line:323 Function:smComSocket_TransceiveRawFD
sss :WARN :nxEnsure:'retStatus == SM_OK' failed. At Line:6987 Function:sss_se05x_channel_txn
sss :WARN :nxEnsure:'ret == SM_OK' failed. At Line:6884 Function:sss_se05x_TXn
sss :ERROR:Error in Se05x_API_CheckObjectExists
解決済! 解決策の投稿を見る。
I found the issue. HaProxy has a watchdog mechanism which emits a SIGALRM after some time and if that happens during a blocking read in the TPM engine, the syscall fails with EINTR and the engine closes the access manager fd, which causes all future IO ops to fail.
I've edited smComSocket_TransceiveRawFD to retry on EINTR and that indeed solved the issue.
I think that should be fixed in the middleware? It shouldn't assume the program which links to the middleware doesn't use signals? Let me know if you plan an official patch for this.
Hi @szymon-kobylecki ,
As far as I know, the openssl config file should be openssl11_sss_se050.cnf when you are using openssl 1.1.1l, and the MW version is not the latest, please kindly refer to https://www.nxp.com/webapp/Download?colCode=SE05x-PLUG-TRUST-MW&appType=license for details.
Please also update the cmake option of PTMW_Applet according to the following :
Hope that helps,
Have a great day,
Kan
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi I've tried your suggestions, unfortunately the issue is still there. Is there anything I can do to debug this issue more easily?
I found the issue. HaProxy has a watchdog mechanism which emits a SIGALRM after some time and if that happens during a blocking read in the TPM engine, the syscall fails with EINTR and the engine closes the access manager fd, which causes all future IO ops to fail.
I've edited smComSocket_TransceiveRawFD to retry on EINTR and that indeed solved the issue.
I think that should be fixed in the middleware? It shouldn't assume the program which links to the middleware doesn't use signals? Let me know if you plan an official patch for this.