An exchange with a NFC target must complete within NCI_DATA_TIMEOUT.
A delay of 700 ms is not sufficient for cryptographic operations on smart
cards. CardOS 6.0 may need up to 1.3 seconds to perform 256-bit ECDH
or 3072-bit RSA. To prevent brute-force attacks, passports and similar
documents introduce even longer delays into access control protocols
(BAC/PACE).

The timeout should be higher, but not too much. The expiration allows
us to detect that a NFC target has disappeared.

Expose data_timeout as a parameter of nci.ko. Keep the value in uint
nci_data_timeout, set the default to 3 seconds. Point NCI_DATA_TIMEOUT
to the new variable.

Signed-off-by: Juraj Šarinay <juraj@sarinay.com>
---
v2:
  - export nci_data_timeout to survive make allmodconfig
v1: https://lore.kernel.org/netdev/20250825134644.135448-1-juraj@sarinay.com/

 include/net/nfc/nci_core.h | 4 +++-
 net/nfc/nci/core.c         | 5 +++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index e180bdf2f82b..da62f0da1fb2 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -52,7 +52,9 @@ enum nci_state {
 #define NCI_RF_DISC_SELECT_TIMEOUT		5000
 #define NCI_RF_DEACTIVATE_TIMEOUT		30000
 #define NCI_CMD_TIMEOUT				5000
-#define NCI_DATA_TIMEOUT			700
+
+extern unsigned int nci_data_timeout;
+#define NCI_DATA_TIMEOUT			nci_data_timeout
 
 struct nci_dev;
 
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index fc921cd2cdff..29fac0dd6c77 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -31,6 +31,11 @@
 #include <net/nfc/nci_core.h>
 #include <linux/nfc.h>
 
+unsigned int nci_data_timeout = 3000;
+module_param_named(data_timeout, nci_data_timeout, uint, 0644);
+MODULE_PARM_DESC(data_timeout, "Round-trip communication timeout in milliseconds");
+EXPORT_SYMBOL_GPL(nci_data_timeout);
+
 struct core_conn_create_data {
 	int length;
 	struct nci_core_conn_create_cmd *cmd;
-- 
2.47.2

On 26/08/2025 01:43, Juraj Šarinay wrote:
> An exchange with a NFC target must complete within NCI_DATA_TIMEOUT.
> A delay of 700 ms is not sufficient for cryptographic operations on smart
> cards. CardOS 6.0 may need up to 1.3 seconds to perform 256-bit ECDH

CardOS is the software running on the NFC card, right? If so, why would
this be Linux kernel module param? Kernel runtime setup is really
independent of what NFC card people will use.

I think this should be unconditionally raised or at least bring argument
why this should be a module param.

> or 3072-bit RSA. To prevent brute-force attacks, passports and similar
> documents introduce even longer delays into access control protocols
> (BAC/PACE).
> 
> The timeout should be higher, but not too much. The expiration allows
> us to detect that a NFC target has disappeared.
> 
> Expose data_timeout as a parameter of nci.ko. Keep the value in uint
> nci_data_timeout, set the default to 3 seconds. Point NCI_DATA_TIMEOUT
> to the new variable.
> 
> Signed-off-by: Juraj Šarinay <juraj@sarinay.com>




Best regards,
Krzysztof

On Wed, 2025-08-27 at 15:29 +0200, Krzysztof Kozlowski wrote:

> CardOS is the software running on the NFC card, right? 

Yes it is. I may have been too specific, all I am saying is that I made
some measurements.

> If so, why would this be Linux kernel module param? Kernel runtime setup is really
> independent of what NFC card people will use.

I suggested a tunable timeout because I am not sure what the new
universal upper bound should be. It may depend on the NFC card one is
communicating with. I have since learned that module parameters are
strongly discouraged (within netdev at least).

> I think this should be unconditionally raised

I am fine with that, but would argue for an even more generous timeout.
Five seconds, say? One can always set a shorter SO_RCVTIMEO from user
space if needed.

Ideally, the kernel would also honor a longer SO_RCVTIMEO and treat
NCI_DATA_TIMEOUT as a default rather than a rigid limit, completely
obviating my subjective need for a parameter. I have not explored the
idea further, given that a somewhat higher value of NCI_DATA_TIMEOUT
solves most problems.

Best,
Juraj