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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Mar 2011 07:26:57 +0100 (CET)
From:	"Indan Zupancic" <indan@....nu>
To:	"Alex Deucher" <alexdeucher@...il.com>
Cc:	"Chris Wilson" <chris@...is-wilson.co.uk>,
	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>,
	"Alan Cox" <alan@...ux.intel.com>
Subject: Re: [PATCH] ACPI/Intel: Rework Opregion support

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.

> It's all about mitigating risk.
> Imagine you run a company and someone asks you this:  "Can we release
> programming info for a part of our chip to support 2-3% of our market
> that may put at risk 90% of our market?"  What would you do?  The
> reason the review is taking so long is that we want to be real sure
> that the risk is safe.

That's what AMD doesn't get, it only has 2-3% because its drivers
aren't great. If AMD had good performing open source drivers they
would not only get a bigger market share, their hardware would also
be used more for embedded kind of things like decoders, media boxes
and who knows what.

The risk you're talking about is how to best hide that the hardware
is totally insecure as far as the drm goes. Well no, you wouldn't
want to make that public indeed. It's probably the crazy drm's that
more or less forced AMD to implement it this way, but still.

>>
>> This is getting more and more off-topic though, sorry for the noise.
>
> Agreed.

Last post from me about this...

Greetings,

Indan

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