If you’re here, you’ve probably heard about our lightning talk at the 32nd Chaos Communication Congress demoing Linux on a PS4. This post continues where the talk left off and clarifies a few aspects of what we’re doing, and why.

If you haven’t yet, please watch the talk before reading the rest of this post:

Two years ago, I said that the PS4 was not a particularly interesting device, being a glorified PC. What happened?

Essentially, two things: First, we’re hackers, and hacking consoles is fun after all. Second, it turned out that the PS4 isn’t really a PC (which makes it a more interesting target), while being enough of a PC to have some serious advantages. It’s hard enough to be interesting, and easy enough to be practical.

Let’s recap the (very simplified) history of game console hacks that we have been involved with:

• On the Wii, we basically drove the entire homebrew community, from exploits to libraries to infrastructure. The community ended up being very large and productive, with lots of interesting releases. However, the people interested in game piracy were always riding on the coattails of homebrew since relatively early on, and greatly benefited from it.
• On the PS3, we tried releasing the exploits and letting others sort out the community. The result was that, for all practical purposes, the only users were those interested in piracy. AsbestOS allowed Linux to work again, but since there was no GPU driver, and the CPU was underpowered and annoying to work with, there wasn’t that much interest beyond those who were already running OtherOS.
• On the Wii U, we tried to get the community to display interest and work on Linux support before releasing the exploits. Although there were certainly several interested people, nobody with the right experience stepped up to actually make it a reality. Eventually others released exploits, and quickly a piracy tool has become one of the primary use cases for them.

For the PS4, therefore, we’re yet again trying something new. It seems that the PS4 security architecture is rather straightforward and simple; the OS is based on FreeBSD, and the browser uses WebKit, both of which are open source. It is relatively easy to find exploits in both of them (all things considered), and that is all you need to chain into a Linux loader. However, as we found out, even though the hardware is certainly similar to a PC, it is not a PC, and Linux needs quite a bit of extra work to get running. Thus, we can add more value to the homebrew ecosystem by helping port Linux than by releasing exploits.

Of course, this also absolves us from responsibility for potentially enabling piracy (and online play hacking and other undesirable outcomes), but we think it might even have a net positive effect: if we can get people interested in running Linux on the PS4 over using the native OS, we can redirect efforts away from reverse engineering the original software infrastructure (which is what the piracy guys need, and they inevitably leech off of those efforts) to Linux (which is completely useless for piracy).

Linux on the PS4 actually makes a lot of sense, more than it ever did on any previous game console. It’s close enough to a PC that getting 3D acceleration working, while rather painful (as we’ve learned), seems entirely possible without undue amounts of effort (in a timeframe of months, not years), to the level needed for real indie games and even AAA titles, not just homebrew. And many thousands of indie and AAA games already run on Linux. Yes, SteamOS on the PS4 should “just work” once the driver issues are sorted out. We demoed a silly GBA emulator because all we had was a 2D framebuffer, but the real fun is getting 3D games to run just like they do on a PC (we’ve tried some commercial indie games already and they do work fine, just painfully slow as they are using software rendering right now, of course).

Although the exploits used in our demo were our own work (we in fact had Linux booting, albeit in a very broken state, well before any PS4 exploits were publicly announced - porting Linux takes time), the fact that other teams have also been able to get kernel code execution proves the point that you really don’t need to depend on us for that aspect. We also have no doubt that vulnerabilities in the latest firmware can be found without too much trouble. Incidentally, everything is pure software. Hardware stuff was only used for research. There is not much reason to resort to hardware-based exploits on an architecture like the PS4, with a very wide attack surface and mediocre isolation.

So, to the community: if you’re interested, we really think this is the way to go for the PS4. Write an exploit, point it to our loader, and you’ll get Linux (we’ll help you get it hooked up/debugged if needed). And if you want piracy, as usual, go away.

As for release timeframes: right now, the code is in a pretty ugly state, and some components are not releasable (e.g. they contain a bit of code that has been directly reverse engineered from Sony modifications to FreeBSD and needs to be rewritten/cleanroomed). Our goal is to eventually get the patches upstreamed in the Linux kernel, but in the meantime we will open up a work-in-progress repo as soon as is practical. If you’re interested, want to contribute, and have access to a PS4 kernel level exploit, feel free to get in contact with us so we know who wants to help out.

For those curious: the current status of 3D support is that we can get the kernel driver to enable acceleration (with some issues), but command buffer execution is currently broken because GPUVM is not working properly (page flipping works, but nothing is rendered, as the command buffer itself triggers a GPU page fault). We’re actively working on debugging this. If you happen to work on the Radeon DRI driver or are familiar with it, we could use a hand here ;).

TL;DR: We’re working on Linux kernel patches, and are looking to get them upstreamed. We’re not releasing exploits - we’re certain other people will. Don’t ask us. And if you want free games, go away.