linux-kernel - Re: [char-misc-next 1/3] mei: nfc: Initial nfc implementation

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]

Date:	Thu, 11 Apr 2013 00:52:05 +0200
From:	Samuel Ortiz <sameo@...ux.intel.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Tomas Winkler <tomas.winkler@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [char-misc-next 1/3] mei: nfc: Initial nfc implementation

Hi Arnd,

On Thu, Apr 11, 2013 at 12:29:38AM +0200, Arnd Bergmann wrote:
> On Wednesday 10 April 2013, Samuel Ortiz wrote:
> > > > That works fine with the typical case where your pn544 is directly accessible
> > > > through i2c. But if it's sitting behind the ME, you will need to send
> > > > commands exported through this file to fetch the vendor and radio IDs, but
> > > > also to send those HCI frames that the vanilla Android stack builds after
> > > > encapsulating them into a struct mei_nfc_cmd. And this is all done through the
> > > > /dev/mei interface.
> > > 
> > > No NFC data should be going through /dev/mei, use the proper kernel apis
> > > please.
> > Not my choice, I'm sorry. And I'm not the one who's going to implement the
> > adaptation layer for the Android stack to properly work over /dev/mei, other
> > folks at Intel will.
> > If an Android OEM decides he wants a pn544 NFC chipset behind an x86 ME, then
> > NFC data will go through /dev/mei. I don't like it, but this is a business
> > decision I have no control over.
> 
> Welcome to the crap that we have to deal with on ARM all the time. Seriously,
> you may not be able to stop people from doing something stupid, but you
> should not pave their way. Exporting a header file to user space, when the
> only possible use of that header is to do the wrong thing helps nobody.
Although I'm pretty sure the reasons for Android not to use the kernel NFC APIs
and stack are all but technical ones, I agree with your statement here.


> If someone seriously wants to use /dev/mei in that way, they can easily
> provide the header file themselves, or patch the kernel in any way necessary.
I'm fine with moving nfc.h back to drivers/misc/mei/

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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/