Linux : PS3's downfall?
- Thread starter !eVo!-X Ant UK
- Start date
Panajev2001a
Veteran
darkblu said:
Ok darkblu, one complicated convoluted answer
, but first a simple one: the security risks allowing unsigned homebrew programs running on the PSP are enormous while they are not for PLAYSTATION 3.The PSP did not have the resources to allow another OS to be installed on it (direct program execution from the XMB with unsigned software was a NO-NO): no HDD or huge Solid State media to use. Linux would have also performed like crap on an system with less available RAM (for user applications) and slower RAM as well and a slower main CPU (222 MHz, they would have no enabled 333 MHz, single issue) and another thing... which MIGHT be important... no MMU (so no Virtual Memory). The cost of porting a general Linux distribution to the PSP hardware was not something that would bring them any benefit whatsoever.
All applications running on the PSP are signed and are thus granted low level hardware access: in theory you could use kernel calls to change the CPU speed or do other fun stuff like coding directly for the ME but it would be TRC hell for you AFAIK. Sony was NOT going to distribuite its AES keys to programmers worldwide to allow their code to directly boot from XMB.
PLAYSTATION 3, even with Linux will still not be an OPEN PLATFORM... it would be open if they also gave us access to ALL components including Flash ROM. A PC is an open platform, PlayStation 2 Linux was not an open platform and PLAYSTATION 3 Linux will be even more closed down although I am and still will be challenging the idea that this means that no GCC will be provided for the PPE and the SPU as if we were just programming in BASIC for a generic interpreter running on Linux.
In reality even an answer like the simple statement "we have a BUSINESS interest in opening (to a certain degree) PS3 (and market it as also a kind of home computer) while we have NO BUSINESS interest opening up the PSP" has its merit and you seem to be unwilling to even consider it as a serious answer.
Ultimately the answer could very well be 1.) Because Sony did not want it. 2.)Because Sony wants it
.1.) == no return for them (who cares if some more programmers embrace this limited [in scope and life] platform) and many security risks == angry customers.
2.) == some return for them (the console software industry and SCE need more programmers and artists to learn this complicated architecture and help it to sustain itself... a new hardware paradigm NEEDS support first and foremost) and less-to-none security risk == happy customers.
Do you want a more practical answer ? Because on PS3 you can efficiently isolate two concurrently running OS's from each other thanks to an hypervisor solution that the PSP currently does not support. Because on PSP you cannot block a signed program from bricking the console 32 MB Flash ROM while on PLAYSTATION 3 you side-step the problem as you do not require (you do not need it) any PS3Linux application to be signed.
I did not want to be so aggressive with my previous posts so I'll do my best to keep my replies on a civil and respectful level from now on.
patsu said:
could be. but i don't think they have to actually *open* the platform for development to claim it's a computer. they can just pack-in a desktop enviromnent and be done with that.
yes, but how much of that comes from IBM and how much from sony? sure there is in-depth cell documentation available. from IBM. but how much *sony's, PS3-specific* documentation is there in the open? where are the various ps3 HALs API references? available upon request? or too early for them? maybe. we'll see. it does not seem like an open-platform effort to me ATM. at all. not more than the psp ('hey, there're tons of free public documentatiuon on MIPS, and reverse-eingineered API references so the psp must be an open platfom!')
sorry, but i absolutely cannot see the evidences for that - how is the psp a 'one-shot' platform - it was at its release, and still is, a state of the art hw platform. kind of an over-shoot for a 'one shot' effort, no? more like an attempt for a long-term market penetration, if you ask me. the first step of, that is.
Panajev2001a
Veteran
This particular portion of your argument would work better if PS2 and PSP were based on simple R5k and R4k MIPS CPU's, but both the Emotion Engine's RISC core and the ALLEGREX are not standard MIPS CPU's but customized ones much differently than the CBE processor which will be the same as the one described in the documents both IBM and SCE host on their websites (both give them out to the public). They gave information about specific EE's low level hardware features, ore than enough to help programmers see the differences between the EE and normal MIPS R5K processors. With the PSP they have never once even thought of releasing ANY kind of hardware document to the public on their public web servers. PLAYSTATION 3 is still not intended to be a fully PC like open platform as I said in m previous post.
Also...
You will likely NEVER see them if you mean specific documentation for those portions of PS3 that they will block from people (including low level RSX information and hardware registers) and you will never see any API references, source code and header files describing interfaces/addresses/etc... to allow you to write programs that run directly on PS3OS and that can be launched from the PLAYSTATION 3 XMB GUI.
Knowing Cg, OpenGL ES, PPE and SPE ASM and intrinsics (all available right now for free), common SPE MFC operations and Linux programming as well as some C/C++ coding is all you will need to program for the machine from the Linux OS.
Last edited by a moderator:
darkblu said:
Right it's a start. And the OS that makes most sense for Sony is Linux.
darkblu said:
But IBM's cell forum will not include RSX and other accesssible devices that forms PS3 ? Based on some early interviews, these will only be accessible via the Linux layer (e.g., OpenGL libraries).
Sony has indicated that there will be restrictions in PS3's Linux OS. "Open" so far refers to the ability for a PS3 user to code, install and run Linux applications in PS3's Linux "partition". It does not mean you can program to the metal and run the unsigned app from the PS3OS partition.
darkblu said:
In my original post, I use the word 'one-shot' to mean Sony is not publicly soliciting licensees for PSP (It's for PSP the portable game console only). As for PS3's Cell architecture, Sony has openly invited Toshiba and Apple to hop on board in the early days. It's in the interest of STI to accelerate the adoption of Cell. Ken has mentioned that Sony is happy to get more people to use Cell (The more the merrier) in a few occassions. Building an open source community is a good start in that direction.
Panajev2001a said:
Pana, in order to provide any GL ES sony have to either:
a) provide register-level access in the respective drivers under the linux 'side', or
b) provide known entry points on the ps3os 'userland side' for control over the 'high-priviledges' hw.
it's either (a) or (b). or no GL support from within linux at all. if they do (a) they just as well may release the hw docs. if they do (b) they effectively make public the ps3os control mechanisms exposed to user space (i referred to them as HAL APIs in my original post).
as about psp not having kernel space and user space, i don't know where this myth originated from. psp's kernel can be as protected as any other kernel out there, it's a matter of sw.
Panajev2001a
Veteran
darkblu said:
I think that low level register access of RSX unlocked by reverse-engineering is the last thing that worries them, call again when that means writing into Flash ROM or into the PS3OS HDD partition
. nVIDIA, rather than Sony, seems to be the one most opposed to letting console developers obtain very low level hardware docs and I am sure it took Sony a bit of time and money to convince nVIDIA to hand over what it has so far to officially licensed developers, but I do not think that PS3Linux users will have that luxury.Even if they do b), it still does not mean that you can access those functions directly in your code: like on PSP even if you obtain user-mode access like with the GTA based eLOADER you still are executing unsigned code with NO kernel mode access.
They will likely have their way to provide a high level access to certain devices without making it easy at all to understand how you COULD access those devices and even more difficult to access them in practice: as I said, what they wanted to hide in PlayStation 2 Linux (I/O CPU, DVD-drive mounting of DVD-Video, PS2-Games, CD's, PSOne games, etc... ) they did and with less hardware+software built-in security mechanisms.
I did not say that there is no separation between kernel and user space, I said that on PSP AFAIK signed applications can perform directly kernel mode calls and thus they have access to the 32 MB of Flash ROM and POTENTIALLY they could be designed to destroy/alter its contents bricking the PSP.
IIRC, PSP FW 1.0 essentially did not bother checking for the signature of EBOOT's running from the MS and with 1.50 and 2.00 they eventually found a way to by-pass it (with 2.00 they exploited a bug in an OS component). EBOOT's running on 1.0-1.5-2.0 CAN brick your PSP and Sony did not want to deal with that.
Yes, commercial games could be used to brick PSP's worldwide if they managed to pass TRC somehow, but then the company would be sued by Sony for a LOT of money and erased permanently from its 3rd party list for all Sony consoles.
Evidently on PLAYSTATION 3 they are sure that applications running on top of the Linux OS cannot tamper with the Flash ROM or the PS3OS partition.
Last edited by a moderator:
Panajev2001a
Veteran
Urian said:
?
You should be able to compile Cg shaders or write some of them by hand ideally since PS3GL is an extension to OpenGL ES 1.x (though compatible and certified by Khronos IIRC) and it does not support natively shaders, the idea is to use Cg for that. After looking at the compiled version of those and after reading some programming guides for Shader programs ASM for GeForce 7 GPU's you should be able to get your hands dirty enough if you so wish.
Simple answer?darkblu said:
Because PSP was supposed to be Sony Movies wild card/trojan against those 'other' mobile media devices, while PS3 is supposed to be SCEs trojan against those 'other' personal computer devices.
Not that I'm saying PS3 will be very open - I'm sticking with "wait and see" on that.
Sure but on PS3 it's also a matter of hw.
That's akin to saying "hw manufacturers may as well release the hw docs to public because eventually people will reverse engineer most of the hw access anyway".
Fafalada said:
see, Faf, as much as i agree with you about the psp being sony movies' wild card, i'm not so sure ps3 is so detached from sony movies on its turn (i.e. you saying it being a SCE wild card only) - blu-ray is too much of a hassle to be a clearly-SCE initiative, IMO. moreover, those 'other' personal computer devices may not be ps3's primary adversary, not as much as those 'other' home consoles w/ a media centre, and which, low and behold, are as open as a tin can on a deep reserve. so SCE, on their turn, have zero incentive to make theirs open in response.
ok, an extra layer of protection for the sound sleep of sony movies' suits. that does not mean though the original psp couldn't have been much more sainly protected and homebrew-friendly if desired, no? which they did not bother with out of the abovementiond reasons, etc, etc, goto 10.
yes, in the context of pirating that's exactly akit to the above. in the content of creating legally-clean homebrew for the device, it isn't, by far.
..and then why is it that i can see another psp situation ensuing..
Panajev2001a
Veteran
darkblu said:
darkblu, I can appreciate your recursive argument here
, but I do not think we can agree on it.The original PSP could have been more protected just as much as it could have shipped with a much more powerful GPU or twin R10K or even twin Itanium 2's if desired.
The extra layer of security was not designed just for PLAYSTATION 3 and to run homebrew programs on it, it was a STI goal shared by all members of the alliance and was a priority of the BPA architecture of which the CBE Architecture is its first implementation/definition.
Since the platform is more secure and SCE can afford to install a different OS to have homebrew running safely there (and since SCE can have some returns from it) then SCE can allow homebrew to run without the worry of bricking PLAYSTATION 3's game parition and/or its upgradeable Firmware stored in an appropriate Flash ROM.
Argument reversed
.PSP as we know it already cost SCE a fortune to manufacture back when it launched and the final (a PSP-like device had been in the works for quite a bit) R&D-to-release cycle was already quite tight.
There are several reasons against pushing homebrew programs on the PSP and none towards homebrew as far as Sony was concerned: no interest into establish a new hardware platform to be used outside the PSP, no need to establish a Home Server (PLAYSTATION 3 was supposed to be it), within that time-frame and especially given the budget and the hardware they had in the works to hit launch date dealing with homebrew would have been much more of a liability than an asset to them.
I think, as I said previously, that given hardware limitations a secure separation between homebrews and the PSP OS+XMB was not doable and they would not accept running unsigned executables from the XMB or giving they AES keys out to homebrew programmers.
Panajev2001a
Veteran
darkblu said:
I could agree a bit more with you and share a bit more your conclusion if a lot of other events, which you seem to see as just smoke and mirrors, hadn't happened. When they mention in interviews, multiple times, that they want to provide a toolchain (which costs them relatively very few pennies
), not all support and free-Havok, free-Ageia software, etc... but enough to get you started (just like they did with PlayStation 2 Linux) then I cannot see the PSP situation happening again just like it happened on PSP regarding homebrew.Of course they could be lying, but if we assume that there is much more that would shake the waters than not being able to code any homebrew program for it, if they are lying you must ask yourself "what are they telling the truth about then ?".
Panajev2001a said:
k, Pana, i believe we need to try and define the crux of the problem with psp and homebrew. you say sony couldn't have proved this even if they wanted to. i think that given sony had *any* plans to allow homebrew, they could have provided for a secure (anyway as secure as it is now circa fw2.7) pspos+xbm+homebrew environment at no extra hw cost (i.e. hw sandboxing ala cell, etc).
simple facts for consideration:
* since fw2.01 all user-space code, signed or pegged, got a much tighter isolation from the kernel.
* signed apps have never been able to, and still cannot flash the fw without a validly-signed fw image. in this regards it really does not matter how signed a code is, it's a matter of whether it's able to produce signed fw images or not.
* there's nothing wrong with running unsigned code with a bunch of priviledged APIs disabled - you can cut off access to UMD totally if need be, put other system services (like XMB) in kernel space, and let the party begin. in this case your paltform is as safe as its kernel-mode componets - i.e. unless you have some tiff buffer exploit in your kernel space, you're safe. but if you have such exploits a homebrew-closed system does not give you any safety (see the situation with fw2.0 and homebrew)
see, that's why i think it was entirely a metter of desire on SCE's part. hence the goto 10 : )
[ed: for the record, the original fw2.0 tiff exploit does not provide kernel-space access, but the example still stands]
Last edited by a moderator:
Panajev2001a
Veteran
darkblu said:
Various loader and System options configurators that came out for FW 1.50 and 1.00 seem to prove the opposite: FW 1.00 AFAIK basically forgot to check for the signature and Flash ROM was quite accessible.
Under FW 1.00 they were not exploiting an oveflow in a kernel component and under that FW and under FW 1.50 (before the TIFF overflow bug) Flash RAM was accessible and thus ruinable.
Even the UMD drive was accessible as well as it was possible to run ripped games from Memory Stick.
I think that the separation you suggest is still not how Sony wanted to do things, probably they did not even think homebrew coders would throw themselves at it so quickly and there is also the piracy issue: for quite a long time people could use programs to boot ripped games from MS which showed that they were unprepared for such an occurrence.
You have to remember the time factor, PSP as we now know it had a quite rushed development cycle and that included its OS as well and it was the first time SCE released a console with an upgradeable firmware (let's forget to mention that failure known as Sony Electronics PSX).
There was certainly a lack of desire to allow homebrew, but I will still keep repeating until they come out with a homebrew kit for the PSP (not impossible if they feel that the system is now more secure against exploits... they strangely mention software bootable from Memory Stick as one of the features they will introduce in a future FW revision...
) that the security side of the problem was one of the main factors why they did not push for it.It is better to put a tested and secured software layer between XMB and homebrew programs rather than complicating XMB+PSPOS's design itself more than necessary.
They also saw very LITTLE benefit from homebrew programs and we will keep on insisting that on PLAYSTATION 3 the situation is different.
Even thinkng about the odds what do we have on the table.
Home PlayStation consoles:
1.) PlayStation NetYaroze program (strangely enough code designed for the Yaroze environment could not run on stock PlayStation's
) with included documentation and toolchain.2.) PlayStation 2 Linux program (strangely enough again code dsigned for the PS2Linux environment could not run on stock PlayStation 2's) with included documentation and toolchain.
3.) PLAYSTATION 3... PS3Linux announced in some form, major documentation for CELL and for nVIDIA G7x class GPU's as well as OpenGL ES + Cg documentation and header files already available, CBE chip toolchain already available and PS3Linux specific toolchain and documentation to be delivered with PS3Linux mentioned on record by SCE executives, etc...
PSP:
1.) SCE never distributed any documentation any toolchain. SCE never promised any documentation or any toolchain and delays for a long time the publication of a patch to GNU binutils for the VFPU meanwhile it emphasizes how the platform is locked down and how important is DRM to them meanwhile they are pitching it to movie executives and music executives around the world trying to launch the UMD Video and UMD Audio formats as viable business options for their proprietary and uber locked down device where they were in total control and you should trust them.
The situation of Blu-Ray cannot really be compared to the UMD Video one: a good fit for saying that we would be comparing apples to oranges.
The TIFF exploit still allows too much as being able to indirectly access the Flash ROM and downgrade to 1.50
.
Last edited by a moderator:
Panajev2001a said:
sorry, i should've been clearer - i meant the complete fw flashing-from-an-image process - the ultimate psp take-over. its protection mechanism is quite safe - the most that's been done so far is cheating the current fw into thinking it's of a different version, making that downgrade possible (that still to a valid, official fw).
otherwise, yes, once you get kernel mode access (fw1.0, 1.5) you also have fs read access and some minor write access to the vfs portion of the fw, but that's as far as you get. there's very little there beyond poking into the system registry and say, changing some other font.
the irony being that they could've been prepared had they anticipated the public interest in homebrew. but we can assume pspos was a rush job (not that there're no plenty of evidences in support of that).
There was certainly a lack of desire to allow homebrew, but I will still keep repeating until they come out with a homebrew kit for the PSP (not impossible if they feel that the system is now more secure against exploits... they strangely mention software bootable from Memory Stick as one of the features they will introduce in a future FW revision...
see, i have one issue with that statement. IIRC, it was in the spirit of 'we'd do that given we see enough interest from the customers' ..
WTF!
'see, we sincerely thought there would not be sufficient interest, but if you guys show some in the future we might actually do something about it..'
have they lived in an alternative reality for the past year? the psp is the _most_popular_homebrew_console_ in history, particularly given its age (before anybody says that place belongs to the DC).
how about 'we never planned to and we still don't (but we were cought with our pants down), but as we don't want to burn out bridges we're gonna be vague with some promisses as only we can be.'
for me that statement in its original form was a clear declaration of no warm intentions whatsoever.
they surely saw _some_ benefit from homebrew, having in mind how many spare psp's were bought just so people could use both homebrew and sony's latest software.
yep, i can totally agree to the above. i also would not be suprised if they try to do the same with the ps3, only that this time the device will be truly locked down.
see, Pana, that may actually turn out to be the case (i personally have been in a 'wait and see' mode ever since a sce exec opened their mouth on the subject) but i find it a bit naive that people all around have been raising their expectations of ps3's homebrew abilities, on the background of an (almost) totally wasted state-of-the-art handheld by the same compay.
ps: i realise i may sound somewhat sceptical, if not bitter, but i had been waiting for so damn long for this handheld (anticipating the very technology making it possible) and sony pulled such a 'give us your money and shut up' car salesman move with the psp that i don't think i'll ever have any beyond-the-user-manual expectations for a sony product ever again. which automatically makes most sony products worthless to me.
Last edited by a moderator:
Similar threads
- Locked
