netdev - Re: [PATCH net-next v2] net: nfc: Propagate ISO14443 type A target ATS to userspace via netlink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241106101804.GM4507@kernel.org>
Date: Wed, 6 Nov 2024 10:18:04 +0000
From: Simon Horman <horms@...nel.org>
To: Juraj Šarinay <juraj@...inay.com>
Cc: netdev@...r.kernel.org, krzk@...nel.org, kuba@...nel.org
Subject: Re: [PATCH net-next v2] net: nfc: Propagate ISO14443 type A target
 ATS to userspace via netlink

On Sun, Nov 03, 2024 at 01:45:25PM +0100, Juraj Šarinay wrote:
> Add a 20-byte field ats to struct nfc_target and expose it as
> NFC_ATTR_TARGET_ATS via the netlink interface. The payload contains
> 'historical bytes' that help to distinguish cards from one another.
> The information is commonly used to assemble an emulated ATR similar
> to that reported by smart cards with contacts.
> 
> Add a 20-byte field target_ats to struct nci_dev to hold the payload
> obtained in nci_rf_intf_activated_ntf_packet() and copy it to over to
> nfc_target.ats in nci_activate_target(). The approach is similar
> to the handling of 'general bytes' within ATR_RES.

Hi Juraj,

Perhaps I misunderstand things, and perhaps there is precedence in relation
to ATR_RES. But I am slightly concerned that this leans towards exposing
internal details rather then semantics via netlink.

> Replace the hard-coded size of rats_res within struct
> activation_params_nfca_poll_iso_dep by the equal constant NFC_ATS_MAXSIZE
> now defined in nfc.h
> 
> Within NCI, the information corresponds to the 'RATS Response' activation
> parameter that omits the initial length byte TL. This loses no
> information and is consistent with our handling of SENSB_RES that
> also drops the first (constant) byte.
> 
> Tested with nxp_nci_i2c on a few type A targets including an
> ICAO 9303 compliant passport.
> 
> I refrain from the corresponding change to digital_in_recv_ats()
> to have the few drivers based on digital.h fill nfc_target.ats,
> as I have no way to test it. That class of drivers appear not to set
> NFC_ATTR_TARGET_SENSB_RES either. Consider a separate patch to propagate
> (all) the parameters.
> 
> Signed-off-by: Juraj Šarinay <juraj@...inay.com>

...