linux-kernel - Re: [PATCH 3/3] usb: cp210x: Add ioctl for GPIO 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]

Date:	Wed, 2 May 2012 23:59:39 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Preston Fick <pffick@...il.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
	preston.fick@...abs.com
Subject: Re: [PATCH 3/3] usb: cp210x: Add ioctl for GPIO support

> > Ok now in your user application how are you going to find which gpio
> > numbers to use that are associated with this specific port,
> 
> Just look at the gpio device that has ttyUSB0 as its parent.

Taking care of course that you keep the ttyUSB file handle open while you
do so, ugly from user space, hideous from kernel space.

> 
> > and how is udev going to do that to manage permissions ?
> 
> How does udev handle permissions for gpio devices today?

It sticks its fingers in its ears and goes "la la la"

> > So you need an ioctl to give you the range that is mapped to this (or a
> > sysfs node, but the sysfs node makes the security problem pretty
> > much insoluble)
> 
> range for what?  Doesn't the gpio interfac provide the size of the gpio
> registers to userspace?

If you fish them out via sysfs trees yes.

>> > 	open /dev/ttyUSB0 [or sysfs node]
> > 	read gpio numbers
> > 	close 
> > 
> > 	open gpio foo
> > 
> > Oh dear... so random shell scripting user is going to screw up horribly.
> 
> What's the odds that the data going across the tty link corrisponds with
> the gpio control?

I think you missed the problem - which speaks volumes for the interface
issue

	open sysfs node
	read gpio numbers
	close

			unplug 
			new device
				assigned the same gpio numbers
	open gpio
	whoops - that was the milling machine not the smartcard

> And shell scripting the gpio interface is used today, I've seen it on
> the beaglebone machine.

Yes it works very well but that isn't the issue.

> > I think it basically boils down to this
> > 
> > If you have a serial port with some gpio lines that drive arbitary
> > unrelated electronics then the gpio interface is handy because you can
> > use the same code logic as if it was wired to other pins elsewhere
> > 
> > If you are using them as part of the tty interface as extra control lines
> > (eg for smartcard protocols) then you want them driven via the tty
> > interface and doubly so once we add some of the smartcard/sim ldisc
> > support.
> > 
> > Hence we really need to expose them both ways because end users are doing
> > both things with the gpio pins on these ports.
> > 
> > So I'd suggest we expose them via termiox bits and also via the tty
> > providing gpio range info in a standardised way.
> 
> Ok, I'll wait for your proposed standardised way before complaining any
> more :)

I think I'd suggest we support the following


open /dev/ttyUSB0
get gpio info somehow
run via gpio interface
close /dev/ttyUSB0

and

open /dev/ttyUSB0
via termiox( what gpios do you have )
via termiox( set/get gpio values)
close /dev/ttyUSB0

that would support the ldisc use of them. I need to go read the specs on
that and look at some hardware. I think we may need a mapping ioctl too
because the pin allocations may need to be described in terms of "pin 0
is this reader signal", "pin 1 is that"

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