| 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
| ||
|
Message-ID: <20061226135706.58395.qmail@web32608.mail.mud.yahoo.com> Date: Tue, 26 Dec 2006 05:57:06 -0800 (PST) From: Martin Knoblauch <knobi@...bisoft.de> To: James C Georgas <jgeorgas@...ers.com>, knobi@...bisoft.de Cc: linux-kernel@...r.kernel.org Subject: Re: Binary Drivers --- James C Georgas <jgeorgas@...ers.com> wrote: > 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). > Correct, as far as I can tell. > 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). > - or they are ashamed to show the world what kind of crap they sell - or they have lost (never had) the documentation themselves. I tend to no believe this > 3) Hardware vendors don't tell us how to program their products, > because they know about (1) and they believe (2). > - or they are just ignorant > 4) We need products with datasheets because of our development model. > - correct > 5) We want products with capabilities that these vendors advertise. > we want open-spec products that meet the performance of the high-end closed-spec products > 6) Products that satisfy both (4) and (5) are often scarce or > non-existent. > unfortunatelly > > 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. > good luck > 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. > - Old hardware is not interesting in most markets - Visionary mamangement is rare > Solution (c) is what we do now, with varying degrees of success. A > good example is the R300 support in the radeon DRM module. > But the R300 does not meet 5) Cheers Martin ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de - 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/
Powered by blists - more mailing lists