?

Log in

PowerVR SGX code leaked. - LIBV Intentionally Breaks Videodrivers [entries|archive|friends|userinfo]
Luc Verhaegen

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

PowerVR SGX code leaked. [Nov. 21st, 2014|11:22 pm]
Luc Verhaegen
[Tags|, , , , , , , , , ]
[Current Location |Rumpelkammer again, finally.]
[mood |Appalled at people, but hopeful.]
[music |Foo Fighters - The colour and the shape - Monkey wrench]

So someone leaked 2011 era PowerVR SGX microcode and user space... And now everyone is pissing themselves like a bunch of overexcited puppies...

I've been fed links from several sides now, and i cannot believe how short-sighted and irresponsible people are, including a few people who should know better.

STOP TELLING PEOPLE TO LOOK AT PROPRIETARY CODE.

Having gotten that out of the way, I am writing this blog to put everyone straight and stop the nonsense, and to calmly explain why this leak is not a good thing.

Before i go any further, IANAL, but i clearly do seem to tread much more carefully on these issues than most. As always, feel free to debunk what i write here in the comments, especially you actual lawyers, especially those lawyers in the .EU.

LIBV and the PVR.

Let me just, once again, state my position towards the PowerVR.

I have worked on the Nokia N9, primarily on the SGX kernel side (which is of course GPLed), but i also touched both the microcode and userspace. So I have seen the code, worked with and i am very much burned on it. Unless IMG itself gives me permission to do so, i am not allowed to contribute to any open source driver for the PowerVR. I personally also include the RGX, and not just SGX, in that list, as i believe that some things do remain the same. The same is true for Rob Clark, who worked with PowerVR when at Texas Instruments.

This is, however, not why i try to keep people from REing the PowerVR.

The reason why i tell people to stay away is because of the design of the PowerVR and its driver stack: PVR is heavily microcode driven, and this microcode is loaded through the kernel from userspace. The microcode communicates directly with the kernel through some shared structs, which change depending on build options. There are sometimes extensive changes to both the microcode, kernel and userspace code depending on the revision of the SGX, customer project and build options, and sometimes the whole stack is affected, from microcode to userspace. This makes the powervr a very unstable platform: change one component, and the whole house of cards comes tumbling down. A nightmare for system integrators, but also bad news for people looking to provide a free driver for this platform. As if the murderous release cycle of mobile hardware wasn't bad enough of a moving target already.

The logic behind me attempting to keep people away from REing the PowerVR is, at one end, the attempt to focus the available decent developers on more rewarding GPUs and to keep people from burning out on something as shaky as the PowerVR. On the other hand, by getting everyone working on the other GPUs, we are slowly forcing the whole market open, singling out Imagination Technologies. At one point, IMG will be forced to either do this work itself, and/or to directly support open sourcing themselves, or to remain the black sheep forever.

None of the above means that I am against an open source driver for PVR, quite the opposite, I just find it more productive to work on the other GPUs amd wait this one out.

Given their bad reputation with system integrators, their shaky driver/microcode design, and the fact that they are in a cut throat competition with ARM, Imagination Technologies actually has the most to gain from an open source driver. It would at least take some of the pain out of that shaky microcode/kernel/userspace combination, and make a lot of peoples lives a lot easier.

This is not open source software.

Just because someone leaked this code, it has not magically become free software.

It is still just as proprietary as before. You cannot use this code in any open source project, or at all, the license on it applies just as strongly as before. If you download it, or distribute it, or whatever other actions forbidden in the license, you are just as accountable as the other parties in the chain.

So for all you kiddies who now think "Great, finally an open driver for PowerVR, let's go hack our way into celebrity", you couldn't be more wrong. At best, you just tainted yourself.

But the repercussion go further than that. The simple fact that this code has been leaked has cast a very dark shadow on any future open source project that might involve the powervr. So be glad that we have been pretty good at dissuading people from wasting their time on powervr, and that this leak didn't end up spoiling many man-years of work.

Why? Well, let's say that there was an advanced and active PowerVR reverse engineering project. Naturally, the contributors would not be able to look at the leaked code. But it goes further than that. Say that you are the project maintainer of such a reverse engineered driver, how do you deal with patches that come in from now on? Are you sure that they are not taken more or less directly from the leaked driver? How do you prove this?

Your fun project just turned from a relatively straightforward REing project to a project where patches absolutely need to be signed-off, and where you need to establish some severe trust into your contributors. That's going to slow you down massively.

But even if you can manage to keep your code clean, the stigma will remain. Even if lawyers do not get involved, you will spend a lot of time preparing yourself for such an eventuality. Not a fun position to be in.

The manpower issue.

I know that any clued and motivated individual can achieve anything. I also know that really clued people, who are dedicated and can work structuredly are extremely rare and that their time is unbelievably valuable.

With the exception of Rob, who is allowed to spend some of his redhat time on the freedreno driver, none of the people working on the open ARM GPU drivers have any support. Working on such a long haul project without support either limits the amount of time available for it, or severely reduces the living standard of the person doing so, or anywhere between those extremes. If you then factor in that there are only a handful of people working on a handful of drivers, you get individuals spending several man-years mostly on their own for themselves.

If you are wondering why ARM GPU drivers are not moving faster, then this is why. There are just a limited few clued individuals who are doing this, and they are on their own, and they have been at it for years by now. Think of that the next time you want to ask "Is it done yet?".

This is why I tried to keep people from REing the powerVR, what little talent and stamina there is can be better put to use on more straightforward GPUs. We have a hard enough time as it is already.

Less work? More work!

If you think that this leaked driver takes away much of the hard work of reverse engineering and makes writing an open source driver easy, you couldn't be more wrong.

This leak means that here is no other option left apart from doing a full clean room. And there need to be very visible and fully transparent processes in place in a case like this. Your one man memory dumper/bit-poker/driver writer just became at least two persons. One of them gets to spend his time ogling bad code (which proprietary code usually ends up being), trying to make sense of it, and then trying to write extensive documentation about it (without being able to test his findings much). The other gets to write code from that documentation, but also little more. Both sides are very much forbidden to go back and forth between those two positions.

As if we ARM GPU driver developers didn't have enough frustration to deal with, and the PVR stack isn't bad enough already, the whole situation just got much much worse.

So for all those who think that now the floodgates are open for PowerVR, don't hold your breath. And to those who now suddenly want to create an open source driver for the powervr, i ask: you and what army?

For all those who are rinsing out their shoes ask yourself how many unsupported man-years you will honestly be able to dedicate to this, and whether there will be enough individuals who can honestly claim the same. Then pick your boring task, and then stick to it. Forever. And hope that the others also stick to their side of this bargain.

LOL, http://goo.gl/kbBEPX

What have we come to?

The leaked source code of a proprietary graphics driver is not something you should be spreading amongst your friends for "Lolz", especially not amongst your open source graphics driver developing friends.

I personally am not too bothered about the actual content of this one, the link names were clear about what it was, and I had seen it before. I was burned before, so i quickly delved in to verify that this was indeed SGX userspace. In some cases, with the links being posted publicly, i then quickly moved on to dissuade people from looking at it, for what limited success that could have had.

But what would i have done if this were Mali code, and the content was not clear from the link name? I got lucky here.

I am horrified about the lack of responsibility of a lot of people. These are not some cat pictures, or some nude celebrities. This is code that forbids people from writing graphics drivers.

But even if you haven't looked at this code yet, most of the damage has been done. A reverse engineered driver for powervr SGX will now probably never happen. Heck, i just got told that someone even went and posted the links to the powerVR REing mailinglist (which luckily has never seen much traffic). I wonder how that went:
Hi,
Are you the guys doing the open source driver for PowerVR SGX?
I have some proprietary code here that could help you speed things along.
Good luck!

So for the person who put this up on github: thank you so much. I hope that you at least didn't use your real name. I cannot imagine that any employer would want to hire anyone who acts this irresponsibly. Your inability to read licenses means that you cannot be trusted with either proprietary code or open source code, as you seem unable to distinguish between them. Well done.

The real culprit is of course LG, for crazily sticking the GPL on this. But because one party "accidentally" sticks a GPL on that doesn't make it GPL, and that doesn't suddenly give you the right to repeat the mistake.

Last months ISA release.

And now for something slightly different...

Just over a month ago, there was the announcement about Imagination Technologies' new SDK. Supposedly, at least according to the phoronix article, Imagination Technologies made the ISA (instruction set architecture) of the RGX available in it.

This was not true.

What was released was the assembly language for the PowerVR shaders, which then needs to be assembled by the IMG RGX assembler to provide the actual shader binaries. This is definitely not the ISA, and I do not know whether it was Alexandru Voica (an Imagination marketing guy who suddenly became active on the phoronix forums, and who i believe to be the originator of this story) or the author of the article on Phoronix who made this error. I do not think that this was bad intent though, just that something got lost in translation.

The release of the assembly language is very nice though. It makes it relatively straightforward to match the assembly to the machine code, and takes away most of the pain of ISA REing.

Despite the botched message, this was a big step forwards for ARM GPU makers; Imagination delivered what its customers need (in this case, the ability to manually tune some shaders), and in the process it also made it easier for potential REers to create an open source driver.

Looking forward.

Between the leak, the assembly release, and the market position Imagination Technologies is in, things are looking up though.

Whereas the leak made a credible open source reverse engineering project horribly impractical and very unlikely, it did remove some of the incentive for IMG to not support an open source project themselves. I doubt that IMG will now try to bullshit us with the inane patent excuse. The (not too credible) potential damage has been done here already now.

With the assembly language release, a lot of the inner workings and the optimization of the RGX shaders was also made public. So there too the barrier has disappeared.

Given the structure of the IMG graphics driver stack, system integrators have a limited level of satisfaction with IMG. I really doubt that this has improved too much since my Nokia days. Going open source now, by actively supporting some clued open source developers and by providing extensive NDA-free documentation, should not pose much of a legal or political challenge anymore, and could massively improve the perception of Imagination Technologies, and their hardware.

So go for it, IMG. No-one else is going to do this for you, and you can only gain from it!
linkReply

Comments:
From: (Anonymous)
2014-11-22 03:01 pm (UTC)
For the code, that data should not be used, except for clean-room.

About the documentation, it should not be safe to use because of the big (C).

(Reply) (Thread)
[User Picture]From: Marius Cirsta
2014-11-22 06:00 pm (UTC)

IMG doesn't seem to care

It seems that Imagination doesn't give a shit, at least for now. I was actually surprised that the code was on github for 5 months now if I read it right. After all their excuses of not providing and open source driver because they risked exposing some well kept secrets this seems very strange indeed.

I think this driver is not completely useless though. People knowledgeable enough may be able to use it to create some custom Android ROMs and maybe even make a Linux PowerVR driver.

Yes distributing this and making modifications and all that might be against the license agreement but I'm sure IMG will not care enough to go after the people doing this. It's just not worth it for them so unless they'll have a good reason to go after anyone everyone is safe.

The only problem that remains here is probably a moral one, just like downloading stuff from piratebay, it's pretty hard to get yourself in any real trouble for doing it but there's a morality issue.
(Reply) (Thread)
[User Picture]From: libv
2014-11-22 07:25 pm (UTC)

Re: IMG doesn't seem to care

Whatever moral issues people have doesn't matter, if people are happy downloading from piratebay they should be just as happy downloading this. But we, open source graphics driver people, simply cannot use the to create free software, unless we use massive indirection and waste much much more time. And we now are forced to either abandon an open source pvr driver completely, or to waste that time.

And then when people do get themselves together to do this, then my question to them is: where have you been all this time, and why have you not used your time to help any of the other ARM GPU drivers? Why did you suddenly decide to work on _this_ project, and why did you before not care about the other projects?
(Reply) (Parent) (Thread)
From: (Anonymous)
2014-11-22 09:29 pm (UTC)

Re: IMG doesn't seem to care

IMG _WONT_ care. And nobody else will either. Throw together some android roms and say fuck corporate.
If no one else will, then i will.
(Reply) (Parent) (Thread)
[User Picture]From: Marius Cirsta
2014-11-22 09:41 pm (UTC)

Re: IMG doesn't seem to care

To be quite honest I care about Mali more than this but even though I'm a programmer I have 2 issues:

1. Time as probably many people do
2. Knowledge, I know nothing about video drivers or any graphics stuff

I assume that if I allocate enough time I can overcome problem nr. 2 eventually.
I also know at least one guy who might have some time and be interested open source drivers development.

The thing is where do you start ? And is there anything you could use some help with regarding Mali ? It would be nice if you could write a post about this.
(Reply) (Parent) (Thread)
[User Picture]From: Irma Suarez
2014-11-25 07:33 pm (UTC)
I understand your concerns about placing the efforts of a handful hackers on a toxic GPU when saner ones are available; and specially, I totally agree that a leakage of proprietary source code should be handled with extreme caution, specially when it affects reverse engineering. We don't want to limit your valuable workspace or even worse, get someone in legal trouble because the authorship of some commits went overlooked. This really is the kind of situation to be paranoid about.

However, I do not share all the interpretations and conclusions you gave.

First, you state that the leakage will probably prevent any possibility of a reverse-engineered FOSS PowerVR driver and that you like the idea of having such a driver; however you also mention time after time how you have (successfully?) discouraged people from working on it. Those claims look a bit incompatible to me.

The fact is that nobody has even started RE-ing PowerVR. There's no repo, no single line of code as far as I know. The mailing list was created in July 2012 and all they had done so far was documenting the series 5 ISA (not to be confused with the newer ISA, sorry I meant assembly, published by ImgTech). Let's be honest, a RE driver would have never been developed at that pace and amount of interest. I don't know whether this leakage will result in a driver being written, but at least it's going to shake things up a bit. I'm not saying that a pristine clean-room approach and meticulous sign-offs are pleasant either. What I'm saying is that this won't be any worse than the the project's situation before the leakage, which basically was being doomed to never take off and starve for a lack of documentation.

I also think there's an underrated reason why working on reverse-engineering PowerVR might be more attractive than working on the rest of the ARM GPUs (not that I'm telling you how to spend your NDA-safe free time): to save TI OMAP, which otherwise is one of the freest ARM platforms I know about. It's a gorgeous shame that TI added PowerVR to OMAP. It is true that PowerVR is awful, but the Beaglebones at least can boot without using proprietary software. Correct me if I'm wrong, but the only full ARM boards that can compete freedom-wise with Beaglebone are the Novena and some Olinuxino's (Allwinner). ARM GPUs are not isolated devices and should be evaluated as part of a bigger silicon.

And while I'm at it, let me thank you for your great work with Lima.
(Reply) (Thread)
[User Picture]From: libv
2014-11-26 09:22 am (UTC)
Those claims are not incompatible when seen in light of me having been working on REing ARM for close to 4 years soon. Especially in light of the amount of noise and fruitless attempts for PowerVR.

But don't to take my word for any of this. You all chose this path, a path i warned against (and you'd think i'd know what i am talking about), and a path which just got much much harder, instead of spending time more usefully. I still see no logical explanation as to why this now suddenly has become an attractive goal, even for people who supposedly have read this blog, while the other GPUs apparently were not sexy enough. In any case, at the end of this all, i will be right here saying "I told you so", like i have done many a time before.

As for OMAP, why bother? Ti chose to leave the mobile business several years ago, to instead focus on automotive. If there is one area where horrible software practices reigns supreme, then it is automotive.
(Reply) (Parent) (Thread)
[User Picture]From: lumag
2014-11-25 08:32 pm (UTC)
Do you know if the same story (lots of different compile-time options) applies to MBX drivers?
(Reply) (Thread)
From: (Anonymous)
2015-03-16 01:01 pm (UTC)

Interesting read

I've been burned recently on Intel GMA 3650 graphics drivers, that's why I'm looking into most sources I can find on PowerVR. Doesn't seem likely that I can use that refurbished netbook as a Linux experimental machine. Intel and PowerVR always said that it's the other party's responsibility. It's terrible for the consumer.

But now I see Nokia N1 will use PowerVR for their graphics again. I really like the product, but I don't really want to support PowerVR.
(Reply) (Thread)