linux-kernel - Re: [linux-usb-devel] [RFC] HID bus design overview.

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: <4610D771.4020806@codemercs.com>
Date:	Mon, 02 Apr 2007 12:14:09 +0200
From:	Robert Marquardt <marquardt@...emercs.com>
To:	Jiri Kosina <jkosina@...e.cz>
CC:	Dmitry Torokhov <dtor@...ightbb.com>, Li Yu <raise.sail@...il.com>,
	yanghong@...ss.com.cn,
	linux-usb-devel <linux-usb-devel@...ts.sourceforge.net>,
	hongzhiyi@...ss.com.cn, Marcel Holtmann <marcel@...tmann.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] [RFC] HID bus design overview.

Jiri Kosina wrote:

> I agree. I am aware of devices for which just inspecting the parsed data 
> would be OK (some keyboards with usage mappings which are not defined by 
> HUT, for example), but also of devices which require special handling on 
> the report level - Robert Marquardt pointed me in a private mail to a few 
> devices which are broken par-excellence, and for which handling on report 
> level would be convenient.
> 
> Also, handling on report level would be nice to have so that we could hook 
> a hidraw driver to it.

Just forgot to use "Reply All".

Here is the text (expanded):
Definitely. I know of several devices where the HID descriptor and the 
data sent completely disagree.
A Metex USB Multimeter for example tells that it has a 4 byte report 
divided into a 3 byte and a 1 byte element. The device sends two reports 
each containing two 2 byte elements with one in the second report not 
containing data.
The wierdest device is a CD archive torus which shows up as a simple 
standard mouse. Commands are sent by *reading* strings.
The Office Rocket Launcher is posing as a keyboard and reacts to the 
LEDs being set (this is of interest for the Num-Lock thread here).
I definitely hope that the latter two devices will never get official 
kernel support in any way.

Why is the report parsed on driver level at all? It should be possible 
to allow drivers to manipulate the reports, but i see no reason to split 
the report into usages that early. The Windows HID API parses the report 
happily in the HID.DLL for user programs. Drivers have the same API 
available on kernel level.
So a raw API for the drivers should be the primary API. It is usually 
easier to manipulate the report directly instead of abstract operations. 
It is also fairly safe. The device has been identified so the offending 
report layout can be presumed. Parsing for specific usages should be 
done from the driver. Preparsing the report before the data is handed to 
the driver only wastes CPU cycles.
-
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/