linux-kernel - Re: [PATCH] ACPI/Intel: Rework Opregion support

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: <AANLkTiku-9+EJc4yBdTYWLmF5QUsrxAB4ma1vpjFdqFK@mail.gmail.com>
Date:	Wed, 16 Mar 2011 10:11:13 -0400
From:	Jerome Glisse <j.glisse@...il.com>
To:	Indan Zupancic <indan@....nu>
Cc:	Alex Deucher <alexdeucher@...il.com>,
	Alan Cox <alan@...ux.intel.com>,
	intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, Matthew Garrett <mjg@...hat.com>,
	Len Brown <lenb@...nel.org>
Subject: Re: [PATCH] ACPI/Intel: Rework Opregion support

On Wed, Mar 16, 2011 at 2:26 AM, Indan Zupancic <indan@....nu> wrote:
> On Wed, March 16, 2011 03:17, Alex Deucher wrote:
>> It's not HDCP, encrypted bluray is the main issue.  And while
>> there are hacks for bluray around already, contractual obligations
>> don't care whether existing hacks are available or not.
>
> So the contract says to keep it secret, not to make it secure.
> Wonderful.
>
>> Without going into detail, they are very intertwined.  The hw was
>> designed long before we planned to support open source as much as we
>> are now.  Fortunately, we have been working with our hw teams to make
>> future UVD implementations take the open source driver into account.
>
> It has nothing to do with open source, if you need to trust the
> driver you're already screwed from a security point of view.
>
>>>
>>> It would be nice to have an open source Fusion based media player/
>>> IPTV decoder, but I guess that's hoping for too much.
>>>
>>> I understand if AMD/ATI wants to keep its 3D driver secret, but
>>> hardware video decoding?! If you have to keep it secret it means
>>> shortcuts were taken and it's all insecure anyway. That if it gets
>>> broken the Open source driver gets blamed is ridiculous and more
>>> politics than anything else.
>>
>> We don't keep the 3D engine secret.  Most of the code we've written
>> and specs we've released are 3D engine stuff.  Fortunately 3D is less
>> tied up in drm compared to video.
>
> That's not what I said, I was talking about the driver. There are always
> details not documented, and plenty of optimisation tricks that make the
> hardware go fast. Just compare the performance of the Windows driver
> with the open source Linux driver. It doesn't give the impression that
> AMD is putting much effort in the open source drivers or that it takes
> it seriously.

People are over thinking and believe secret recipes is what actually
make driver fast. From my experience i would say that it's just the
open source driver stack that is limiting performances, mostly because
it require a huge amount of work. I believe there is several hundred
of engineers working on the closed driver just to optimize it and
improve it while the open source stacks have couple dozen and not all
working on same hw but working on AMD, Intel, NVidia.

You can check that with some of the test that were in r600 demo, iirc
correctly with direct hw access perf were close to theoretical hw
performance.

Cheers,
Jerome
--
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/