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: <20110811162530.5d1c6455@lxorguk.ukuu.org.uk>
Date:	Thu, 11 Aug 2011 16:25:30 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Hans de Goede <hdegoede@...hat.com>,
	Theodore Kilgore <kilgota@...ach.math.auburn.edu>,
	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

> Between two or more kernel drivers, a resource locking mechanism like the one 
> you've proposed works fine, but, when the driver is on userspace, there's one
> additional issue that needs to be addressed: What happens if, for example,
> if a camera application using libgphoto2 crashes? The lock will be enabled, and
> the V4L driver will be locked forever. Also, if the lock is made generic enough
> to protect between two different userspace applications, re-starting the
> camera application won't get the control back.

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.

> To avoid such risk, kernel might need to implement some ugly hacks to detect
> when the application was killed, and put the device into a sane state, if this
> happens.

At which point history says it's easier to do the job right, once, in the
kernel.

> Again, applications that won't implement this control will take the lock forever.

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.

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

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.

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/