Fai0verflow: Linux on the PS4 [video]
youtube.com
youtube.com
Is there a future with an open gaming platform like the Steam Machine? Why do developers choose a closed platform like PS4 vs the Steam Machine? What's there to protect that they work so hard to guard it?
Beautiful work here. Keep on hacking.
I don't know if Sony every actually said anything official, but I remember that being part of the reason why the 'Other OS' feature was removed from the PS3 - Places/People were buying them up and running Linux on them because they were such a good deal for the hardware.
I wouldn't want to bet money on my predictions, but I would say that if someone does build a platform like the PS4 that's open and can run Steam, it would cost a lot more for the consumer then the PS4 since it would probably be priced closer to the actual value of the hardware - And that would put off a lot of potential customers.
That said, there's an obvious chicken-and-egg problem in getting people to buy the system, and getting developers to develop for it, but having a cheaper system is definitely an advantage (Obviously, already being well-known to both developers and consumers is probably even more important). Regardless, if they had set the price of the PS4 at $1,000, it probably wouldn't be doing so hot right now.
but I remember that being part of the reason why the
'Other OS' feature was removed from the PS3 -
Places/People were buying them up and running Linux on
them because they were such a good deal for the hardware.
The real danger (for Sony) in opening up their consoles is the risk of piracy. That's a huge attack vector for hackers looking to defeat a console's copy protection scheme(s).
Sony's biggest nightmare is a world where teenagers can easily copy games because, as you say, that's where the real money is.
https://en.wikipedia.org/wiki/PlayStation_3_cluster
http://www.nytimes.com/2014/12/23/science/an-economical-way-...
Being able to easily copy and run games is an entirely fair point, but I felt it was separate from what I (And who I responded to) was getting at. An open-hardware machine running steam still has DRM on the games - And it's a bit of a given that most devs probably wouldn't want their games on platforms that didn't at-least try to have this (Though there are notable exceptions). Having open hardware, and having open software are really two different things, and it's a distinction that's only really come apparent in the later gen systems.
In the past, game systems were fairly close to being basically embedded systems, with the games running on the bare metal, so generally speaking having open-hardware in such a situation makes piracy much easier, because the only protections are in the hardware itself. Current gen systems actually have full OS's and a kernel-mode user-mode split, like a regular PC. Even if the hardware was open, without access to kernel-mode while the OS is running piracy isn't possible. I will concede that opening the hardware possibly creates an attack vector for the kernel though, so from that perspective it really isn't something that they want to have to deal with - And they don't gain anything from allowing it.
That said, if you look at Steam, AFAIK they have no real big issues with piracy. Why that's the case is debatable, but you can obviously make it work without having to lock-down the hardware.
The 3DS actually has a somewhat complicated architecture - My understanding is that it has a dual-core CPU, but one core is dedicated to running the OS kernel, and the other is used for games. Thus, there is also a 'kernel-mode' 'user-mode' split in a way, because the core dedicated to running games doesn't have full access to everything, and doesn't have full access to mess with the other core. You can kinda see this in action when you note that the 3DS can only ever have one game running at a time, but certain home-screen applications can be run while a regular game is suspended - Due to the application running off of the OS kernel's core and not the game's core.
This also means that an exploit in a game doesn't automatically result in full-system control - A separate exploit in the kernel is necessary to gain full control over the system. This is completely different from the Wii's setup as you noted - I'm not sure if the Wii had the OS running while games did or not, but regardless since games ran with full privileges a single exploit in a game resulted in full-system control.
I agree here. Running Yellow Dog Linux [0] on my PS3 was a fun weekend project, but it never came close to replacing my dedicated computer. I didn't even notice the update that removed it, which in hindsight could have been pretty bad had I used it more.
Several reasons, in order of significance:
* Console manufacturers will often subsidize your development for platform exclusivity, in order to attract users. * Large userbase. * Single hardware target. While consoles (intentionally) have no software portability, you are also targeting a single set of hardware so the QA is easier and the dev process requires less testing.
So basically, in reverse order, if you want Steam Machines to win:
* You need APIs that are perfectly portable, so your SDL + Vulkan game can run everywhere without having to manually fix everything. * You need users buying your platform. * You need current manufacturers to lose their profit margins enough to stop buying off exclusivity deals.
Note that with consoles, exclusives attract users which attract exclusives. Its a positive feedback loop that, at least in this console generation when you can build a PC of comparable power to a PS4 / Xbone for the same price, there is no barrier to entry cost on the user besides the preassembly costs, and the fact Steam Machine vendors are selling at profit where Sony / MS care less about margins because they make per-sale revenue in the same way Steam does. But Valve isn't making the consoles, so Alienware needs to keep the lights on exclusively through sales.
That means there is both, A. no incentive for platform exclusivity on Steam Machines, because you aren't getting lockin to your Steam Machine, you would buy exclusivity to the ecosystem and B. no Steam Machine competitive with PS4 / Xbone in price / performance unless you are buying a lot of games to make up the gap between console used prices vs Steam sales.
> Is there a future with an open gaming platform like the Steam Machine?
Yes, but not without Valve biting the bullet to force enough user adoption to get the feedback loop going. They launched it last month without any compelling reason to buy one, and thus sales were underwhelming. And the only way to make them a compelling buy requires Valve to spend money on it - either through subsidizing sales with huge amounts of free games, or directly by making Steam Machines more cost effective up front than current consoles. And then on top of that, you need a critical mass of users to get developers releasing all cross platform releases for it, while also having the games to attract users. Usually, you get that through exclusives, but as I said, nobody has a motivation to release exclusives on SteamOS except Valve, and that would only be if they value adoption of their platform over raw sales figures, and I bet they don't.
"you are also targeting a single set of hardware so the QA is easier and the dev process requires less testing."
Are you serious? You mean to convince me every developer wants to take yet another hipster sdk, one for xbox one, one for ps4, one for xbox 360 and develop for each and every one because it is easiest? Instead of just developing for single linux desktop and reaching linux pc market + consoles and optionally cross compiling to windows from linux too? What kind of crack are you on mate?
Steam machine is better in every way than a gaybox and homostation, everything you get from a pc - free internet, cheap games, same online multiplayer for console or a pc, way beefier hardware than a console, even upgrade options, yet people say that steam machine is lacking something?
A talking point is that closed systems make piracy harder which makes for a more captive group of buyers. Again, just a talking point, we don't have enough comparable data to study.
They are not even subsidizing the hardware anymore, as I understand it, they sell it for about the same it costs to produce.
It looked like they found an exploit via whatever app renders the userguide.html
Curious if they used a proxy to instead load a "malicious" page resulting in a buffer-overflow.
Of course PSN require latest firmware to work while they using device with Firmware 1.76. It's one of Sony measures to force people update firmware.
Awesome job!
The fail0verflow exploit takes it a step further to "kexec" the system into linux where the linux system has direct access to the hardware.
The emulator itself was a great visual demonstration of "the full linux desktop experience" as opposed to listing "Can emulate video games" as a bullet point.
Besides, for a "single application use", speed is not the biggest consideration. USB2 is several times faster than spinning rust
Their name is fail0verflow.
For irony they would need to be named something like FailDeficiency.
Presuming developers just treat the PS4 as somewhat like we treat PCs: a generic processor that can do "math stuff", and some black-box libraries for {threading, graphics, audio, HID support, networking, ...}, then it becomes far easier to statically recompile a PS4 binary into a native PC binary: just recompile the "math stuff" for your target architecture, and then replace the linkages to libraries provided by the PS4 SDK, to libraries provided by your virtualization wrapper.
In other words, basically do the equivalent of what Emscripten does to C programs that expect to use OpenGL: compile the C to asm.js, and compile the calls OpenGL into calls to WebGL.
I doubt we'll ever see this for titles that extract every ounce of performance out of a platform.
My point was not that this might be possible now; but that, as console CPU+GPU power approaches a certain threshold of "good enough; why would we need more?", console makers will eventually decide to spend some of the console's power not on fancier graphics, but on making development easier and more portable by introducing at least one full black-box abstraction layer above the hardware. When this happens, that layer can then be considered the "source ABI" for transpilation.
Now, I haven't played with the XBO or PS4 SDKs, but I have played with the Wii U SDK—and it's exactly what I'm talking about. There's no hardware to think about in the Cafe toolchain—no IO ports to peek and poke, no MSRs to read off. There's just library APIs. It's nearly as abstract as Apple's tvOS SDK.
That's why CEMU is so advanced.
Also, the "libraries" in HLE, that the JITed code calls into, are wrappers built into the emulator software, and therefore can "think in terms of" the source console (see, for example, the texture upscaling in Dolphin)—whereas with transpilation, you have to make direct use of the transpilation-target's platform libraries as-is, with the only extra platform-specific logic existing as shim-code compiled into the transpiled binary at the call-site.
Besides Emscripten, the only other good comparison I can think of is ARC (https://developer.chrome.com/apps/getstarted_arc): a transpiler that takes Android Java bytecode (with Android SDK calls) and spits out PNaCl bytecode (with PPAPI calls.)
Wine has a variant, libwine, that can linked into a Windows binary at compile-time, replacing that Windows binary's linkages to Windows libraries with linkages to Wine. If you have the opportunity, this is always the more processor-efficient way to go (and I'm surprised so many companies choose to "port" their software to Linux using Cider rather than taking their source and compiling in libwine.)
If you didn't have the source of a Windows binary, you could create a Linux transpiler that replaces already-generated Windows symbols with Wine symbols statically while also potentially rewriting the ISA and calling conventions. The only reason one doesn't exist is that the overhead of running a very similar platform via HLE (i.e. one with the same ISA) is negligible. If OSX was still on PPC, for example, running Wine-on-PPC-OSX would work much better via transpilation than via HLE.
Speaking of PowerPC, a better candidate for "transpilation for performance purposes" would have been the PPC apps run under the Rosetta HLE emulator built into OSX. These apps could have been chewed-through once to produce a Carbon-linked x86 binary, that binary cached in the PPC binary's resource fork, and then executed immediately from then on. But Apple themselves had little reason to do this—they didn't want to give anyone an extra incentive to continue using PPC software instead of moving to x86/x64 software.
- Instruction set: JIT (emulators, Rosetta) vs. static recompilation (only niche projects when the source is a machine ISA, but arguably Java AOT compilers, OdinMonkey, etc. count) vs. doing nothing because the source and target have the same ISA (Wine, VM software for the most part).
- APIs: HLE (emulate semantics) vs. LLE (emulate hardware). The more abstract the API, the better the former works, and vice versa. If you are not emulating things like interrupts and register pokes, that is HLE by definition.
In some cases you can /directly/ translate source API usage into target API usage without any shims, but only for relatively simple APIs. For anything complicated, the semantics are likely different enough that transforming calls to it would require complicated global analysis, which would be quite pointless from a performance perspective unless the API is called ridiculously often.
https://www.youtube.com/watch?v=bQVI-84Byb0
Also, FreeBSD can run Linux binaries on the same architecture.
Also video does show privilege escalation that start via webkit exploit, but that doesn't mean that they worked towards breaking of content encryption and / or dumping games.
https://twitter.com/fail0verflow/status/682283793831587840
So maybe the GPU firmware doesn't support the new packet?
So will PS4 users who complain that they can't play Witcher 1 & 2, be able to play them on Linux there?-)
Also since this test Gallium Nine only become better for running things in Wine.
Yeah, but the APU drivers may not be comparable. That's one piece we won't know until we see actual benchmarks with it, if they manage to get 3D acceleration working.
It is playable in Wine, so running Linux on PS4 can enable tons of games both native and Wine compatible (the demo even shows an emulated game which isn't native for Linux either). No idea how good 3D acceleration there will be of course.
That was fixed a while ago. The only bug that I still encounter there is this one: https://devtalk.nvidia.com/default/topic/773623/linux/charac...
Xorg changes not really required because AMD GPUs work just fine on top of modesetting driver.