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]

Message-Id: <201304110029.38938.arnd@arndb.de>
Date:	Thu, 11 Apr 2013 00:29:38 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Samuel Ortiz <sameo@...ux.intel.com>
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

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.

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.

	Arnd
--
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/