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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20110409184559.41b947af@lxorguk.ukuu.org.uk>
Date:	Sat, 9 Apr 2011 18:45:59 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Harald Welte <laforge@...monks.org>
Cc:	Lauro Ramos Venancio <lauro.venancio@...nbossa.org>,
	linux-kernel@...r.kernel.org,
	Aloisio Almeida <aloisio.almeida@...nbossa.org>,
	Arnd Bergmann <arnd@...db.de>, Waldemar.Rymarkiewicz@...to.com
Subject: Re: [RFC] NFC subsystem prototype

>    If you're worried about SPI-attached RFID/NFC ASICs, then I think the
>    propper approach is to have a generic support for exporting SPI devices to
>    userspace (similar to what we have with usb + libusb).

That bit in my experience doesn't work. Most i²c devices for example end
up needing an actual kernel driver because you have to manage the
transaction flow to stop users breaking things horribly.

>    I simply do not see the advantage of having this in the kenrel.  There are
>    no latency/timing constraints, and the amount of data you are moving is so
>    small, that performance considerations also don't really play any role.

The big one is security management - once you've got readers that are
needing to report different stuff to different people you need at least
the muxing in kernel. It also separates protocol stacks from apps which
is rather important in more complex systems.

> 2) even if you go for an in-kernel subsystem, what is your strategy for the
>    many existing CL-RC5xx / CL-RC6xx ASIC based RFID/NFC readers?  For them,
>    you typically need your own software implementation of the anti-collision
>    procedures of 14443-3 (a+b) and the T=CL (14443-4) code.  All of this has
>    been implemented in userspace e.g. librfid - but do you want to port or
>    re-implement it all in kernel-land, and then 'glue' it below your current
>    NFC subsystem approach?

The obvious thing would be to plug it into the kernel at a higher level
than the raw asic interface. We manage that sort of stuff with all sorts
of network devices just fine, and in fact we'll need chunks of that
anyway for virtualisation of rfid/nfc.
--
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/