linux-kernel - Re: Closed source userspace graphics drivers with an open source kernel component

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <AANLkTikisB-m6ZrpXvToQm1P43S22U0tt9_E-sWETAz4@mail.gmail.com>
Date:	Thu, 15 Jul 2010 20:42:39 -0400
From:	Tim HRM <zt.tmzt@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Piotr Gluszenia Slawinski <curious@...190.internetdsl.tpnet.pl>,
	Dave Airlie <airlied@...hat.com>,
	linux-arm-msm@...r.kernel.org,
	Saravana Kannan <skannan@...eaurora.org>,
	LKML <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: Closed source userspace graphics drivers with an open source 
	kernel component

On Wed, Jul 14, 2010 at 9:24 AM, Pavel Machek <pavel@....cz> wrote:
> Hi!
>
>> >There is no point supporting companies that give you a little bit of
>> >information in exchange they want the support that being in a mainline
>> >kernel gives. Its an unfair exchange of knowledge and time, and if they
>> >claim they have to make a profit then its even more unfair.
>>
>> also, they seem to do it quite wrong way. i.e. much simpler would be
>> to just implement regular, open driver , and implement additional
>> crypto
>> mechanism in chipset itself, allowing to use simple userspace program
>> sending certified keys allowing GPU to operate.
>
> What is going on there? Does msm actually use crypto to prevent you
> from use hardware you bought?
>
> Are the keys device-specific? What prevents me from
> reverse-engineering their binary and publishing them?
>                                                                     Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

Hi Pavel. No I think that was meant to be theoretical/hypothetical.
There's no crypto or device key as such, this hardware is much like
any other that requires firmware to function.

I think the issue is broader than that. The question seems to be
whether an open API/ABI can be specified between an open kernel driver
and a closed userspace driver that is required to perform a subset of
the total functionality, in this case, certain GL and 3D primitives.
The other functions, 2d, the ability to bind a texture to a simple
poly, etc. can be potentially accomplished with an open source driver
and development of a radeonhd or avivo based driver in parallel.  But
that would require developers to agree on an API that can be stablised
and standardized between Android Xorg 2d driver and any potential 3d
driver, where the developers of closed source components must ensure
they remain compatible with whatever direction the open driver takes.

--
Timothy Meade
tmzt #htc-linux
--
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/