linux-kernel - Re: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip

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, 17 Mar 2011 14:07:57 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Waldemar.Rymarkiewicz@...to.com
Cc:	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip

On Thursday 17 March 2011, Waldemar.Rymarkiewicz@...to.com wrote:
> >> >Note that the microread_is_busy() logic does not protect you from 
> >> >having multiple concurrent readers, because multiple threads may 
> >> >share a single file descriptor.
> >> 
> >> It's just used to ensure that only one reader can open the device.
> >> It's called only in open callback.
> >> The mutex actually secures concurrent read operations. 
> >
> >So if having multiple readers is safe (though possibly not 
> >meaningful), I guess you don't really need the 
> >microread_is_busy() logic.
> >
> >I suppose it doesn't hurt either, it just seems a bit 
> >pointless when it does the right thing most of the time, but 
> >not always.
> >
> 
> Could you give me an example when the microread_is_busy() logic does
> not do what it's intended to do. I don't really get your point here. 
> 

An application can open the device, and then do a pthread_create()
or a fork(). In either case, you have two concurrent threads that
have access to the file pointer and can read from it concurrently,
which is inherently racy regarding which of the processes gets the
data.

This is not very different from opening the file descriptor in
multiple processes, which you prevent using your logic.

You can of course argue that you try your best to prevent the
race. Traditionally, e.g. on serial ports and the like, we
don't do this but instead rely on user space synchronizing the
access. What you have to make sure of course is that multiple
threads calling read on the same file can never bring the
kernel driver into an invalid state.

	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/