Re: Driver for Microsoft USB Fingerprint Reader

Re: Driver for Microsoft USB Fingerprint Reader

[linux]

Alan Cox wrote:
> The very cheap readers all appear to be fairly crude image scanners, and
> they even lack hardware encryption/perturbation so they are actually of
> very limited value.

I utterly fail to see why multiple, generally knowledgeable people are
claiming that encryption in a fingerprint scanner is desirable.

As far as I can tell, the only thing you want is AUTHENTICATION - you
want proof that you are getting a "live" scan taken from a user
who's present, and not a replay of what was sent last week.

This is called "freshness" and is usually provided by including a
random "nonce" (known in other contexts as "magic cookie") in the
authenticated data.

That is,

1) Computer generates random nonce and sends to fingerprint reader
   as part of the "please scan" command.

2) Fingerprint reader scans the image, and hashes it along with the nonce.

3) Fingerprint reader sends the (unencrypted) scan back to the computer.

4) Fingerprint reader computes a digital signature of the hash computed
   in step 2, and sends it to the computer.

5) Computer verifies the signature, thereby proving that the reader
   read the fingerprint after receiving the nonce (or has been
   compromised internally).

To do it right, I'd have a per-reader signing key, signed by a vendor
model key, signed by a top-level vendor public key that's widely
published.  These signatures and the public keys they sign can be stored
in ROM.

Also note that, if using DSA, the raw fingerprint reader's data, hashed
with the device private key and nonce, will make an excellent seed
to generate the per-signature random nonce K.  It is a security disaster
if you make two signatures on different data with the same K, but by
combining some secret information and all of the input used to generate
the hash value, you guarantee that that will only happen if the data
signed is the same, in which case it's harmless.

Put another way, given the hash H to sign and the private key X,
you can let K = SHA(H,X).  (You can also hash in other data, but H and
X are available and sufficient.)


If you don't have the signature verification information, you can still
use the device, you just can't be sure you aren't experiencing a replay
attack.

Encryption is useless, as is authentication without a host-provided
nonce or other means of guaranteeing freshness.  You can just sniff
and replay.  I'm sure keyghost.com would be happy to sell you the
necessary hardware.

Not that I expect "A-1 Computer Corporation" in Shenzhen to have a clue
about these things, but you'd think that Microsoft would have one or
two competent employees left on the payroll.

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Drake]

linux@horizon.com wrote:
> I utterly fail to see why multiple, generally knowledgeable people are
> claiming that encryption in a fingerprint scanner is desirable.
> 
> As far as I can tell, the only thing you want is AUTHENTICATION - you
> want proof that you are getting a "live" scan taken from a user
> who's present, and not a replay of what was sent last week.
> 
> This is called "freshness" and is usually provided by including a
> random "nonce" (known in other contexts as "magic cookie") in the
> authenticated data.

The Digital Persona readers apparently use a challenge-response 
authentication scheme for the encryption. I think I know the 
challenge-sending and response-reading command structure but have not 
yet examined their effect on the encrypted fingerprint data.

> Not that I expect "A-1 Computer Corporation" in Shenzhen to have a clue
> about these things, but you'd think that Microsoft would have one or
> two competent employees left on the payroll.

Now theres an interesting story in this area. The Microsoft fingerprint 
readers are based on Digital Persona devices, and actually they seem to 
be completely identical. But when comparing bus traffic for the DP 
devices vs the MS devices, the DP devices send encrypted fingerprint 
data and the MS devices send it as unencrypted 8-bit greyscale.

Anyway, further investigation shows a 1 bit difference in the firmware 
uploaded to each device, and I have confirmed that this bit turns 
encryption on and off.

IOW, MS's device are capable of encryption but they explicitly turned it 
off at the firmware level.

Daniel

Re: Driver for Microsoft USB Fingerprint Reader

[Alan Cox]

Ar Iau, 2006-07-06 am 00:48 -0400, ysgrifennodd linux@horizon.com:
> As far as I can tell, the only thing you want is AUTHENTICATION - you
> want proof that you are getting a "live" scan taken from a user
> who's present, and not a replay of what was sent last week.

Read the papers on the subject. If I can get copies of the unencrypted
data I can use those to make fake fingers. 

A finger print is personal data, arguably sensitive personal data. That
means there are lots of duties to store it securely. It is also very
hard to revoke a fingerprint so theft of data is highly problematic as
it will allow me to generate fake fingers. Theft of encrypted data might
allow replay attacks on one PC. Big deal.

Alan

Re: Driver for Microsoft USB Fingerprint Reader

[Joel Jaeggli]

Alan Cox wrote:
> Ar Iau, 2006-07-06 am 00:48 -0400, ysgrifennodd linux@horizon.com:
>> As far as I can tell, the only thing you want is AUTHENTICATION - you
>> want proof that you are getting a "live" scan taken from a user
>> who's present, and not a replay of what was sent last week.
> 
> Read the papers on the subject. If I can get copies of the unencrypted
> data I can use those to make fake fingers. 
> 
> A finger print is personal data, arguably sensitive personal data. That
> means there are lots of duties to store it securely. It is also very
> hard to revoke a fingerprint so theft of data is highly problematic as
> it will allow me to generate fake fingers. Theft of encrypted data might
> allow replay attacks on one PC. Big deal.

A fingerprint is a good identity token, but it's not a secret, nor is it
really feasible to protect it (IE you leave them everywhere).

see:

http://www.schneier.com/crypto-gram-9808.html#biometrics

The transmission channel for the data must be protected in some way to
prevent replay attacks. challange response, radius style shared secret,
one-time-key approach

The data itself needs to be cryptographically secured on the
authenticating side because, otherwise you can game the identity system.

A- Alice subverts the machine containing the identity management system
and uses bobs finger print data to fool the identity management system
next time.

B - Substitution, alice replaces bobs fingerprint in the identity
management system with her own, now alice is bob.

biometric data might be useful as an identy token, but if used as the
sole source of authentication data it is pretty seriously lacking.

> Alan
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
-------------------------------------------------
Joel Jaeggli (joelja@uoregon.edu)
GPG Key Fingerprint:
5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

Re: Driver for Microsoft USB Fingerprint Reader

[Bodo Eggert]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Ar Iau, 2006-07-06 am 00:48 -0400, ysgrifennodd linux@horizon.com:

>> As far as I can tell, the only thing you want is AUTHENTICATION - you
>> want proof that you are getting a "live" scan taken from a user
>> who's present, and not a replay of what was sent last week.
> 
> Read the papers on the subject. If I can get copies of the unencrypted
> data I can use those to make fake fingers.

Copies like the one on the glass I used in the restaurant ...

> A finger print is personal data, arguably sensitive personal data. That
> means there are lots of duties to store it securely.

That's why every waiter will assiduously clean your glass. won't he?

> It is also very
> hard to revoke a fingerprint so theft of data is highly problematic as
> it will allow me to generate fake fingers.

That's the problem: You can't know who is acting responsibly and who isn't.
Therefore you can't reuse your fingerprint on different sites.

> Theft of encrypted data might
> allow replay attacks on one PC. Big deal.

ACK. It should be protected by a nonce, too, as long as you depend on
encryption. You should also authenticate the reader before prompting for
a fingerprint, otherwise the replacement device might store the image to a
secondary location. And don't forget to prompt for cleaning the scanner, I
have heared rumors about scanners erroneously authenticating the previous
user. You should also install a camera preventing an attacker to place his
own scanner on top of yours.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

http://david.woodhou.se/why-not-spf.html

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

As I said before, usefulness is something relative, and sometimes,
security is not a concern (even when talking about fingerprint
readers).
My intention with this is to try to create a catalog of fingerprint
readers' properties and I think that taking a look at vendors' SDKs
would be a good start.
As pointed out by Greg, it would be also interesting to export those
properties via sysfs instead of structure passing (or in addiction,
not sure yet).
I'm not sure though about relating fingerprint devices with V4L2 (even
the cheapest ones). Some other considerations discussed with Greg are
also:

1) extending those device informations to other classes, not only to
fingerprint readers
2) maybe using another layer to hold device properties based on
classes ( device driver -> device information layer -> sysfs+kobjects
) so we can have specific properties for "fingerprintreader" objects
and easier ways to export them to the sysfs layer, without explicit
declaration on the device driver
3) extend that layer also to non-USB devices ( bus-independent )

Maybe sysfs classes could have a list of default properties (for
example, /sys/class/fingerprint objects could hold a list of commom
fingerprint properties).

Bill, which fingerprint reader are you using ?

Daniel

-- 
What this world needs is a good five-dollar plasma weapon.

Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

Hello everybody.

I would like to develop a driver for any kind of fingerprint reader
that currently doesn't have a driver for linux, and I'm open for
suggestions on which device I should use. My first thought was the
microsoft usb fingerprint reader
(http://www.geeks.com/details.asp?invtid=DG2-00002-DT&cpc=SCH) because
it's a new device (and, of course, doesn't have any driver for linux),
it's cheap, and it's from MS (read "would be fun" =)

Before proceeding, I would like to know if:
1) Would it be ilegal to write a driver for such device (i.e., without
the permition of the hardware manufacturer) ?

2) Is there any standard on how the fingerprint should be presented to
userspace ? Currently the only fingerprint driver that I could find is
the Siemens ID Mouse driver (drivers/usb/misc/idmouse.c), and it
delivers the fingerprint as an image in pnm format thru a device like
/dev/idmouse0 (cat /dev/idmouse 0 > /tmp/fingerprint.pnm). Is this the
best way to deliver the image to userspace, or should we have an
centralized for that, or a centralized device like /dev/fingerprint0
(which then wraps to the idmouse driver or any other)

There are also other interesting devices like this
(http://www.geeks.com/details.asp?invtid=FIN002&cpc=SCH) that are
cheap and probably would be a better subject. I know that there are
some standards (something related to the resolution of the readers),
and some of the cheap ones don't meet some "high-profile security"
standards (I think from NSA or something like that). Maybe we should
also try any of those heavy-duty high-security gadgets too.

Another question: Is there any place (probably a webpage) where we can
see a list of hardware devices separated by category, and know if
there's already a driver for it (and the name/url of the maintainer)
or not, if there are plans to develop a driver for it or not, or to
form teams to develop it ? Like a webpage where I can browse and see
that the device X doesn't have any drivers for it (and people can go
and "vote" for a driver, so we can know which devices are most wanted
by users), and sign ourselves to develop it ? I think that it would be
cool. If there isn't anything like that, I can develop it myself and
somebody at kernel.org or another place could host it =]

Thanks,
Daniel

-- 
What this world needs is a good five-dollar plasma weapon.

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Drake]

Daniel Bonekeeper wrote:
> I would like to develop a driver for any kind of fingerprint reader
> that currently doesn't have a driver for linux, and I'm open for
> suggestions on which device I should use. My first thought was the
> microsoft usb fingerprint reader
> (http://www.geeks.com/details.asp?invtid=DG2-00002-DT&cpc=SCH) because
> it's a new device (and, of course, doesn't have any driver for linux),
> it's cheap, and it's from MS (read "would be fun" =)

Already done (well, in development with early working code):
http://dpfp.berlios.de

> Another question: Is there any place (probably a webpage) where we can
> see a list of hardware devices separated by category, and know if
> there's already a driver for it (and the name/url of the maintainer)
> or not, if there are plans to develop a driver for it or not, or to
> form teams to develop it ? Like a webpage where I can browse and see
> that the device X doesn't have any drivers for it (and people can go
> and "vote" for a driver, so we can know which devices are most wanted
> by users), and sign ourselves to develop it ? I think that it would be
> cool. If there isn't anything like that, I can develop it myself and
> somebody at kernel.org or another place could host it =]

For USB devices there is http://www.qbik.ch/usb/devices/

Daniel

Re: Driver for Microsoft USB Fingerprint Reader

[Alon Bar-Lev]

On 7/3/06, Daniel Bonekeeper <thehazard@gmail.com> wrote:
> Hello everybody.
>
> I would like to develop a driver for any kind of fingerprint reader
> that currently doesn't have a driver for linux, and I'm open for
> suggestions on which device I should use. My first thought was the
> microsoft usb fingerprint reader
> (http://www.geeks.com/details.asp?invtid=DG2-00002-DT&cpc=SCH) because
> it's a new device (and, of course, doesn't have any driver for linux),
> it's cheap, and it's from MS (read "would be fun" =)

Please consider UPEK reader.
It is available on all new Thinkpad laptops, and the vendor provides
only binary drivers.

http://www.upek.com/support/dl_linux_bsp.asp

I hate when vendors like ATI, Conexant and UPEK publish binary drivers
without publishing the chipset spec... They should decide whether
their IP is on the software part or on the hardware part, if it is on
the hardware part, they are making money in selling the hardware. If
it is on the software part, there is no reason why not providing the
information for others to write software to work with the primitive
hardware. So in either case there should be full hardware interface
disclosure.

Best Regards and Goodluck!
Alon Bar-Lev.

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

Hello Alon !
Unfortunately I don't have an accessible thinkpad laptop (luckly the
external usb devices may work the same way). From the USB readers at
http://www.upek.com/products/usb.asp, which one do you think that fits
better the hardware on your laptop ?

I was looking for any place that sells those devices and I could not
find any online (even though I found lots of SDK and matching engines
that supports them, like VeriFinger).

Is there any place where I can buy one of those readers ?

Daniel

On 7/3/06, Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> On 7/3/06, Daniel Bonekeeper <thehazard@gmail.com> wrote:
> > Hello everybody.
> >
> > I would like to develop a driver for any kind of fingerprint reader
> > that currently doesn't have a driver for linux, and I'm open for
> > suggestions on which device I should use. My first thought was the
> > microsoft usb fingerprint reader
> > (http://www.geeks.com/details.asp?invtid=DG2-00002-DT&cpc=SCH) because
> > it's a new device (and, of course, doesn't have any driver for linux),
> > it's cheap, and it's from MS (read "would be fun" =)
>
> Please consider UPEK reader.
> It is available on all new Thinkpad laptops, and the vendor provides
> only binary drivers.
>
> http://www.upek.com/support/dl_linux_bsp.asp
>
> I hate when vendors like ATI, Conexant and UPEK publish binary drivers
> without publishing the chipset spec... They should decide whether
> their IP is on the software part or on the hardware part, if it is on
> the hardware part, they are making money in selling the hardware. If
> it is on the software part, there is no reason why not providing the
> information for others to write software to work with the primitive
> hardware. So in either case there should be full hardware interface
> disclosure.
>
> Best Regards and Goodluck!
> Alon Bar-Lev.
>


-- 
What this world needs is a good five-dollar plasma weapon.

Re: Driver for Microsoft USB Fingerprint Reader

[Alon Bar-Lev]

Daniel Bonekeeper wrote:
> Hello Alon !
> Unfortunately I don't have an accessible thinkpad laptop (luckly the
> external usb devices may work the same way). From the USB readers at
> http://www.upek.com/products/usb.asp, which one do you think that fits
> better the hardware on your laptop ?

I think that the TCRE3C is similar to the laptop one. I also 
hope that it is the same... Also the laptop integrated one 
is USB device.

Here is my device information:

Bus 003 Device 011: ID 0483:2016 SGS Thomson Microelectronics
Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               1.00
   bDeviceClass            0 (Defined at Interface level)
   bDeviceSubClass         0
   bDeviceProtocol         0
   bMaxPacketSize0         8
   idVendor           0x0483 SGS Thomson Microelectronics
   idProduct          0x2016
   bcdDevice            0.01
   iManufacturer           1 STMicroelectronics
   iProduct                2 Biometric Coprocessor
   iSerial                 0
   bNumConfigurations      1
   Configuration Descriptor:
     bLength                 9
     bDescriptorType         2
     wTotalLength           39
     bNumInterfaces          1
     bConfigurationValue     1
     iConfiguration          0
     bmAttributes         0xa0
       Remote Wakeup
     MaxPower              100mA
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       0
       bNumEndpoints           3
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol      0
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            2
           Transfer Type            Bulk
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0040  1x 64 bytes
         bInterval               0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x02  EP 2 OUT
         bmAttributes            2
           Transfer Type            Bulk
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0040  1x 64 bytes
         bInterval               0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0004  1x 4 bytes
         bInterval              20


> I was looking for any place that sells those devices and I could not
> find any online (even though I found lots of SDK and matching engines
> that supports them, like VeriFinger).
> 
> Is there any place where I can buy one of those readers ?

Oh... I really don't know...
You can buy a new laptop :)

Best Regards,
Alon Bar-Lev.

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

hahahaha I wish I could... well, you are _always_ welcome to donate me
yours ! =P
I'll try more later to get one of those readers...

Reading Greg's comment, now I'm in doubt if this should really be in
kernel mode or at userspace. Since there is no standard (AFAIK) for
those readers, how should it be done ?

Another thing: where can I find documentation about the USB
architecture ? For example, I suppose that some (or all) USB devices
may have DMA capabilities... how is this done ?

[]'s
Daniel



On 7/3/06, Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> Daniel Bonekeeper wrote:
> > Hello Alon !
> > Unfortunately I don't have an accessible thinkpad laptop (luckly the
> > external usb devices may work the same way). From the USB readers at
> > http://www.upek.com/products/usb.asp, which one do you think that fits
> > better the hardware on your laptop ?
>
> I think that the TCRE3C is similar to the laptop one. I also
> hope that it is the same... Also the laptop integrated one
> is USB device.
>
> Here is my device information:
>
> Bus 003 Device 011: ID 0483:2016 SGS Thomson Microelectronics
> Device Descriptor:
>    bLength                18
>    bDescriptorType         1
>    bcdUSB               1.00
>    bDeviceClass            0 (Defined at Interface level)
>    bDeviceSubClass         0
>    bDeviceProtocol         0
>    bMaxPacketSize0         8
>    idVendor           0x0483 SGS Thomson Microelectronics
>    idProduct          0x2016
>    bcdDevice            0.01
>    iManufacturer           1 STMicroelectronics
>    iProduct                2 Biometric Coprocessor
>    iSerial                 0
>    bNumConfigurations      1
>    Configuration Descriptor:
>      bLength                 9
>      bDescriptorType         2
>      wTotalLength           39
>      bNumInterfaces          1
>      bConfigurationValue     1
>      iConfiguration          0
>      bmAttributes         0xa0
>        Remote Wakeup
>      MaxPower              100mA
>      Interface Descriptor:
>        bLength                 9
>        bDescriptorType         4
>        bInterfaceNumber        0
>        bAlternateSetting       0
>        bNumEndpoints           3
>        bInterfaceClass       255 Vendor Specific Class
>        bInterfaceSubClass      0
>        bInterfaceProtocol      0
>        iInterface              0
>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x81  EP 1 IN
>          bmAttributes            2
>            Transfer Type            Bulk
>            Synch Type               None
>            Usage Type               Data
>          wMaxPacketSize     0x0040  1x 64 bytes
>          bInterval               0
>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x02  EP 2 OUT
>          bmAttributes            2
>            Transfer Type            Bulk
>            Synch Type               None
>            Usage Type               Data
>          wMaxPacketSize     0x0040  1x 64 bytes
>          bInterval               0
>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x83  EP 3 IN
>          bmAttributes            3
>            Transfer Type            Interrupt
>            Synch Type               None
>            Usage Type               Data
>          wMaxPacketSize     0x0004  1x 4 bytes
>          bInterval              20
>
>
> > I was looking for any place that sells those devices and I could not
> > find any online (even though I found lots of SDK and matching engines
> > that supports them, like VeriFinger).
> >
> > Is there any place where I can buy one of those readers ?
>
> Oh... I really don't know...
> You can buy a new laptop :)
>
> Best Regards,
> Alon Bar-Lev.
>
>


-- 
What this world needs is a good five-dollar plasma weapon.

Re: Driver for Microsoft USB Fingerprint Reader

[Greg KH]

A: No.
Q: Should I include quotations after my reply?

On Mon, Jul 03, 2006 at 04:53:43PM -0400, Daniel Bonekeeper wrote:
> hahahaha I wish I could... well, you are _always_ welcome to donate me
> yours ! =P
> I'll try more later to get one of those readers...
> 
> Reading Greg's comment, now I'm in doubt if this should really be in
> kernel mode or at userspace. Since there is no standard (AFAIK) for
> those readers, how should it be done ?

It all depends on what you want the userspace interface to be.

> Another thing: where can I find documentation about the USB
> architecture ?

www.usb.org for the USB specs.  See the kernel built-in documentation
for a full document on how the Linux USB layer works.

> For example, I suppose that some (or all) USB devices may have DMA
> capabilities... how is this done ?

Heh, no, USB can't do DMA at all.  Why would you think they could?  It's
a serial bus that just streams data across it at relativly slow speeds.

thanks,

greg k-h

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

On 7/3/06, Greg KH <greg@kroah.com> wrote:
> A: No.
> Q: Should I include quotations after my reply?
>
> On Mon, Jul 03, 2006 at 04:53:43PM -0400, Daniel Bonekeeper wrote:
> > hahahaha I wish I could... well, you are _always_ welcome to donate me
> > yours ! =P
> > I'll try more later to get one of those readers...
> >
> > Reading Greg's comment, now I'm in doubt if this should really be in
> > kernel mode or at userspace. Since there is no standard (AFAIK) for
> > those readers, how should it be done ?
>
> It all depends on what you want the userspace interface to be.
>

That's one problem: I don't want to create one more userspace
interface for that. I suppose that all the hundreds of fingerprint
readers that ships with a SDK have their own way of doing that.. that
looks awfull to me, even though I believe that currently there isn't
any uniform way of working with fingerprint readers... shouldn't we
have a way to classify devices ? For example, if I want to list all
the printers connected via USB (supposing that we have more than one),
I should be able to request that information from somewhere
(/dev/usb/printers/* ?) I suppose that different fingerprint readers
works with different resolutions... we should be able to have an
unified interface that could tell the userspace the capabilities of
each fingerprint device (the area size of the scanner, resolution,
etc)... I think that applies for a lot of devices, not just
fingerprint readers. Probably there is already something like that.

> > Another thing: where can I find documentation about the USB
> > architecture ?
>
> www.usb.org for the USB specs.  See the kernel built-in documentation
> for a full document on how the Linux USB layer works.

Thanks... UTFG for me. #)

> > For example, I suppose that some (or all) USB devices may have DMA
> > capabilities... how is this done ?
>
> Heh, no, USB can't do DMA at all.  Why would you think they could?  It's
> a serial bus that just streams data across it at relativly slow speeds.
>

Well.. even though I didn't know how and was a bit suspicious, I used
to believe that USB devices could do DMA because I heard some time ago
about "the danger of USB devices that could do DMA and have total
access over the OS"... something on bugtraq or securityfocus...
talking about USB and FireWire devices and how they could be used to
"inject" stuff on the system's memory and take it over... but I guess
it only applies to firewire (even though USB was clearly mentioned).
Reviewing it, it definitely applies just for firewire stuff.

http://www.csoonline.com/read/050106/ipods.html


> thanks,
>
> greg k-h
>


-- 
What this world needs is a good five-dollar plasma weapon.

Re: Driver for Microsoft USB Fingerprint Reader

[Greg KH]

On Mon, Jul 03, 2006 at 06:11:03PM -0400, Daniel Bonekeeper wrote:
> >> Reading Greg's comment, now I'm in doubt if this should really be in
> >> kernel mode or at userspace. Since there is no standard (AFAIK) for
> >> those readers, how should it be done ?
> >
> >It all depends on what you want the userspace interface to be.
> >
> 
> That's one problem: I don't want to create one more userspace
> interface for that. I suppose that all the hundreds of fingerprint
> readers that ships with a SDK have their own way of doing that.. that
> looks awfull to me, even though I believe that currently there isn't
> any uniform way of working with fingerprint readers... shouldn't we
> have a way to classify devices ? For example, if I want to list all
> the printers connected via USB (supposing that we have more than one),
> I should be able to request that information from somewhere
> (/dev/usb/printers/* ?) I suppose that different fingerprint readers
> works with different resolutions... we should be able to have an
> unified interface that could tell the userspace the capabilities of
> each fingerprint device (the area size of the scanner, resolution,
> etc)... I think that applies for a lot of devices, not just
> fingerprint readers. Probably there is already something like that.

Yes, we should have one way of identifying them.  I've talked with Dan
already about this in the past.  Please see his driver for support for a
few devices already.

> >> For example, I suppose that some (or all) USB devices may have DMA
> >> capabilities... how is this done ?
> >
> >Heh, no, USB can't do DMA at all.  Why would you think they could?  It's
> >a serial bus that just streams data across it at relativly slow speeds.
> >
> 
> Well.. even though I didn't know how and was a bit suspicious, I used
> to believe that USB devices could do DMA because I heard some time ago
> about "the danger of USB devices that could do DMA and have total
> access over the OS"... something on bugtraq or securityfocus...
> talking about USB and FireWire devices and how they could be used to
> "inject" stuff on the system's memory and take it over... but I guess
> it only applies to firewire (even though USB was clearly mentioned).
> Reviewing it, it definitely applies just for firewire stuff.
> 
> http://www.csoonline.com/read/050106/ipods.html

Yes, firewire and USB is very different.  You can't dma memory directly
out using USB, although I've heard rumors that through the USB debug
port you might be able to do that, but as that requires a custom cable,
which no one will give me, I can't confirm or deny that yet...

thanks,

greg k-h

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

I think that I didn't make myself clear on that... let me try to
explain on what I'm thinking to do. Let's take as example Dan's driver
at http://prdownload.berlios.de/dpfp/dpfp-driver-0.1.2.tar.bz2.

On our usb_device_id, we specify the vendor of the device, etc. We
could also (I don't know if this is the best place to do that) specify
which kind of device is it (printer, storage, fingerprint reader, HID,
etc). Let's suppose that we have some #define's or a enum that specify
the hundreds of different device types (is that possible ? :) Nothing
that a USB_GENERIC can't solve lol).

enum usb_device_type {
	USB_DEVICE_SCANNER,
	USB_DEVICE_KEYBOARD,
	USB_DEVICE_MOUSE,
	USB_DEVICE_FINGERPRINT_READER,
	USB_DEVICE_GENERIC,
	...
};

For each device, he have some kind of struct that is complex enough to
describe characteristics of each device, at least the most common
ones. So, for USB_DEVICE_FINGERPRINT_READER, we could have:

#define FINGEPRINT_IMAGE_JPG 0
#define FINGEPRINT_IMAGE_PNM 1
#define FINGEPRINT_IMAGE_BMP 2
#define FINGEPRINT_IMAGE_RAW 3

struct usb_devcap_fingerprint_reader {
	unsigned int width;
	unsigned int height;
	unsigned int colors;
	unsigned char cap_encrypted_output;
	unsigned char image_type; /* FINGEPRINT_IMAGE_PNM */
};

(I know, this sucks, but you got the idea).

So our usb_device_id array could also include the kind of device and a
pointer to our structure describing the device capabilities, something
like:

static struct usb_devcap_fingerprint_reader
usb_devcap_fingerprint_reader_mskeyboard = {
	.width = 100,
	.height = 100,
	.colors = 2,
	.cap_encrypted_output = 0,
	.image_type = FINGEPRINT_IMAGE_BMP,
}

static struct usb_device_id dpfp_table[] = {
	{
		/* Microsoft Keyboard with Fingerprint reader */
		USB_DEVICE(0x045e, 0x00bb),
		.driver_info = DPFP_TYPE_URU4000B,
		USB_DEVICE_FINGERPRINT_READER,
		(usb_devcap_fingerprint_reader *) usb_devcap_fingerprint_reader_mskeyboard,
	},
	{}	/* terminating null entry */
};

So, to know each fingerprint reader device (if any) and its
capabilities, we could have a directory like /dev/usb/fingerprint
where we could iterate and access the device thru
/dev/usb/fingerprint/fingerprint0. Opening a fd to this device and
issuing a ioctl(), we could have a usb_devcap_fingerprint_reader-like
structure on userspace filled in with the device's capabilities, so we
would know exactly what to expect when doing a cat
/dev/usb/fingerprint/fingerprint0 > /tmp/catchme.bmp.

I think that the most difficult part would be summarize the thousands
of different devices and their capabilities in a struct ()... but I
also think that this stuff is needed, and should be kept by the
kernel, and not some lib in userspace...

Daniel



-- 
What this world needs is a good five-dollar plasma weapon.

Re: Driver for Microsoft USB Fingerprint Reader

[Greg KH]

On Mon, Jul 03, 2006 at 07:24:30PM -0400, Daniel Bonekeeper wrote:
> I think that I didn't make myself clear on that... let me try to
> explain on what I'm thinking to do. Let's take as example Dan's driver
> at http://prdownload.berlios.de/dpfp/dpfp-driver-0.1.2.tar.bz2.
> 
> On our usb_device_id, we specify the vendor of the device, etc. We
> could also (I don't know if this is the best place to do that) specify
> which kind of device is it (printer, storage, fingerprint reader, HID,
> etc).

No, why would we want to do that?

> Let's suppose that we have some #define's or a enum that specify
> the hundreds of different device types (is that possible ? :) Nothing
> that a USB_GENERIC can't solve lol).
> 
> enum usb_device_type {
> 	USB_DEVICE_SCANNER,
> 	USB_DEVICE_KEYBOARD,
> 	USB_DEVICE_MOUSE,
> 	USB_DEVICE_FINGERPRINT_READER,
> 	USB_DEVICE_GENERIC,
> 	...
> };

No, please see the USB layer for why we don't need this.

> So our usb_device_id array could also include the kind of device and a
> pointer to our structure describing the device capabilities, something
> like:
> 
> static struct usb_devcap_fingerprint_reader
> usb_devcap_fingerprint_reader_mskeyboard = {
> 	.width = 100,
> 	.height = 100,
> 	.colors = 2,
> 	.cap_encrypted_output = 0,
> 	.image_type = FINGEPRINT_IMAGE_BMP,
> }
> 
> static struct usb_device_id dpfp_table[] = {
> 	{
> 		/* Microsoft Keyboard with Fingerprint reader */
> 		USB_DEVICE(0x045e, 0x00bb),
> 		.driver_info = DPFP_TYPE_URU4000B,
> 		USB_DEVICE_FINGERPRINT_READER,
> 		(usb_devcap_fingerprint_reader *) 
> 		usb_devcap_fingerprint_reader_mskeyboard,
> 	},
> 	{}	/* terminating null entry */
> };

Yes, that's fine to do.

I'll await a real patch before critiquing anything else :)

thanks,

greg k-h

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

Ok, I'll develop this in a cleaner way. But did you get the idea ? Let
me know if you think that this is something worthy to develop so I can
work on it. There are some details that I need to study about the USB
layer to get the whole picture so I can avoid redundant stuff.

I just think that it would be cool to be able to know the capabilities
of each device connected to our system, and who's better to tell us
that than the device drivers? =]
This way we can know, for example, that a webcam can do 30fps at
640x480 and the output type of the video, independently of which
webcam (and driver) we're using...

Daniel

On 7/3/06, Greg KH <greg@kroah.com> wrote:
> On Mon, Jul 03, 2006 at 07:24:30PM -0400, Daniel Bonekeeper wrote:
> > I think that I didn't make myself clear on that... let me try to
> > explain on what I'm thinking to do. Let's take as example Dan's driver
> > at http://prdownload.berlios.de/dpfp/dpfp-driver-0.1.2.tar.bz2.
> >
> > On our usb_device_id, we specify the vendor of the device, etc. We
> > could also (I don't know if this is the best place to do that) specify
> > which kind of device is it (printer, storage, fingerprint reader, HID,
> > etc).
>
> No, why would we want to do that?
>
> > Let's suppose that we have some #define's or a enum that specify
> > the hundreds of different device types (is that possible ? :) Nothing
> > that a USB_GENERIC can't solve lol).
> >
> > enum usb_device_type {
> >       USB_DEVICE_SCANNER,
> >       USB_DEVICE_KEYBOARD,
> >       USB_DEVICE_MOUSE,
> >       USB_DEVICE_FINGERPRINT_READER,
> >       USB_DEVICE_GENERIC,
> >       ...
> > };
>
> No, please see the USB layer for why we don't need this.
>
> > So our usb_device_id array could also include the kind of device and a
> > pointer to our structure describing the device capabilities, something
> > like:
> >
> > static struct usb_devcap_fingerprint_reader
> > usb_devcap_fingerprint_reader_mskeyboard = {
> >       .width = 100,
> >       .height = 100,
> >       .colors = 2,
> >       .cap_encrypted_output = 0,
> >       .image_type = FINGEPRINT_IMAGE_BMP,
> > }
> >
> > static struct usb_device_id dpfp_table[] = {
> >       {
> >               /* Microsoft Keyboard with Fingerprint reader */
> >               USB_DEVICE(0x045e, 0x00bb),
> >               .driver_info = DPFP_TYPE_URU4000B,
> >               USB_DEVICE_FINGERPRINT_READER,
> >               (usb_devcap_fingerprint_reader *)
> >               usb_devcap_fingerprint_reader_mskeyboard,
> >       },
> >       {}      /* terminating null entry */
> > };
>
> Yes, that's fine to do.
>
> I'll await a real patch before critiquing anything else :)
>
> thanks,
>
> greg k-h
>


-- 
What this world needs is a good five-dollar plasma weapon.

Re: Driver for Microsoft USB Fingerprint Reader

[Greg KH]

On Mon, Jul 03, 2006 at 08:04:39PM -0400, Daniel Bonekeeper wrote:
> Ok, I'll develop this in a cleaner way. But did you get the idea ? Let
> me know if you think that this is something worthy to develop so I can
> work on it. There are some details that I need to study about the USB
> layer to get the whole picture so I can avoid redundant stuff.
> 
> I just think that it would be cool to be able to know the capabilities
> of each device connected to our system, and who's better to tell us
> that than the device drivers? =]
> This way we can know, for example, that a webcam can do 30fps at
> 640x480 and the output type of the video, independently of which
> webcam (and driver) we're using...

Take a look at the V4L2 layer :)

thanks,

greg k-h

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Drake]

Daniel Bonekeeper wrote:
> Ok, I'll develop this in a cleaner way. But did you get the idea ? Let
> me know if you think that this is something worthy to develop so I can
> work on it. There are some details that I need to study about the USB
> layer to get the whole picture so I can avoid redundant stuff.
> 
> I just think that it would be cool to be able to know the capabilities
> of each device connected to our system, and who's better to tell us
> that than the device drivers? =]
> This way we can know, for example, that a webcam can do 30fps at
> 640x480 and the output type of the video, independently of which
> webcam (and driver) we're using...

While this may be a good idea in general, it could possible be done in 
userspace (the whole concept is basically linking USB ID's to capability 
sets, so there is no need for this to be in-kernel, right?).

Also, in the less general case of fingerprint readers, most drivers will 
be in userspace. The upek one is, a driver being developed for the 
Authentec AES4000 is, and dpfp will be if the USB stack is now mature 
enough to allow libusb to bind to the fingerprint reader while the 
kernel usbhid driver is bound to the keyboard interface on the same 
device. So, defining some kind of structure for /sys/class/fingerprint 
won't apply to many of the supported devices.

Yes - I agree that there needs to be some common abstraction for 
fingerprint readers. When we have more device support, we should look at 
providing a fingerprint processing library, which supports as many 
devices as possible through a common interface.

Daniel

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

> While this may be a good idea in general, it could possible be done in
> userspace (the whole concept is basically linking USB ID's to capability
> sets, so there is no need for this to be in-kernel, right?).
>

Yes and no... we can have that stuff in userspace, of course, but I
think that we are walking to a big salad here. Imagine this: some
fingerprint devices have userspace drivers while others have
kernel-mode drivers, while the majority of other USB devices (that
could also be implemented in userspace) are in kernel-space. Why care
to keep that stuff in userspace (except for security, since less
non-critical code in userspace == stability+security), while we still
have other devices being managed in kernel mode ?

Another thing is that this "device information layer" should also be
implemented not only for fingerprint devices, but for other USB
devices too... and possibly (very likely) to other devices that are
not USB. If such device-class-specific properties layer is to be
implemented, we should do it to all device classes (not bind to any
specific BUS type).

> Also, in the less general case of fingerprint readers, most drivers will
> be in userspace. The upek one is, a driver being developed for the
> Authentec AES4000 is, and dpfp will be if the USB stack is now mature
> enough to allow libusb to bind to the fingerprint reader while the
> kernel usbhid driver is bound to the keyboard interface on the same
> device. So, defining some kind of structure for /sys/class/fingerprint
> won't apply to many of the supported devices.
>

I think that the kernel should be aware of the properties of the
devices that it handles, otherwise we're walking to some kind of
microkernel architecture, where one day we'll have everything running
on userspace... Well, I'm not aware if there's any sensus regarding
moving device drivers to userspace, but this sounds to me more like a
decision made by fingerprint devices manufactures (as there are lots
of SDKs that comes with userspace drivers, instead of a kernel driver
for their devices). In order to keep a uniform standard, we should
keep this on kernel space. Things like match algorithm
implementations, indeed, should be kept at userspace.

> Yes - I agree that there needs to be some common abstraction for
> fingerprint readers. When we have more device support, we should look at
> providing a fingerprint processing library, which supports as many
> devices as possible through a common interface.

Do you have any idea about how many fingerprint readers have linux
support (i.e., kernel mode drivers, instead of dozens of
per-manufacturer SDKs) ?



Thanks
Daniel

-- 
What this world needs is a good five-dollar plasma weapon.

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Drake]

Daniel Bonekeeper wrote:
> Yes and no... we can have that stuff in userspace, of course, but I
> think that we are walking to a big salad here. Imagine this: some
> fingerprint devices have userspace drivers while others have
> kernel-mode drivers, while the majority of other USB devices (that
> could also be implemented in userspace) are in kernel-space. Why care
> to keep that stuff in userspace (except for security, since less
> non-critical code in userspace == stability+security), while we still
> have other devices being managed in kernel mode ?

You kind of answered your own question before you asked it, but let me 
try and clarify my view. Two things:

1. We generally try and implement things in userspace where possible and 
where it makes sense at least to a certain degree. Or at least, you only 
get USB stuff included in the kernel when you have convinced Greg it 
belongs there (which you may have already done).

2. As you acknowledge, only a certain subset of all USB fingerprint 
reader drivers will be implemented in the kernel, therefore providing 
the abstraction at kernel level is inadequate (you leave the pure 
userspace drivers out of the loop, therefore getting people to actually 
use your interface will be difficult). You may argue that your proposal 
doesn't limit itself to fingerprint readers, but neither does my answer: 
many USB devices (of other types) are supported purely in userspace.

> Another thing is that this "device information layer" should also be
> implemented not only for fingerprint devices, but for other USB
> devices too... and possibly (very likely) to other devices that are
> not USB. If such device-class-specific properties layer is to be
> implemented, we should do it to all device classes (not bind to any
> specific BUS type).

Sounds like you are talking about reimplementing HAL at this point. I 
don't think this argument justifies including it at kernel level (but 
neither does it oppose it).

> I think that the kernel should be aware of the properties of the
> devices that it handles,

If the kernel doesn't *need* to know about the properties and doesn't 
act on them, why? And what about the devices that the kernel doesn't 
handle, where they are operated purely through userspace?

> otherwise we're walking to some kind of
> microkernel architecture, where one day we'll have everything running
> on userspace...

That's not what I'm suggesting - many classes of drivers belong in 
kernel space and would incur major brain damage if moved to userspace.

You might want to go back a year or two and read the discussions when 
the USB scanner driver was moved out of the kernel and reimplemented 
100% inside libsane. There are other examples as well.

> but this sounds to me more like a
> decision made by fingerprint devices manufactures 

It's not their decision while they aren't the ones writing the drivers.

> Do you have any idea about how many fingerprint readers have linux
> support

idmouse is the only fingerprint reader driver in the Linux kernel that I 
know of. There are a number of other devices supported in userspace.

Daniel

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

On 7/5/06, Daniel Drake <dsd@gentoo.org> wrote:
> Daniel Bonekeeper wrote:
> > Yes and no... we can have that stuff in userspace, of course, but I
> > think that we are walking to a big salad here. Imagine this: some
> > fingerprint devices have userspace drivers while others have
> > kernel-mode drivers, while the majority of other USB devices (that
> > could also be implemented in userspace) are in kernel-space. Why care
> > to keep that stuff in userspace (except for security, since less
> > non-critical code in userspace == stability+security), while we still
> > have other devices being managed in kernel mode ?
>
> You kind of answered your own question before you asked it, but let me
> try and clarify my view. Two things:
>
> 1. We generally try and implement things in userspace where possible and
> where it makes sense at least to a certain degree. Or at least, you only
> get USB stuff included in the kernel when you have convinced Greg it
> belongs there (which you may have already done).
>

We actually didn't talk about where we should put fingerprint devices.
I understand that fingerprint devices can perfectly fit in userspace,
and maybe that's the best place to put them.

> 2. As you acknowledge, only a certain subset of all USB fingerprint
> reader drivers will be implemented in the kernel, therefore providing
> the abstraction at kernel level is inadequate (you leave the pure
> userspace drivers out of the loop, therefore getting people to actually
> use your interface will be difficult). You may argue that your proposal
> doesn't limit itself to fingerprint readers, but neither does my answer:
> many USB devices (of other types) are supported purely in userspace.
>

So in this case, instead of having an unique interface to retrieve and
use fingerprint readers on the kernel space, we should have it on
userspace ? Entirely ? This will then bind fingerprint applications to
always use some kind of userspace library or daemon. If we are to have
a centralized system to manage that (which we don't have right now),
and in both situations we're going to need to implement it (either at
kernel level or as some kind of userspace library set and/or a running
daemon that uses it), I think that it will be better to bind future
fingerprint applications to the kernel instead of userspace libraries.
What will happen then if we want to combine fingerprint matching in a
situation where the userspace isn't available ? Let's say, use a
fingerprint validation to mount / (I now that this implies having a
fingerprint match algorithm implemented in kernel, which is out of
scope).

If we are to have all the fingerprint readers interfaces in usermode,
how will this be done ?
Let's take in consideration the number of currently available usermode
drivers for fingerprint readers: if we are to have a centralized
interface to manage all the different types of fingerprint readers, we
need to keep this somewhere (a daemon or library providing an API to
access the devices in an uniform way). In both cases, an effort is
involved in porting the currently available SDKs to this API in order
to get it working. What about the closed-source SDKs ?

My point is: if we're going to implement a centralized interface for
this, and fingerprint applications are to be bound to an API, this API
should be at the kernel, where there are less chances of each vendor
having their own API (as it is now in userspace), and less libraries
or daemons competing between them to be "the default standard for
fingerprint devices" in linux.

> > Another thing is that this "device information layer" should also be
> > implemented not only for fingerprint devices, but for other USB
> > devices too... and possibly (very likely) to other devices that are
> > not USB. If such device-class-specific properties layer is to be
> > implemented, we should do it to all device classes (not bind to any
> > specific BUS type).
>
> Sounds like you are talking about reimplementing HAL at this point. I
> don't think this argument justifies including it at kernel level (but
> neither does it oppose it).
>

I'm currently talking about something much less ambitious... at least
started like that. Just having a way to tell the userspace the
capabilities of our fingerprint reader hardware (image resolution,
image format, etc). In a uniform way (so doesn't matter which reader
do you have, you can have this information). Them came the idea of
putting it on sysfs (since this is already done with sound system,
net, etc). Then came the idea of extending it to all devices and
BUSes, not just USB fingerprint (which got off-topic). If you see my
previous messages about this, the proposed system was just an extra
void structure pointer that would point to a device-class-based
structure holding the properties (even though this was fixed for USB
devices only).


> > I think that the kernel should be aware of the properties of the
> > devices that it handles,
>
> If the kernel doesn't *need* to know about the properties and doesn't
> act on them, why? And what about the devices that the kernel doesn't
> handle, where they are operated purely through userspace?
>

As I said before, the kernel _may_ need to access the device (used
together with cryptography, as an example). It's the only case that I
can actually think of, and may not be enough to move fingerprint
readers entirely to kernel mode...

> > otherwise we're walking to some kind of
> > microkernel architecture, where one day we'll have everything running
> > on userspace...
>
> That's not what I'm suggesting - many classes of drivers belong in
> kernel space and would incur major brain damage if moved to userspace.
>
> You might want to go back a year or two and read the discussions when
> the USB scanner driver was moved out of the kernel and reimplemented
> 100% inside libsane. There are other examples as well.
>

For scanners, I think that it's ok to be entirely in userspace, since
I don't see any use of scanners in kernel mode.

> > but this sounds to me more like a
> > decision made by fingerprint devices manufactures
>
> It's not their decision while they aren't the ones writing the drivers.
>

Actually they are, since I'm referring to the userspace SDK that they
provide, which access the /dev/usb* stuff directly to talk directly
with the fingerprint readers. Are there independent developers
developing userspace drivers for fingerprint readers on linux (i.e.,
aren't tied to any vendor) ?


Thanks
Daniel

-- 
What this world needs is a good five-dollar plasma weapon.

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Drake]

Daniel Bonekeeper wrote:
> So in this case, instead of having an unique interface to retrieve and
> use fingerprint readers on the kernel space, we should have it on
> userspace ?

Yep - why not (we can do it that way, and it is much easier than doing 
it in kernel space).

 > Entirely ?

I guess there may be situations where, if there is a kernel-based 
fingerprint scanning driver, userspace cannot realistically know about 
some of the advanced details that we plan to 'export' for this 
interface. In this case, we'd have to modify the kernel drivers to add 
an interface for this extra information, or just make it add a file to 
sysfs or something like that.

> This will then bind fingerprint applications to
> always use some kind of userspace library or daemon.

Yep. Just like all applications that use scanners use libsane, and there 
are many other examples where the kernel does not provide the full 
solution to a problem.

Not to forget that userspace code is needed to complement any potential 
kernel-side driver anyway - the functionality provided by the 
DigitalPersona and AES4000 scanners (just 2 examples which I know about) 
is so rich that you need an actual userspace library to form the basic 
operations ("scan a finger", etc). Even more so when we figure out how 
to decrypt the images and can enable the image encryption bit. Whether 
in userspace or in kernel, I don't want the driver portion to limit what 
can be done with the devices, since there are so many possibilities.

> If we are to have
> a centralized system to manage that (which we don't have right now),
> and in both situations we're going to need to implement it 

Yep.

> (either at
> kernel level or as some kind of userspace library set and/or a running
> daemon that uses it), I think that it will be better to bind future
> fingerprint applications to the kernel instead of userspace libraries.

While there are viable and workable userspace solutions available, I 
disagree.

> What will happen then if we want to combine fingerprint matching in a
> situation where the userspace isn't available ? Let's say, use a
> fingerprint validation to mount / (I now that this implies having a
> fingerprint match algorithm implemented in kernel, which is out of
> scope).

Do it in an initramfs, just like you would for any other complex 
mounting procedure. I think klibc makes this kind of thing even easier. 
Even if it is out of scope of this discussion, software-based 
fingerprint matching is not practical in kernel space, and I think I can 
safely say that this kind of thing will never be added to the Linux kernel.

> If we are to have all the fingerprint readers interfaces in usermode,
> how will this be done ?

Good question. I haven't thought a great deal about it, as I mentioned 
before my TODO list is:
1. Get dpfp/libdpfp stable
2. Find or write some code which can reliably compare fingerprint 
images, hook dpfp up to that as a prototype
3. Solve the larger problem of finding a way to abstract fingerprint 
reading devices (and fingerprint comparison) into a common API for mass 
adoption.

I'm still on (1), but I'm really glad that people are showing interest 
in (2) and (3).

Anyway, here's a really rough plan for (3): compare a number of 
fingerprint readers, looking at the functionality they offer. Find a way 
to abstract the common functionality into an API which would be used by 
a higher level. Add some API and code to compare fingerprint images, and 
maybe to glue the two together (scanning and matching). Design a modular 
system so that (to a certain extent) support for fingerprint scanning 
devices can be 'plugged in' to provide some of the functionality behind 
the scanning API that has been previously defined.

> Let's take in consideration the number of currently available usermode
> drivers for fingerprint readers: if we are to have a centralized
> interface to manage all the different types of fingerprint readers, we
> need to keep this somewhere (a daemon or library providing an API to
> access the devices in an uniform way).

Yep.

> In both cases, an effort is
> involved in porting the currently available SDKs to this API in order
> to get it working.

Yep, except there aren't really any current SDKs/APIs. As I said before, 
the only driver I know about is idmouse and that doesn't offer any 
recognition capabilities, infact it doesn't even offer finger detection 
(you ask it for an image, and it will take a photo of thin air if there 
is no finger there). I don't know much about the driver or hardware, but 
I think idmouse will need to be reworked before it becomes useful.

So basically we're starting from scratch.

 > What about the closed-source SDKs ?

We (as in kernel development community) don't care about them. They can 
do what they want. They can even adapt our GPL code to better suit their 
needs, but we might not accept their changes into the official codebase.

> My point is: if we're going to implement a centralized interface for
> this, and fingerprint applications are to be bound to an API, this API
> should be at the kernel, where there are less chances of each vendor
> having their own API (as it is now in userspace), and less libraries
> or daemons competing between them to be "the default standard for
> fingerprint devices" in linux.

I'm not clear whether you refer to vendors as Linux vendors (e.g. Red 
Hat, Novell, ...) or fingerprint hardware manufacturers (e.g. Digital 
Persona, Authentec).

If you are talking about Linux vendors, I think they would have no 
problem adopting and contributing to an open-source centralized 
fingerprint handling userspace library, and I don't think there would be 
any problems with multiple libraries doing the same thing in the wild, 
unless ours really sucks.

If you are talking about hardware manufacturers, I'd gladly take any 
input they have if they are interested in helping the open source 
development community. I'm sure they have more experience than most of 
we do. I have yet to even get a word of response from Digital Persona 
about my work.

Also, in some ways, competition is good. And doing something at kernel 
level to simply ensure everyone is using the same code and to prevent 
competition is not a strategy that is usually employed.

> I'm currently talking about something much less ambitious... at least
> started like that. Just having a way to tell the userspace the
> capabilities of our fingerprint reader hardware (image resolution,
> image format, etc). In a uniform way (so doesn't matter which reader
> do you have, you can have this information).

Ok. This makes a certain degree of sense, but is making the assumption 
that the kernel actually knows about the fingerprint reader it is 
working with. There aren't enough devices supported to make judgment 
yet, but it appears this will be at least partially false: open-source 
drivers for at least some widely marketed fingerprint readers will be 
implemented purely in userspace.

Either way, I agree with the aim, which is basically to provide a 
generic way for userspace programs to get information about the 
fingerprint reading hardware which they are dealing with.

> Them came the idea of
> putting it on sysfs (since this is already done with sound system,
> net, etc).

Sounds sensible, but only if we are talking about kernel drivers. 
Putting information into syfs about devices which the kernel knows 
almost nothing about is not very realistic, unless you have a masterplan.

> Then came the idea of extending it to all devices and
> BUSes, not just USB fingerprint (which got off-topic).

This is ambitious (just by sheer scope) but is an admirable effort: it 
would rock if more device-specific information is available in sysfs, 
but again, it only makes sense where the kernel itself is powering the 
hardware.

>> > but this sounds to me more like a
>> > decision made by fingerprint devices manufactures
>>
>> It's not their decision while they aren't the ones writing the drivers.
>>
> 
> Actually they are, since I'm referring to the userspace SDK that they
> provide, which access the /dev/usb* stuff directly to talk directly
> with the fingerprint readers.

Are you referring to open source SDKs? If you are, I'd love to hear 
about them. If you aren't, its not something that we really care about. 
They are free to work without the support of the community if they choose.

> Are there independent developers
> developing userspace drivers for fingerprint readers on linux (i.e.,
> aren't tied to any vendor) ?

I don't know.

Anyway, let me make a statement in response to your mails which I'm sure 
will be corrected by Greg or someone else if I'm talking rubbish:

Various USB devices are *not* handled by the kernel. However, these 
devices are usable on Linux/FreeBSD/Windows via userspace libusb-based 
driver code. These drivers will *not* be moved into the Linux kernel 
unless there is a strong reason to do so. This also applies to the 
in-development USB fingerprint reader drivers in userspace: they won't 
be moved into the kernel unless there is a real need to. The ideas you 
have presented so far do not justify that move.

So, if you are designing some kind of information abstraction for all 
USB fingerprint readers, or even all USB devices, or even the spectrum 
of all devices which includes USB, you *cannot* realistically do this at 
kernel level because the kernel has no clue about some of the devices it 
is operating. This is a significant problem with your otherwise 
convincing ideas up to this point, and is something you need to think 
about in other ways than moving things into the kernel.

I hope this makes some sense!

Daniel

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

>
> > If we are to have all the fingerprint readers interfaces in usermode,
> > how will this be done ?
>
> Good question. I haven't thought a great deal about it, as I mentioned
> before my TODO list is:
> 1. Get dpfp/libdpfp stable
> 2. Find or write some code which can reliably compare fingerprint
> images, hook dpfp up to that as a prototype
> 3. Solve the larger problem of finding a way to abstract fingerprint
> reading devices (and fingerprint comparison) into a common API for mass
> adoption.
>
> I'm still on (1), but I'm really glad that people are showing interest
> in (2) and (3).

Do you currently have any page/doc/wiki about the current efforts in
writing an API to handle fingerprint stuff ? (as in (3))

> Anyway, here's a really rough plan for (3): compare a number of
> fingerprint readers, looking at the functionality they offer. Find a way
> to abstract the common functionality into an API which would be used by
> a higher level. Add some API and code to compare fingerprint images, and
> maybe to glue the two together (scanning and matching). Design a modular
> system so that (to a certain extent) support for fingerprint scanning
> devices can be 'plugged in' to provide some of the functionality behind
> the scanning API that has been previously defined.
>

Yeah, that's the idea that I had in mind at first. I/we could start by
taking a look on the current API implementations from the most common
devices to get a whole idea of what's involved (for example some fancy
readers may provide ways to control a LED that indicates the state of
the device, etc, and it may be programmable, others not). We could put
everything in a Wiki separated by devices, and fix a date where we can
start discussing the first API.

> > Let's take in consideration the number of currently available usermode
> > drivers for fingerprint readers: if we are to have a centralized
> > interface to manage all the different types of fingerprint readers, we
> > need to keep this somewhere (a daemon or library providing an API to
> > access the devices in an uniform way).
>
> Yep.
>
> > In both cases, an effort is
> > involved in porting the currently available SDKs to this API in order
> > to get it working.
>
> Yep, except there aren't really any current SDKs/APIs. As I said before,
> the only driver I know about is idmouse and that doesn't offer any
> recognition capabilities, infact it doesn't even offer finger detection
> (you ask it for an image, and it will take a photo of thin air if there
> is no finger there). I don't know much about the driver or hardware, but
> I think idmouse will need to be reworked before it becomes useful.
>
> So basically we're starting from scratch.
>

Sweet =)

Well.. I was thinking about keeping that stuff on kernel more for
conservative reasons (driver == kernel). I really would like the idea
of having something very nice (and under a standard) to have
information about the devices on the system, as sysfs is progressing
to do so. I already explained in earlier e-mails about what I had in
mind, but it can only, of course, run in kernel mode. Mixing userspace
and kernel mode drivers will mess it up anyways. Imagine my wonderful
world: every device and information that you may want to know about
any device on your system is on /sys, and not only "obscure" things
like BUS ID, vendor ID, etc, but userspace-useful info like
resolution, capabilities, etc. A tool like "si" could easily parse
/sys to show everything about your system. And since all drivers (in
kernelspace) are specifically implemented to handle their devices,
they can know _exactly_ their properties, and export them.

In the real world, however, if we want to have information about our
devices, we need to sweat it from a range of ioctl()'s, /dev's and
userspace devices (sometimes direct access to memory, as I think that
the (old?) superprobe used to do). Since sysfs is an effort (between
others) to centralize such informations, why blow it by sparsing
information onto userspace ?

Even though I believe that the place for drivers is in the kernel, I
don't have _practical_ reasons to insist on that (at least for
fingerprint devices), and as I can see that this concept of userspace
vs. kernelspace drivers was already heavily discussed, I won't sweat
to find a reason to get it into the kernel... Just feel that would be
good to have everything under one single place, sounding more like a
standard.

Anyways, how idmouse got into the mainstream kernel, then ?

Daniel

-- 
What this world needs is a good five-dollar plasma weapon.

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Drake]

Daniel Bonekeeper wrote:
> Do you currently have any page/doc/wiki about the current efforts in
> writing an API to handle fingerprint stuff ? (as in (3))

No, but feel free to use the dpfp wiki if you want to start one.

> Anyways, how idmouse got into the mainstream kernel, then ?

You are asking this because its usability is questionable?

Before you start on any of the more advanced code such as unified API 
and fingerprint recognition, you need the basic device support in place. 
The idmouse driver does this.

Greg is particularly keen on including semi-working driver code in the 
Linux kernel even if there is no complete picture, because it really 
raises awareness and development efforts. After all, if idmouse wasn't 
included because it doesn't form a complete fingerprint login system, 
I'd probably have never heard of it and would have no clue about it's 
capabilities.

Daniel

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

Maybe this is not a default on the market and is something that is
coming... but seems that some USB controllers are coming with DMA
capabilities:

http://www.usb.org/developers/presentations/pres0501/Augustin_DMA_Implem_Final.ppt
http://www.semiconductors.philips.com/pip/isp1183.html

Daniel

On 7/3/06, Greg KH <greg@kroah.com> wrote:
> On Mon, Jul 03, 2006 at 06:11:03PM -0400, Daniel Bonekeeper wrote:
> > >> Reading Greg's comment, now I'm in doubt if this should really be in
> > >> kernel mode or at userspace. Since there is no standard (AFAIK) for
> > >> those readers, how should it be done ?
> > >
> > >It all depends on what you want the userspace interface to be.
> > >
> >
> > That's one problem: I don't want to create one more userspace
> > interface for that. I suppose that all the hundreds of fingerprint
> > readers that ships with a SDK have their own way of doing that.. that
> > looks awfull to me, even though I believe that currently there isn't
> > any uniform way of working with fingerprint readers... shouldn't we
> > have a way to classify devices ? For example, if I want to list all
> > the printers connected via USB (supposing that we have more than one),
> > I should be able to request that information from somewhere
> > (/dev/usb/printers/* ?) I suppose that different fingerprint readers
> > works with different resolutions... we should be able to have an
> > unified interface that could tell the userspace the capabilities of
> > each fingerprint device (the area size of the scanner, resolution,
> > etc)... I think that applies for a lot of devices, not just
> > fingerprint readers. Probably there is already something like that.
>
> Yes, we should have one way of identifying them.  I've talked with Dan
> already about this in the past.  Please see his driver for support for a
> few devices already.
>
> > >> For example, I suppose that some (or all) USB devices may have DMA
> > >> capabilities... how is this done ?
> > >
> > >Heh, no, USB can't do DMA at all.  Why would you think they could?  It's
> > >a serial bus that just streams data across it at relativly slow speeds.
> > >
> >
> > Well.. even though I didn't know how and was a bit suspicious, I used
> > to believe that USB devices could do DMA because I heard some time ago
> > about "the danger of USB devices that could do DMA and have total
> > access over the OS"... something on bugtraq or securityfocus...
> > talking about USB and FireWire devices and how they could be used to
> > "inject" stuff on the system's memory and take it over... but I guess
> > it only applies to firewire (even though USB was clearly mentioned).
> > Reviewing it, it definitely applies just for firewire stuff.
> >
> > http://www.csoonline.com/read/050106/ipods.html
>
> Yes, firewire and USB is very different.  You can't dma memory directly
> out using USB, although I've heard rumors that through the USB debug
> port you might be able to do that, but as that requires a custom cable,
> which no one will give me, I can't confirm or deny that yet...
>
> thanks,
>
> greg k-h
>


-- 
What this world needs is a good five-dollar plasma weapon.

Re: Driver for Microsoft USB Fingerprint Reader

[Greg KH]

On Mon, Jul 03, 2006 at 11:56:26PM -0400, Daniel Bonekeeper wrote:
> Maybe this is not a default on the market and is something that is
> coming... but seems that some USB controllers are coming with DMA
> capabilities:
> 
> http://www.usb.org/developers/presentations/pres0501/Augustin_DMA_Implem_Final.ppt
> http://www.semiconductors.philips.com/pip/isp1183.html

I think you are a bit confused.  Of course the USB Host controller
devices support DMA, that's how things are set up and work properly
without using a ton of CPU.  They are usually PCI devices and work quite
well and use DMA.

It's the USB devices themselves that don't and can't do any DMA
themselves.

Hope this helps explain things.

greg k-h

Re: Driver for Microsoft USB Fingerprint Reader

[Alan Cox]

Ar Llu, 2006-07-03 am 18:11 -0400, ysgrifennodd Daniel Bonekeeper:
> That's one problem: I don't want to create one more userspace
> interface for that. I suppose that all the hundreds of fingerprint
> readers that ships with a SDK have their own way of doing that.. that

The very cheap readers all appear to be fairly crude image scanners, and
they even lack hardware encryption/perturbation so they are actually of
very limited value.

> looks awfull to me, even though I believe that currently there isn't
> any uniform way of working with fingerprint readers... shouldn't we
> have a way to classify devices ? For example, if I want to list all

They vary from "low res bitmap" and the rest in software through "low
res bitmap mangled by specific device instance unique scheme" (1)
through to smart card based external tamperproof boxes that authenticate
the smartcard with the fingerprint and the host typically via PAM in
user space.

That's a huge range of devices with little in common.

Alan
(1) Think about what happens if you don't have this. Its possible to
steal a result then reverse engineer a "finger" on your own laptop to
produce the same result.

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

On 7/3/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Ar Llu, 2006-07-03 am 18:11 -0400, ysgrifennodd Daniel Bonekeeper:
> > That's one problem: I don't want to create one more userspace
> > interface for that. I suppose that all the hundreds of fingerprint
> > readers that ships with a SDK have their own way of doing that.. that
>
> The very cheap readers all appear to be fairly crude image scanners, and
> they even lack hardware encryption/perturbation so they are actually of
> very limited value.
>

Noticed that. Well, which device to use is a decision of the user and
the kernel should be able to handle his needs, independently from
being the most secure or not.

> > looks awfull to me, even though I believe that currently there isn't
> > any uniform way of working with fingerprint readers... shouldn't we
> > have a way to classify devices ? For example, if I want to list all
>
> They vary from "low res bitmap" and the rest in software through "low
> res bitmap mangled by specific device instance unique scheme" (1)
> through to smart card based external tamperproof boxes that authenticate
> the smartcard with the fingerprint and the host typically via PAM in
> user space.
>
> That's a huge range of devices with little in common.
>

=(
At least they have something in common: all of them deliver an image
as output. Maybe that could be centralized somehow... for example, a
single structure that we use to ask for the capabilities of a fp
reader and the driver fills it telling the maximum resolution of
image, if it supports encryption or not (or if the datastream that
comes from the driver is encrypted or not), etc. What the userspace
does with the image is irrelevant. Let's imagine that: I have a daemon
in userspace that is responsible for reading fingerprints from
/dev/fingerprint[012], and it is supposed to be device-independent. So
this device asks the device for information about its capabilities,
and the device returns the information as a structure (for example
telling the dimension of the image returned, the image format, etc).

How does encryption-based readers works ? I suppose that a software
driver or library in userspace should be responsible for decrypting
the image and processing it, right ? So, in this case, the decryption
could be done at kernel level (to fit the model above, where just
images are returned), or giving the option for the userspace to
receive the raw encrypted stuff.

> Alan
> (1) Think about what happens if you don't have this. Its possible to
> steal a result then reverse engineer a "finger" on your own laptop to
> produce the same result.
>

At some point, the encrypted image needs to be decrypted for
processing, so it can be stolen anyways, right ?

Re: Driver for Microsoft USB Fingerprint Reader

[Alan Cox]

Ar Llu, 2006-07-03 am 18:49 -0400, ysgrifennodd Daniel Bonekeeper:
> At least they have something in common: all of them deliver an image
> as output. Maybe that could be centralized somehow... for example, a

Not even that.

For those that do we have the video4linux API ("its just a bad webcam")
for the smartcard type devices the interfaces are generally unrelated.

> How does encryption-based readers works ? I suppose that a software
> driver or library in userspace should be responsible for decrypting
> the image and processing it, right ? 

Usually you pick a combination of recognition algorithm and algorithm
that makes the per data unique per chip such that the recognition
algorithm can compare two sets of scrambled data.

Re: Driver for Microsoft USB Fingerprint Reader

[Bill Davidsen]

Alan Cox wrote:
> Ar Llu, 2006-07-03 am 18:11 -0400, ysgrifennodd Daniel Bonekeeper:
>> That's one problem: I don't want to create one more userspace
>> interface for that. I suppose that all the hundreds of fingerprint
>> readers that ships with a SDK have their own way of doing that.. that
> 
> The very cheap readers all appear to be fairly crude image scanners, and
> they even lack hardware encryption/perturbation so they are actually of
> very limited value.

Crude, like beauty, is in the eye of the beholder. I like hardware which 
does as little as possible because I can then apply the appropriate 
software to the data. I can see that if cost is no object and the 
algorithm is never going to change, I can build all that stuff into the 
device. But I don't need to... as long as I can take the data, pass it 
through a transform, and get out of that a key which works or not, then 
I can do useful things with it.

Useful includes many things. I'm playing with using a combined secret 
and SecureID(tm) to decrypt and boot a virtual machine, such that I can 
do many unrelated things and have reduced chance of "unintended data 
migration." It also allows ad-hoc users (read that as undergrads) given 
a temporary machine fairly easily, visiting professors, etc.

I can see the benefits of having the whole package be a black box, I 
hope I have explained why I find even a dumb scanner useful in some cases.

-- 
Bill Davidsen <davidsen@tmr.com>
   Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.

Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Bonekeeper]

    Alan Cox wrote:
    > Ar Llu, 2006-07-03 am 18:11 -0400, ysgrifennodd Daniel Bonekeeper:
    >> That's one problem: I don't want to create one more userspace
    >> interface for that. I suppose that all the hundreds of fingerprint
    >> readers that ships with a SDK have their own way of doing that.. that
    >
    > The very cheap readers all appear to be fairly crude image scanners, and
    > they even lack hardware encryption/perturbation so they are actually of
    > very limited value.



As I said before, usefulness is something relative, and sometimes,
security is not a concern (even when talking about fingerprint
readers).
My intention with this is to try to create a catalog of fingerprint
readers' properties and I think that taking a look at vendors' SDKs
would be a good start.
As pointed out by Greg, it would be also interesting to export those
properties via sysfs instead of structure passing (or in addiction,
not sure yet).
I'm not sure though about relating fingerprint devices with V4L2 (even
the cheapest ones). Some other considerations discussed with Greg are
also:

1) extending those device informations to other classes, not only to
fingerprint readers
2) maybe using another layer to hold device properties based on
classes ( device driver -> device information layer -> sysfs+kobjects
) so we can have specific properties for "fingerprintreader" objects
and easier ways to export them to the sysfs layer, without explicit
declaration on the device driver
3) extend that layer also to non-USB devices ( bus-independent )

Maybe sysfs classes could have a list of default properties (for
example, /sys/class/fingerprint objects could hold a list of commom
fingerprint properties).


    Crude, like beauty, is in the eye of the beholder. I like hardware which
    does as little as possible because I can then apply the appropriate
    software to the data. I can see that if cost is no object and the
    algorithm is never going to change, I can build all that stuff into the
    device. But I don't need to... as long as I can take the data, pass it
    through a transform, and get out of that a key which works or not, then
    I can do useful things with it.

    Useful includes many things. I'm playing with using a combined secret
    and SecureID(tm) to decrypt and boot a virtual machine, such that I can
    do many unrelated things and have reduced chance of "unintended data
    migration." It also allows ad-hoc users (read that as undergrads) given
    a temporary machine fairly easily, visiting professors, etc.

    I can see the benefits of having the whole package be a black box, I
    hope I have explained why I find even a dumb scanner useful in some cases.

    --
    Bill Davidsen < davidsen@tmr.com >


Which fingerprint reader are you using ?

Daniel

PS: sorry about sending that message more than once, I just figured
out that my mails were boucing back to me because Gmail was using HTML
mode for mails =S

-- 
What this world needs is a good five-dollar plasma weapon.

Re: Driver for Microsoft USB Fingerprint Reader

[Alon Bar-Lev]

On 7/3/06, Daniel Bonekeeper <thehazard@gmail.com> wrote:
> Hello everybody.
>
> I would like to develop a driver for any kind of fingerprint reader
> that currently doesn't have a driver for linux, and I'm open for
> suggestions on which device I should use. My first thought was the
> microsoft usb fingerprint reader
> (http://www.geeks.com/details.asp?invtid=DG2-00002-DT&cpc=SCH) because
> it's a new device (and, of course, doesn't have any driver for linux),
> it's cheap, and it's from MS (read "would be fun" =)

Please consider UPEK reader.
It is available on all new Thinkpad laptops, and the vendor 
provides
only binary drivers.

http://www.upek.com/support/dl_linux_bsp.asp

I hate when vendors like ATI, Conexant and UPEK publish 
binary drivers
without publishing the chipset spec... They should decide 
whether
their IP is on the software part or on the hardware part, if 
it is on
the hardware part, they are making money in selling the 
hardware. If
it is on the software part, there is no reason why not 
providing the
information for others to write software to work with the 
primitive
hardware. So in either case there should be full hardware 
interface
disclosure.

Best Regards and Goodluck!
Alon Bar-Lev.

Re: Driver for Microsoft USB Fingerprint Reader

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

On Mon, 03 Jul 2006 14:44:10 +0300, Alon Bar-Lev said:

> I hate when vendors like ATI, Conexant and UPEK publish binary drivers
> without publishing the chipset spec... They should decide whether
> their IP is on the software part or on the hardware part, if it is on
> the hardware part, they are making money in selling the hardware. If
> it is on the software part, there is no reason why not providing the
> information for others to write software to work with the primitive
> hardware. So in either case there should be full hardware interface
> disclosure.

That's all fine and good, if the hardware design is entirely either
stuff designed to open specs (for instance, the actual PCI interface
chips, which *have* to behave a given way for the PCI bus to work) or
your own design.

Things get much more difficult if your hardware design ends up incorporating
somebody else's intellectual property, and they insist on such obfuscation
as part of the licensing terms.  You then have two choices:

1) Refuse to build and sell the board under such onerous requirements.

2) Realize that 95% of the computers that could possibly use your board
are running Windows and don't care about an open-source driver *anyhow*,
accept the fact that you'll not be able to sell to that last 5%, and
build it anyhow...

Only one of these choices generates revenue for your company.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Driver for Microsoft USB Fingerprint Reader

[Alon Bar-Lev]

Valdis.Kletnieks@vt.edu wrote:
> On Mon, 03 Jul 2006 14:44:10 +0300, Alon Bar-Lev said:
> 
>> I hate when vendors like ATI, Conexant and UPEK publish binary drivers
>> without publishing the chipset spec... They should decide whether
>> their IP is on the software part or on the hardware part, if it is on
>> the hardware part, they are making money in selling the hardware. If
>> it is on the software part, there is no reason why not providing the
>> information for others to write software to work with the primitive
>> hardware. So in either case there should be full hardware interface
>> disclosure.
> 
> That's all fine and good, if the hardware design is entirely either
> stuff designed to open specs (for instance, the actual PCI interface
> chips, which *have* to behave a given way for the PCI bus to work) or
> your own design.
> 
> Things get much more difficult if your hardware design ends up incorporating
> somebody else's intellectual property, and they insist on such obfuscation
> as part of the licensing terms.  You then have two choices:
> 
> 1) Refuse to build and sell the board under such onerous requirements.
> 
> 2) Realize that 95% of the computers that could possibly use your board
> are running Windows and don't care about an open-source driver *anyhow*,
> accept the fact that you'll not be able to sell to that last 5%, and
> build it anyhow...
> 
> Only one of these choices generates revenue for your company.

This is not the situation in ATI, Conexant and UPK. They all 
manufacture chips, and they claim that the interface of the 
chip is their IP. I cannot accept this.

Let's take the Conexant case, I bought a computer (Thinkpad) 
with their modem. This means that I've paid for the hardware 
part.

Now this chip should be very primitive, it only allow the 
basic hardware support for software to produce the necessary 
waves.

They supply drivers for Windows for free, but they have sold 
the chip interface to 3rd party that sells!!! drivers for Linux.

They admit that they need no more money for the sale, but 
they don't publish the chip interface to allow others to 
develop appropriate software.

The secret should be on the software... But still they 
continue to limit the usage of the chip people payed money for.

And until now I did not discuss the low quality level of the 
linux binary drivers!

The same goes for ATI and others.

Best Regards,
Alon Bar-Lev.