Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fai0verflow: Linux on the PS4 [video]

youtube.com

Post reply on HN
Print view View original

31–40 of 90 posts

Re: Fai0verflow: Linux on the PS4 [video]

#31

Post by SXX »

balls187 wrote: post #27
m00dy wrote: post #3

Actually, I was expecting more technical stuff relating to how they jailbreak the system. PoC is also good though.

(from the video) 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.

They using normal webkit exploit there. Reason why they start it via "userguide.html" it's because in any other case browser on PS4 can only be used when you logged in on PSN.

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.

Re: Fai0verflow: Linux on the PS4 [video]

#32

Post by devbug »

derefr wrote: post #21
jaimehrubiks wrote: post #18

Would it be possible to achieve the opposite in some way?, I mean, dump the kernel and build it on a pc on top of a compatible hardware? Let me know what you think

As consoles get more and more powerful and introduce abstractions between the game developer and the hardware (kernels, syscalls, platform runtime libraries), I've figured it would only be a matter of time before we stop trying to emulate the way that console works, and instead begin to virtualize the console by writing API-compatible wrapper libraries. Presuming developers just treat the PS4 as somewhat like we trea…

So, Xenia.

https://github.com/benvanik/xenia

Re: Fai0verflow: Linux on the PS4 [video]

#33

Post by derefr »

user583495234 wrote: post #26
derefr wrote: post #21

Earlier quoted context omitted.

As consoles get more and more powerful and introduce abstractions between the game developer and the hardware (kernels, syscalls, platform runtime libraries), I've figured it would only be a matter of time before we stop trying to emulate the way that console works, and instead begin to virtualize the console by writing API-compatible wrapper libraries. Presuming developers just treat the PS4 as somewhat like we trea…

You just re-invented high-level emulation. See UltraHLE from 1999.

Sorry, I was going to compare-and-contrast with HLE; forgot. HLE is effectively a JIT, whereas I'm talking about something more like a static recompiler, like jamulator (http://andrewkelley.me/post/jamulator.html).

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.)

Re: Fai0verflow: Linux on the PS4 [video]

#34

Post by anthk »

derefr wrote: post #21
jaimehrubiks wrote: post #18

Would it be possible to achieve the opposite in some way?, I mean, dump the kernel and build it on a pc on top of a compatible hardware? Let me know what you think

As consoles get more and more powerful and introduce abstractions between the game developer and the hardware (kernels, syscalls, platform runtime libraries), I've figured it would only be a matter of time before we stop trying to emulate the way that console works, and instead begin to virtualize the console by writing API-compatible wrapper libraries. Presuming developers just treat the PS4 as somewhat like we trea…

Better like Wine for Linux

Re: Fai0verflow: Linux on the PS4 [video]

#35

Post by anthk »

derefr wrote: post #21
jaimehrubiks wrote: post #18

Would it be possible to achieve the opposite in some way?, I mean, dump the kernel and build it on a pc on top of a compatible hardware? Let me know what you think

As consoles get more and more powerful and introduce abstractions between the game developer and the hardware (kernels, syscalls, platform runtime libraries), I've figured it would only be a matter of time before we stop trying to emulate the way that console works, and instead begin to virtualize the console by writing API-compatible wrapper libraries. Presuming developers just treat the PS4 as somewhat like we trea…

Ahem , there is something similar and which run much faster than the crappy asm.js

https://www.youtube.com/watch?v=bQVI-84Byb0

Also, FreeBSD can run Linux binaries on the same architecture.

Re: Fai0verflow: Linux on the PS4 [video]

#36

Post by derefr »

vvanders wrote: post #25
derefr wrote: post #21

Earlier quoted context omitted.

As consoles get more and more powerful and introduce abstractions between the game developer and the hardware (kernels, syscalls, platform runtime libraries), I've figured it would only be a matter of time before we stop trying to emulate the way that console works, and instead begin to virtualize the console by writing API-compatible wrapper libraries. Presuming developers just treat the PS4 as somewhat like we trea…

Talk to some game devs sometimes, they don't think of it like a PC at all(which is why PC -> console is so hard and not vice versa). I doubt we'll ever see this for titles that extract every ounce of performance out of a platform.

Man, this is the fourth time today that someone's suggested that maybe I should talk to a real game developer about something. I am a game developer. Just not a (modern) console game developer. But I did develop SNES games, way back when!

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.

Re: Fai0verflow: Linux on the PS4 [video]

#37

Post by anthk »

derefr wrote: post #33
user583495234 wrote: post #26

Earlier quoted context omitted.

You just re-invented high-level emulation. See UltraHLE from 1999.

Sorry, I was going to compare-and-contrast with HLE; forgot. HLE is effectively a JIT, whereas I'm talking about something more like a static recompiler, like jamulator ( http://andrewkelley.me/post/jamulator.html ). 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 upscal…

Wine runs the binaries. It's much, much faster than Emscripten.

Re: Fai0verflow: Linux on the PS4 [video]

#38

Post by derefr »

anthk wrote: post #37
derefr wrote: post #33

Earlier quoted context omitted.

Sorry, I was going to compare-and-contrast with HLE; forgot. HLE is effectively a JIT, whereas I'm talking about something more like a static recompiler, like jamulator ( http://andrewkelley.me/post/jamulator.html ). 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 upscal…

Wine runs the binaries. It's much, much faster than Emscripten.

Wine is faster than Emscripten because asm.js is a slow target, not because HLE produces fundamentally better results than transpilation.

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.

Re: Fai0verflow: Linux on the PS4 [video]

#40

Post by Igglyboo »

balls187 wrote: post #27
m00dy wrote: post #3

Actually, I was expecting more technical stuff relating to how they jailbreak the system. PoC is also good though.

(from the video) 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.

Probably a webkit exploit. The Wii U was hacked in a similar way.
Post reply on HN