linux-kernel - [RFC] Configuration generic drivers at runtime

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-next>] [day] [month] [year] [list]

Date:	Sat, 10 Mar 2007 23:57:17 +0100
From:	Laurent Pinchart <laurent.pinchart@...net.be>
To:	linux-kernel@...r.kernel.org
Subject: [RFC] Configuration generic drivers at runtime

Hi everybody,

I'm writing a Linux driver for USB Video Class (UVC) devices. Before 
submitting it to the kernel, there are still a few rough corners I'd like to 
polish. Comments would be appreciated for the following one.

The UVC spec defines a way for device vendors to provide extensions to the 
standard through so-called extension units, identified by a GUID (Globally 
Unique IDentifier). An extension unit can define any number of controls 
(think of controls as simple parameters such as brightness, zoom, pan/tilt, 
shutter speed, ...). Devices advertise in their USB descriptors the extension 
units they support, along with the controls that are supported in each 
extension unit.

To access those extension units from user-space, the UVC driver will offer two 
methods. One of them will map the controls defined by extension units to V4L2 
controls. The question that arises is how to define and store those mappings.

And obvious solution would be to have an ever growing array in the driver, 
storing control information for all possible extension units ever defined by 
webcam vendors. While this is quite straightforward, it might not be the most 
usable solution for device vendors who wouldn't want debug controls to be 
included in the kernel by default, or who wouldn't want to submit new control 
definitions for inclusion in the kernel (with the implied delay) every time a 
new device comes out.

Another solution would be to introduce a way to define controls and mappings 
at runtime. Mappings would be stored in test-based user-space configuration 
files, distributed by vendors. A small user-space utility would add them 
through a few ioctls. This obviously raises some security concerns (regarding 
which users will be allowed to add mappings, or how many of them they can 
add).

I would like comments regarding the second solution. Is this something that is 
likely to be accepted in the mainline kernel ? I don't know of any other 
Linux driver implementing such kind of dynamic runtime configuration.

Best regards,

Laurent Pinchart
-
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/