linux-kernel - Re: [RFC] NFC subsystem prototype

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 for Android: free password hash cracker in your pocket

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

Message-ID: <BANLkTi=T42zgY0hy4_u7YKboYuuUiRg_Yw@mail.gmail.com>
Date:	Thu, 14 Apr 2011 19:57:57 -0300
From:	Lauro Ramos Venancio <lauro.venancio@...nbossa.org>
To:	Samuel Ortiz <sameo@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] NFC subsystem prototype

Hi Samuel,

2011/4/14 Samuel Ortiz <sameo@...ux.intel.com>:

>> Subsystem Operations:
>>       - start poll - start polling for targets using the protocols given as
>> parameter
>>       - stop poll - stop polling
>>       - activate target - activate a target for communication using a
>> specific protocol
>>       - deactivate target - deactivate a target
>>       - reset device - put the adapter in idle mode
>>       - data exchange - low level data exchange (send and receive data)
> I suppose the data_exchange hook is sitting at the NFCIP level ? As I agree
> with your further comment that this one should not be part of the netlink
> API but should be done through sockets instead, I think this one should be
> defined as the netdev start_xmit hook.
> So this matches quite well the pn533 API, but I'm wondering how you're
> planning to support the HCI based devices (pn544, microread). We clearly
> have 2 kind of devices here, and it reminds me of the soft MAC vs full MAC
> problem in the 802.11 subsystem.
> I think we should have a kernel NFC HCI layer that would implement those
> hooks by following the HCP protocol. Then devices that only take HCI
> commands (kind of soft MAC NFC devices) would register against the NFC HCI
> layer and use those hooks. Other devices (e.g. pn533) would register at a
> higher level (The NFC core layer) and provide their own hooks. This would be
> similar to what 802.11 drivers do by registering against mac80211 (soft MACs)
> or directly against cfg80211 (full MACs).

I fully agree. The prototype was designed with pn533 and pn544 in
mind. When the pn544 device driver is implemented, we will need
another layer for the HCI implementation.


>> Further work:
>>       - Define subsystem operations for adapters in "target mode"
> I am not sure we need any specific additional hook for the target mode. In
> this mode, we mostly would be sending events (RF field ON, card activated
> or deactivated). After that, afaiu, the card would be expecting data
> reception, and then sending responses to it.

I think the main part is the handling of timing constraints between
the data reception and the response using a socket interface.

> We probably need to add a mode setting hook in the ops structure. And also,
> according to NFCIP-2, NFC devices should by default be in target mode.

The selection between proximity and vicinity is partially covered by
the protocols selection in start_poll operation.

Probably, the polling loop needs to have an initiator mode phase and a
target mode phase in a cycle (as the PN544 Polling management).


Regards,

Lauro Ramos Venancio
INdT - Instituto Nokia de Tecnologia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/