linux-kernel - Re: [PATCH v2 1/4] gpiolib: Add "unknown" direction support

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: <4D5D0EAA.9030807@metafoo.de>
Date:	Thu, 17 Feb 2011 13:03:54 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Eric Miao <eric.y.miao@...il.com>
CC:	Peter Tyser <ptyser@...-inc.com>, linux-kernel@...r.kernel.org,
	Alek Du <alek.du@...el.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Uwe Kleine-K?nig <u.kleine-koenig@...gutronix.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Joe Perches <joe@...ches.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH v2 1/4] gpiolib: Add "unknown" direction support

On 02/17/2011 08:33 AM, Eric Miao wrote:
> On Thu, Feb 17, 2011 at 8:56 AM, Peter Tyser <ptyser@...-inc.com> wrote:
>> Previously, gpiolib would unconditionally flag all GPIO pins as inputs,
>> regardless of their true state.  This resulted in all GPIO output pins
>> initially being incorrectly identified as "input" in the GPIO sysfs.
>>
>> Since the direction of GPIOs is not known prior to having their
>> direction set, instead set the default direction to "unknown" to prevent
>> user confusion.  A pin with an "unknown" direction can not be written or
>> read via sysfs; it must first be configured as an input or output before
>> it can be used.
>>
> 
> Hrm... that's why I don't like the original definition of gpio_request()
> which is vague on the pin configurations.
Actually it doesn't say anything at all about the current configuration at all.
Requesting a pin grants you exclusive access to that pin, if it succeeds. So it
is solely about ownership and not about configuration.
Once you own a pin you are allowed to modify its configuration, otherwise you
should never touch it. And you shouldn't make any assumptions about its
previous configuration, if you want to use it as input you should explicitly
configure it as an input pin.

> The pin configuration should be clear upon requesting, otherwise it's a
> potential issue.
How so?

> 
> Anyway, this unknown state looks to be a good mitigation to this
> underlying problem. I'm good with it.
> 

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