Big open news!

[jamesh]

<jamesh> I also get phased over all these comments by people saying 'access to GPU means we can find and fix bugs". I've been working on the GPU code for 4 years, and I've only scratched the surface. There are over 5 million lines of code in the GPU. That's the same order of magnitude as in the whole of the Linux kernel code. Finding and fixing bugs in an arbitrary piece of code on the GPU is NOT easy, requires specialist equipment, compilers and knowledge. People jumping in and saying this really have NO IDEA of the complexity involved.

I should preface by saying I'm satisfied that the route that's been taken so far is probably the best we can do under current constraints. There are other reasons that the GPU code is closed. I have to say, however, that you don't strengthen your case by talking about complexity. Complexity is not a reason to close something.

What would have happened if 4 years ago Broadcom thought "You know what? Jamesh doesn't know anything about the GPU code, we shouldn't let him see it!"? How much would you know about it now?

The simple fact is that you don't know what people are capable of doing unless you let them try. Your mentioning that the Linux kernel is 10m lines is a case in point. People just get involved. Most probably don't do much, and even more probably take a look and think "Forget that!". There's always a core of people that, due to their familiarity, do most of the progress, but that core inevitably can't do everything. And some of those who just take a look end up becoming part of the core. Plus, even if you end up changing nothing, you can still learn an awful lot.

There are coherent (I struggle to refer to them as 'good') reasons for keeping the GPU source closed. Complexity is not one of them.

<Heater> Logically any amount of software can be implemented in hardware given enough gates.

This is what, to me, makes the FSF's position re: Firmware so amusing. They're so myopically focused on 'software' that they literally don't care about hardware which is, at the end of the day, the same thing in a different form. The reasons that software should be open are the same reasons that hardware should be open. The idea that blowing a PROM changes the openness of code is ludicrous.

Note, I wasn't saying that complexity was a reason to keep the GPU code private. I was saying that people who think they can just dive in and fix stuff are mistaken, just like anyone coming to the Linux kernel fresh saying they are going to fix it, would also be in for a nasty shock. In fact, in the GPU's case, the combinations of vector processors, Quad processors, camera ISP and a multitude of HW blocks make the GPU a very difficult thing to get to grips with. Like I said, I've done 4 years, and I know a bit about the camera and ISP...

Now I'm not saying people won't be capable of it after a while. But it's not a "Wow, its open, let's go and fix all those bugs" thing. Also, has anyone using a Raspi ever reported a bug on the GPU?

Note, I was employed to work on the GPU by Broadcom, so its unlikely Broadcom would have said it was too complicated so I shouldn't do it.

[jamesh]

There is one point about the GPU firmware debate where I might side with the moaners and whiners here.

Amazingly they would rather slander the open source announcement as being false or be abusive about it. All the while they make incorrect claims about this only opening up "shims" or "wrappers" around the "real driver", which is technically a false statement, whilst missing the one true objection to the whole set up.

That objection is security.

If I understand correctly the GPU has access to all the memory space of the Pi. Further that the GPU is responsible for booting up Linux or any other OS. Do correct me if I'm wrong.

As such any flaws in that firmware could potentially be used to compromise the whole system. When you upgrade to a new firmware version how do you know it has not been compromised?

Now, you may or may not take that as a serious concern. But dose it invalidate the Open Source claim?

I think not. It's rather like running an instance of Linux under a closed source virtual machine like vmware. Your security is compromised because you don't know what vmware can do to your operating system but that does not suddenly make your OS non Open Source.

This has nothing whatsoever to do with the Arm side libraries being OSS. They are, simply, now OSS. The memory management is irrelevant.

But to answer you question, yes the GPU does have access to memory as a flat address space, according to the memory split at start-up. The Arm is given a chunk of memory which the Arm manages using its MMU. So technically feasible for the GPU to stomp Arm memory, I believe, but not not in any malicious way because it has no knowledge of the MMU, and therefore no knowledge of where stuff might be in memory.

Or at least that's how I understand it. Dom would know more.

[Pickle]

Now I'm not saying people won't be capable of it after a while. But it's not a "Wow, its open, let's go and fix all those bugs" thing. Also, has anyone using a Raspi ever reported a bug on the GPU?

If that's the impression you had from my comments it wasn't what I intended. I only meant the opportunity isnt there if things are closed and support has ended.

[michele.x]

But to answer you question, yes the GPU does have access to memory as a flat address space, according to the memory split at start-up. The Arm is given a chunk of memory which the Arm manages using its MMU. So technically feasible for the GPU to stomp Arm memory, I believe, but not not in any malicious way because it has no knowledge of the MMU, and therefore no knowledge of where stuff might be in memory.

I remember that a long time ago, when, Linux was in version 1, ISA bus was rampant and a 486 with 48 MB of ram was a powerful system, token ring and Ethernet on coaxial cable were battling for the networking structure, the combination of a buggy driver for an expansion card, and a system with more than 16 MB caused random corruption and crashes because the buffer of the board were allocated on the upper physical RAM, the ISA bus was limited to 16 MB addressing and when a DMA write started was in always in the lower physical RAM, without MMU protection.

In a theoretical way if a program could trick another bus master, like the GPU, to write in the wrong physical location, you surely can make the OS to crash...

[Heater]

Tricking the GPU into crashing your machine is one thing. The security implications are somewhat bigger.

In the Raspi the GPU firmware is responsible for booting up Linux. A rogue firmware could potentially alter the kernel image or other files prior to booting Linux. With that capability comes the possibility of an attacker owning your machine.

Sounds like a long shot but I can imagine there is already some keen hackers working on it. Even if they are not we have to trust that Broadcom, or some rogue employee would not do that.

I would imagine that it is this possibility, however remote, that makes security concious systems like some of the BSD's not want to work with the Pi. Perhaps that is also the Free Software Foundations stance. If you cannot review it and build it yourself you cannot trust it.

This is orthogonal to the question of the Openness of the GPU kernel drivers and such, which I do not question.

[Bakul Shah]

Even if you somehow manage to create and piggyback a virus on start.elf, You have to get it to the gpu. That means replacing start.elf on the plugged in flash card. That can happen if you have physical access to the card or can remotely log in to an account with write privileges to /boot. If you have either, all bets are off -- you have bigger things to worry about! And if the bad guy can already exploit a Linux fault, why would he work much much harder and infect start.elf?

On trusting Broadcom: Remember, they built the chip and could have easily embedded whatever backdoor access they wanted! There is *no evidence* of such a thing but if you going to be paranoid, be properly paranoid and don't use the raspi at all! Or any computer for that matter.

I am all for open source but the security argument won't pry open the gpu firmware.

[Max]

Good news.
Means it is now also possible to use the libraries on non-standard Linux distributions (e.g. ones using uclibc instead of glibc as C library)

[Max]

But to answer you question, yes the GPU does have access to memory as a flat address space, according to the memory split at start-up. The Arm is given a chunk of memory which the Arm manages using its MMU. So technically feasible for the GPU to stomp Arm memory, I believe, but not not in any malicious way because it has no knowledge of the MMU, and therefore no knowledge of where stuff might be in memory.

One does not need to know where exactly in memory stuff is, if it is likely that all data you are interested in resides in the same page (4 kb?), and you know a pattern to look for.

E.g. when a user logs into Linux, the login process will read and parse /etc/shadow from disk containing the password hashes of all system users.
The contents of that file is likely to remain in memory for a while afterwards, due to the disk block caching mechanism.
If one knows that the file contains a known entry like "daemon:*:15601:0:99999:7:::", one could instruct the GPU to simply search the entire memory for that string, to get to the other entries before and after that.

[adafruit]

Hey speaking of great jobs, how about that Pi starter kit on your site? Looks like quite the impressive array of stuff to start learning some of the lower level GPIO things with the Pi.

thank you! the adafruit team really appreciates it!

ladyada