public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roland Stigge <stigge@antcom.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: gregkh@linuxfoundation.org, grant.likely@secretlab.ca,
	linus.walleij@linaro.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, w.sang@pengutronix.de,
	jbe@pengutronix.de, plagnioj@jcrosoft.com, highguy@gmail.com,
	broonie@opensource.wolfsonmicro.com, daniel-gl@gmx.net,
	rmallon@gmail.com, tru@work-microwave.de, sr@denx.de,
	wg@grandegger.com
Subject: Re: [PATCH 0/6 v10] gpio: Add block GPIO
Date: Fri, 07 Dec 2012 18:33:28 +0100	[thread overview]
Message-ID: <50C22868.4070405@antcom.de> (raw)
In-Reply-To: <20121207170215.0057f791@pyramind.ukuu.org.uk>

On 12/07/2012 06:02 PM, Alan Cox wrote:
>>>> Currently we can set different permissions on different GPIO lines. Your
>>>> driver change drives a truck through this facility.
>>
>> What I maybe misread in your concern: The dev interface is actually an
>> "alternative to sysfs for block GPIO", not considered as a replacement
>> for the current sysfs interface for _single_ GPIOs.
> 
> That is the problem. If you add the driver then you can no longer
> implement the same permissions per node. If I've got a typical hardened
> embedded device running something like SMACK I can tie a few gpio lines
> to specific tasks in the security model.
> 
> The moment there is another driver anyone who can open that driver can
> bypass all the security rules being imposed.
> 
> The basic problem is that right now our mapping is
> 
> "gpio line is a file system object"
> 
> you change it to
> 
> "all gpio lines are a single file system object"

No - maybe that's still not documented well enough: Upon defining a GPIO
block, you can specify each individual GPIO that's contained therein.
Define as many (disjoint) blocks as you want with as many permission
sets as you want, right away.

In the extreme case, define blocks with only a single GPIO in each of
them, and the interface should still be faster than the sysfs one. Each
block is a separate device node with separate permissions.

Further, block GPIOs only need to be present on systems where firmware
tells via DT (or the kernel itself in setup code) explicitely which
GPIOs should be in a certain block to be accessed efficiently.

Sysfs can still work as expected, at least for the remaining GPIOs.

So I don't see a contradiction here, considering that you can still
organize permissions for the (optional) GPIO block, as you do currently
via sysfs.

You can also compare sysfs and block GPIO interfaces to block devices
where you create file systems on top. Userspace can access both, but
it's not very useful to access the underlying block device at the same
time when it's also mounted as an fs. The good thing about the sysfs and
block GPIO case is that you can use both at the same time: Consider a
single controller/gpio_chip containing 32 lines. You can define a GPIO
block of 16 of them for use as an efficient 16 bit bus, and use the rest
via single GPIO sysfs as you described.

Thanks for considering,

Roland

  reply	other threads:[~2012-12-07 17:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-06 21:47 [PATCH 0/6 v10] gpio: Add block GPIO Roland Stigge
2012-12-06 21:47 ` [PATCH 1/6 v10] gpio: Add a block GPIO API to gpiolib Roland Stigge
2012-12-06 21:47 ` [PATCH 2/6 v10] gpio: Add sysfs support to block GPIO API Roland Stigge
2012-12-06 21:47 ` [PATCH 3/6 v10] gpio: Add userland device interface to block GPIO Roland Stigge
2012-12-06 21:47 ` [PATCH 4/6 v10] gpiolib: Fix default attributes for class Roland Stigge
2012-12-06 21:47 ` [PATCH 5/6 v10] gpio: Add device tree support to block GPIO API Roland Stigge
2012-12-06 21:47 ` [PATCH 6/6 v10] gpio: Add block gpio to several gpio drivers Roland Stigge
2012-12-07 10:36 ` [PATCH 0/6 v10] gpio: Add block GPIO Alan Cox
2012-12-07 12:06   ` Roland Stigge
2012-12-07 12:16     ` Roland Stigge
2012-12-07 17:02       ` Alan Cox
2012-12-07 17:33         ` Roland Stigge [this message]
2012-12-07 21:28           ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50C22868.4070405@antcom.de \
    --to=stigge@antcom.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=daniel-gl@gmx.net \
    --cc=grant.likely@secretlab.ca \
    --cc=gregkh@linuxfoundation.org \
    --cc=highguy@gmail.com \
    --cc=jbe@pengutronix.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=plagnioj@jcrosoft.com \
    --cc=rmallon@gmail.com \
    --cc=sr@denx.de \
    --cc=tru@work-microwave.de \
    --cc=w.sang@pengutronix.de \
    --cc=wg@grandegger.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox