linux-kernel - Re: Binary Drivers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1167139732.15424.48.camel@Rainsong>
Date:	Tue, 26 Dec 2006 08:28:52 -0500
From:	James C Georgas <jgeorgas@...ers.com>
To:	knobi@...bisoft.de
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Binary Drivers

On Tue, 2006-26-12 at 03:20 -0800, Martin Knoblauch wrote:
> On 12/25/06, David Schwartz <davids@...xxxxxxxxxx> wrote:
> 
> >   If I bought the car from the manufacturer, it also must
> > include any rights the manufacturer might have to the car's use.
> > That includes using the car to violate emission control measures.
> > If I didn't buy the right to use the car that way (insofar as
> > that right was owned by the car manufacturer), I didn't
> > buy the whole care -- just *some* of the rights to use it.
> 
>  just to be dense - what makes you think that the car manufacturer has
> any legal right to violate emission control measures? What an utter
> nonsense (sorry).
> 
>  So, lets stop the stupid car comparisons. They are no being funny any
> more.

Let's summarize the current situation:

1) Hardware vendors don't have to tell us how to program their products,
as long as they provide some way to use it (i.e. binary blob driver).

2) Hardware vendors don't want to tell us how to program their products,
because they think this information is their secret sauce (or maybe
their competitor's secret sauce).

3) Hardware vendors don't tell us how to program their products, because
they know about (1) and they believe (2).

4) We need products with datasheets because of our development model.

5) We want products with capabilities that these vendors advertise.

6) Products that satisfy both (4) and (5) are often scarce or
non-existent.

So far, the suggestions I've seen to resolve the above conflict fall
into three categories:

a) Force vendors to provide datasheets. 

b) Entice vendors to provide datasheets.

c) Reverse engineer the hardware and write our own datasheets.

Solution (a) involves denial of point (1), mostly through the use of
analogy and allegory. Alternatively, one can try to change the law
through government channels.

Solution (b) requires market pressure, charity, or visionary management.
We can't exert enough market pressure currently to make much difference.
Charity sometimes gives us datasheets for old hardware. Visionary
management is the future.

Solution (c) is what we do now, with varying degrees of success. A good
example is the R300 support in the radeon DRM module.

Did I miss anything?

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