linux-kernel - Re: USB mini-summit at LinuxCon Vancouver

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: <alpine.LNX.2.00.1108111235400.27040@banach.math.auburn.edu>
Date:	Thu, 11 Aug 2011 15:01:30 -0500 (CDT)
From:	Theodore Kilgore <kilgota@...ach.math.auburn.edu>
To:	Alan Stern <stern@...land.harvard.edu>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	Hans de Goede <hdegoede@...hat.com>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Greg KH <greg@...ah.com>, linux-usb@...r.kernel.org,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	libusb-devel@...ts.sourceforge.net, Alexander Graf <agraf@...e.de>,
	Gerd Hoffmann <kraxel@...hat.com>, hector@...cansoft.com,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Stefan Hajnoczi <stefanha@...ux.vnet.ibm.com>,
	pbonzini@...hat.com, Anthony Liguori <aliguori@...ibm.com>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Oliver Neukum <oliver@...kum.org>, Felipe Balbi <balbi@...com>,
	Clemens Ladisch <clemens@...isch.de>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Adam Baker <linux@...er-net.org.uk>
Subject: Re: USB mini-summit at LinuxCon Vancouver



On Thu, 11 Aug 2011, Alan Stern wrote:

> On Thu, 11 Aug 2011, Alan Cox wrote:
> 
> > Actually there are more issues than that - you've also got to worry about
> > a security/permission model, and that is hard to get right, especially if
> > you are not very careful that anything that can be retrieved which might
> > violate the security model (eg the last frame on the capture) has been
> > blanked before handover etc.
> 
> As far as I can tell, these same security issues exist today.  I don't 
> see them getting any worse than they are now.
> 
> > And applications that are touching both video (even indirectly) and still
> > camera may get surprise deadlocks if they accidentally reference both the
> > still and video device even via some library or service.
> 
> No, not deadlocks.  Just -EBUSY errors.
> 
> > > > Well, a user program can assume that the kernel driver left the device
> > > > in a clean state.  The reverse isn't always true, however -- it's one
> > 
> > Not it cannot - the user program doesn't know
> > 
> > a) if the kernel driver has ever been loaded
> > b) the values the kernel driver leaves set (and those will change no
> > doubt at times)
> > c) if the camera has been plugged and unplugged and not yet had the
> > kernel driver loaded
> 
> That's true.  The program can't assume that a kernel driver was ever 
> bound to the device; all it can assume is that _if_ a kernel driver was 
> bound then it left the device in a sane state -- whatever "sane" might 
> mean in this context.
> 
> > To me it sounds like a recipe for disaster. For those tiny number of
> > devices involved just use V4L and if need be some small V4L tweaks to
> > handle still mode. In most cases the interface is basically identical and
> > I'd bet much of the code is identical too.
> 
> I'm not against moving the whole thing into the kernel.  I'm just
> pointing out that an easier-to-code-up solution will accomplish much
> the same result.
> 
> Alan Stern
> 

Alan,

As I said, I am agnostic, though leaning in the direction that Hans de 
Goede is pointing. What he says about a single control mechanism seems to 
make a lot of sense. If you can come up with an outline of the "easier to 
code" solution, that would be interesting, though.

I assume you are also going to be in Vancouver? If you will be there on 
Monday, then Hans and I are already planning to meet and discuss. 

BTW, as to using V4L with "tweaks" to handle still mode, it would probably 
be more difficult than is imagined. For, though the operations required to 
process still images and webcam frames are in principle similar, the 
priorities and constraints are too different. Therefore, my understanding 
is that the libgphoto2 image processing routines, not the libv4l image 
processing routines, would still be used for still images.

Theodore Kilgore
--
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/