Does Firmware 2.10 remove access to RSX?

[Oobles]

On a few threads people are discussing if firmware 2.10 removes access to RSX? Can a few people confirm if this is the case? Would be good to know how you confirmed it too?

thanks,
David.

[jimparis]

Access to RSX removed? Heh, no, then you wouldn't see anything on the screen.

What it appears to have blocked is the lv1_gpu_memory_alloc(0) trick (it returns an error now) that unintentially allowed GPU DMA access to the RAMIN which was used to set up new 3D contexts and stuff. There's probably a hypervisor call that does that instead, it just hasn't been found.

I don't think there's any evidence that manipulating the FIFO is a problem; I don't have my PS3 set up to play with that at the moment.

[IronPeter]

RSX is blocked in some sense.

Some official kernels use the same gpu_mem_alloc( 0 ) call. I think, Sony halved linux install base. Nice XMas PR action.

[TheSverre]

Maybe this patch would help

http://www.kernel.org/pub/linux/kernel/ ... 71023.diff

[Panajev2001a]

Just wanted to report my own dmesg crashdump, maybe it can be of some help:

OS: Fedora 7

Kernel: 2.6.24-rc5-g31034440 (patched ps3fb.c and ps3fb.h)

Code: Select all

ps3rsx: PS3 RSX access module, 1.0.0
ps3rsx: reserved XDR memory is @c000000000d00000, len 9437184
ps3rsx: lv1_gpu_memory_allocate failed: -17
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0000000001aece0
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2 PS3
Modules linked in: ps3rsx autofs4 hidp rfcomm l2cap snd_ps3 hci_usb snd_pcm bluetooth usb_storage snd_page_alloc snd_timer snd soundcore sg ehci_hcd ohci_hcd usbcore
NIP: c0000000001aece0 LR: d0000000000001cc CTR: c0000000001aecb8
REGS: c00000000659f840 TRAP: 0300   Not tainted  (2.6.24-rc5-g31034440-dirty)
MSR&#58; 8000000000008032 <EE,IR,DR>  CR&#58; 24000422  XER&#58; 00000000
DAR&#58; 0000000000000000, DSISR&#58; 0000000040000000
TASK = c000000006d39040&#91;2059&#93; 'insmod' THREAD&#58; c00000000659c000 CPU&#58; 0
GPR00&#58; d0000000000001cc c00000000659fac0 c000000000478b78 0000000000000000
GPR04&#58; 0000000000000001 0000000000000001 0000000000000000 0000000000000000
GPR08&#58; c000000001019d20 c000000000496378 c0000000004a18b0 c0000000001aecb8
GPR12&#58; d000000000000d90 c0000000003f0600 d0000000000da3d0 0000000000000000
GPR16&#58; d0000000000da390 0000000000000009 0000000000000061 d000000000001740
GPR20&#58; 0000000000000061 d0000000000d9b54 0000000000000000 d0000000000d8000
GPR24&#58; 000000000000001f 0000000000000001 4000000000000000 0000000000000000
GPR28&#58; d000000000002cf8 c000000006c5b400 c00000000043f750 0000000000000000
NIP &#91;c0000000001aece0&#93; .unregister_framebuffer+0x28/0x108
LR &#91;d0000000000001cc&#93; .cleanup_ps3rsx+0x88/0xc0 &#91;ps3rsx&#93;
Call Trace&#58;
&#91;c00000000659fac0&#93; &#91;0000000000000061&#93; 0x61 &#40;unreliable&#41;
&#91;c00000000659fb60&#93; &#91;d0000000000001cc&#93; .cleanup_ps3rsx+0x88/0xc0 &#91;ps3rsx&#93;
&#91;c00000000659fbe0&#93; &#91;d000000000000ca0&#93; ._ps3rsx_init+0x25c/0x82c &#91;ps3rsx&#93;
&#91;c00000000659fc90&#93; &#91;c000000000076ac0&#93; .sys_init_module+0x16a0/0x1830
&#91;c00000000659fe30&#93; &#91;c0000000000076b4&#93; syscall_exit+0x0/0x40
Instruction dump&#58;
7c0803a6 4e800020 7c0802a6 fbc1fff0 fbe1fff8 fb81ffe0 fba1ffe8 ebc2b098
f8010010 f821ff61 7c7f1b78 e93e8018 <eba30002> 38810070 3860000e 7ba01f24

[anthraxx]

Now, Sony is now officially and actively blocking attemps from the community to get decent 2D/3D grafik performance? Breaking half of the installed linux base? One week before christmas?
Really nice work, Sony, great. How much does a 360' cost again?

[Panajev2001a]

Now, Sony is now officially and actively blocking attemps from the community to get decent 2D/3D grafik performance? Breaking half of the installed linux base? One week before christmas?
Really nice work, Sony, great. How much does a 360' cost again?

Calm down :), going by the fact that this little "change" broke quite a bit of linux installations that were NOT even using these rsx Xorg and kernel modules I'd say that we cannot jump to the conlcusion we would want to jump on.

[anthraxx]

Calm down :), going by the fact that this little "change" broke quite a bit of linux installations that were NOT even using these rsx Xorg and kernel modules I'd say that we cannot jump to the conlcusion we would want to jump on.

Hm. If it's just a little change, which accidently broke the FIFO trick (that's how it is looking like, now), i said nothing.
But if they deliberately broke it, they are looking really hard that the PS3 cant be used for GFX except for themself. This would level Sony from "moderate Evil" to "real Evil".

[codelogic]

The firmware upgrade didn't break my YDL 2.6.16 vanilla kernel. It booted to X fine, with no changes whatsoever.

[Frek]

Calm down :), going by the fact that this little "change" broke quite a bit of linux installations that were NOT even using these rsx Xorg and kernel modules I'd say that we cannot jump to the conlcusion we would want to jump on.

Hm. If it's just a little change, which accidently broke the FIFO trick (that's how it is looking like, now), i said nothing.
But if they deliberately broke it, they are looking really hard that the PS3 cant be used for GFX except for themself. This would level Sony from "moderate Evil" to "real Evil".

Well personally I can't see any reason whatsoever not to provide 3d/2d acceleration- if Sony is afraid people will start buying PS3s just to run linux they might take a look around and notice the lowprice PCs that gives dramatically better linux performance for the bucks.

[stesmi]

One big problem is that Sony said from day one that they would disallow accelerated graphics (read : RSX access) and they haven't said anything to the contrary since then.

So it's no surprise that they do this, for me there was never a question of "if", but of "when".

That some kernels out there used gpu_mem_alloc( 0 ) is really not Sony's fault. Anyone can put any call to anything anywhere if they so wish. And really, using "0" to any memory allocation function is in my eyes never a good idea to begin with, so the kernels that don't work are simply bugged. (No, I'm not counting those that do it on purpose to get RSX access).

That said I am at the same time sad that we can't get RSX access anymore - I have mine still at 2.01 for that exact purpose and I do hope that we either get an official RSX setup call or a new way to enable RSX access again.

[androvsky]

One big problem is that Sony said from day one that they would disallow accelerated graphics (read : RSX access) and they haven't said anything to the contrary since then.

I keep hearing that second-hand, but I've never seen a quote from Sony. The closest I've seen is from a Cell whitepaper by IBM that says that there's no RSX access on purpose, but I'd still like to see something from Sony. I have seen a quote from Phil Harrison that Sony's answer to WiiWare and especially XNA was linux + opengl. I've taken that to mean Cell-accelerated OpenGL, but it still suggests Sony does have some interest in the linux side having some 3D capabilities.

[stesmi]

I'll try to get that quote for you. First hand is a lot better than second hand I agree.

The Sony kernel documentation from 2006-11-10, in "LinuxKernelOverwiew.html", the head states:

Linux Kernel Overview

Copyright © 2006 Sony Computer Entertainment Inc.
Copyright © 2006 Sony Corp.

and below it we see the following :

Graphics/Video

PS3 has a powerful graphic processing unit with high speed host connection. The GPU is connected to both HDMI and AV multi interface. Although the GPU is connected directly to CBE, no direct access by guest OSes to the GPU is allowed currently. Video mode/format setting is also the role of AV setting driver. PS3 Linux fb driver calls AV setting driver to setup video modes.

Currently X server uses virtual frame buffer to render its image. No hardware acceleration is supported under Linux. See the description above section.

Can be downloaded from http://www.powerdeveloper.org/asset/by- ... x-docs-ps3.

I do hope I am allowed to post that, if someone sees that I'm not, please let me know and I'll delete it (or delete it for me please if you're a mod).

[cypherpunks]

That some kernels out there used gpu_mem_alloc( 0 ) is really not Sony's fault. Anyone can put any call to anything anywhere if they so wish. And really, using "0" to any memory allocation function is in my eyes never a good idea to begin with, so the kernels that don't work are simply bugged.

Except that the "gpu_mem_alloc( 0 )" calls* in ps3fb that you are referring to were added by Sony engineers. We wouldn't have even known about this "trick" if it wasn't for the fact that Sony purposefully used it in published, production code, the same code which is now broken by the 2.10 update.

The general approach to using the GPU in OtherOS is to call hypervisor functions which set up the FIFO, screen buffers, and necessary class objects in the gpu configuration space. However this is not what the ps3rsx code does. It uses DMA operations to create the desired gpu configuration directly.

However the code also demonstrates that this ability to DMA anywhere in the GPU, a feature purposefully included by Sony, is also a *huge* security hole. It gives the OtherOS operating system complete control over the entire state of the GPU. Ideally that would not be a problem, but the RSX is a very complex beast that was designed for performance, with LPAR/Hypervisor security as an afterthought. It is entirely likely that there exists hardware bugs, or poorly thought out features which would allow hackers to use the gpu functionality to read/change hypervisor state and gain full access to the entire machine (allowing, among other things, the creation of iso loaders and region bypass filters by pirate hackers). Although it seems obvious now, I do not believe that Sony engineers understood the full implications of allowing DMA access to the entire GPU.

That said, until someone from Sony speaks up, it will never be clear what their intentions truly were with this change. There is no reason to assume that Sony made this change to prevent access to accelerated graphics. But we also have no proof either way, just conjecture.

As IronPeter has said, it is very likely that there exists an undocumented hypervisor call which creates the classes we need for accelerated graphics. We just need to find that (and any help in doing so would be much appreciated).

---

*For the record, it's not a memory allocation. What the call does is set the range of gpu memory that can be DMA'd to. And it is common for such calls to include the semantics that size=0 specifies an infinite range (all memory writable, in this case).

[mc]

stesmi: Note the use of "currently" in both paragraphs, which indicate that this information is subject to change. It does not say "we don't want to support 3D under linux", just "we don't support 3D under linux right now". Of course, it doesn't say that they do want to support it either, but it's not the clear-cut answer that androvsky was looking for. People have been posting their interpretations of these statements as fact (3D must be disallowed under Linux for security reasons, 3D must be disallowed under Linux for licensing reasons, whatever) but AFAIK there has been no clear statement from Sony regarding their roadmap for Linux features.

[stesmi]

stesmi: Note the use of "currently" in both paragraphs, which indicate that this information is subject to change. It does not say "we don't want to support 3D under linux", just "we don't support 3D under linux right now". Of course, it doesn't say that they do want to support it either, but it's not the clear-cut answer that androvsky was looking for. People have been posting their interpretations of these statements as fact (3D must be disallowed under Linux for security reasons, 3D must be disallowed under Linux for licensing reasons, whatever) but AFAIK there has been no clear statement from Sony regarding their roadmap for Linux features.

Yup, I noticed them already before and the way I see it is that the word "currently" is irrelevant. With or without the word "currently" in that sentence, if Sony (ever) choses to open up any part of the RSX and/or accelerated graphics (by any means), then they will - no matter if it says "currently" in that documentation or not. Since it's their hardware and software (hypervisor, etc) they can enable those features at any time they chose. That document the way I see it is a "state of things" document that can be changed at any time by Sony. It is not a promise of anything, and noone would complain if they chose to open up MORE of the hardware to us at any time, but they can do that at their own discretion at any time ..

[stesmi]

That some kernels out there used gpu_mem_alloc( 0 ) is really not Sony's fault. Anyone can put any call to anything anywhere if they so wish. And really, using "0" to any memory allocation function is in my eyes never a good idea to begin with, so the kernels that don't work are simply bugged.

Except that the "gpu_mem_alloc( 0 )" calls* in ps3fb that you are referring to were added by Sony engineers.

It was? Ok, I didn't know that. My bad memory I guess. Do you have a link to a changelog or something where they added it?

We wouldn't have even known about this "trick" if it wasn't for the fact that Sony purposefully used it in published, production code, the same code which is now broken by the 2.10 update.

I donno, attempting stuff like that (enable DMA using "illegal" flags or options (size=0, etc)) is exactly what any hacker would do to see what the hypervisor responds with, for that same reason as there.

The general approach to using the GPU in OtherOS is to call hypervisor functions which set up the FIFO, screen buffers, and necessary class objects in the gpu configuration space. However this is not what the ps3rsx code does. It uses DMA operations to create the desired gpu configuration directly.

However the code also demonstrates that this ability to DMA anywhere in the GPU, a feature purposefully included by Sony, is also a *huge* security hole. It gives the OtherOS operating system complete control over the entire state of the GPU. Ideally that would not be a problem, but the RSX is a very complex beast that was designed for performance, with LPAR/Hypervisor security as an afterthought. It is entirely likely that there exists hardware bugs, or poorly thought out features which would allow hackers to use the gpu functionality to read/change hypervisor state and gain full access to the entire machine (allowing, among other things, the creation of iso loaders and region bypass filters by pirate hackers). Although it seems obvious now, I do not believe that Sony engineers understood the full implications of allowing DMA access to the entire GPU.

Hardware and software bugs always exist. If you write perfect code then you can be sure that some combination of compiler flags will make a bug for you. That's just how it works.

That said, until someone from Sony speaks up, it will never be clear what their intentions truly were with this change. There is no reason to assume that Sony made this change to prevent access to accelerated graphics. But we also have no proof either way, just conjecture.

Well said. I have been wondering the same. There is one thing saying "we don't want you to" but then there's the unspoken "if you get it to work - go ahead, we won't stop you until what you do constitutes a security breach at some level." I wouldn't be surprised if Sony themselves managed to find a way to do something really really naughty using that hole and that's why they plugged it. What leads me in that direction is what they really did. Read the changelog from Geert Uytterhoeven, this is not a direct quote: "must make an allocation of at least 2MiB". Why? Why 2MiB? Why not >0 bytes? The devil is in the details. If they'd wanted to stop the RSX DMA access via size=0 then all they'd need is to add an if (!size) { return(YOU_CAN'T_DO_THAT); } at the top of gpu_mem_alloc().

As IronPeter has said, it is very likely that there exists an undocumented hypervisor call which creates the classes we need for accelerated graphics. We just need to find that (and any help in doing so would be much appreciated).

Yeah, wouldn't surprise me the least. And naturally they could be plugged, changed or removed the second it's apparent they can be used for something for which they were not intended.

*For the record, it's not a memory allocation. What the call does is set the range of gpu memory that can be DMA'd to. And it is common for such calls to include the semantics that size=0 specifies an infinite range (all memory writable, in this case).

Excellent point. Set DMA'able range can equal memory allocation though, a normal malloc() call really does something similar - allocating memory is really just mapping available memory into the address space of a process and setting some flags here and there (MMU, mem tables, etc). But yes, we're talking semantics right now :) I do agree with you though.

[IronPeter]

>it is very likely that there exists an undocumented hypervisor call which creates the classes we need for accelerated graphics.

It is known that games and linux run over the same hypervisor. So we ( probably ) can use all HV functions called by PS3 game SDK. Without restrictions.

[stesmi]

>it is very likely that there exists an undocumented hypervisor call which creates the classes we need for accelerated graphics.

It is known that games and linux run over the same hypervisor. So we ( probably ) can use all HV functions called by PS3 game SDK. Without restrictions.

We might be able to call them but using them? Nah, wouldn't think so.

How easy isn't it to just add a

Code: Select all

if(otheros) { return(YOU_CAN'T_DO_THAT); }

?

So yes, we'll get to that if() but not further.

From my point of view I'm thinking more that there are HV calls that they haven't added that if() in ON PURPOSE so that they MIGHT in the future release the specs of that HV call to us so either we can use it or so that their own opengl or whatever API can use it.

Remember - the HV WILL know if it's running in gameos mode or otheros mode.

[androvsky]

I'll try to get that quote for you. First hand is a lot better than second hand I agree.

The Sony kernel documentation from 2006-11-10, in "LinuxKernelOverwiew.html", the head states:

Linux Kernel Overview

Copyright © 2006 Sony Computer Entertainment Inc.
Copyright © 2006 Sony Corp.

and below it we see the following :

Graphics/Video

PS3 has a powerful graphic processing unit with high speed host connection. The GPU is connected to both HDMI and AV multi interface. Although the GPU is connected directly to CBE, no direct access by guest OSes to the GPU is allowed currently. Video mode/format setting is also the role of AV setting driver. PS3 Linux fb driver calls AV setting driver to setup video modes.

Currently X server uses virtual frame buffer to render its image. No hardware acceleration is supported under Linux. See the description above section.

Can be downloaded from http://www.powerdeveloper.org/asset/by- ... x-docs-ps3.

I do hope I am allowed to post that, if someone sees that I'm not, please let me know and I'll delete it (or delete it for me please if you're a mod).

Thanks for the quote, I've been bugging people that have claimed that for months and you're the first that had real info. :) I find the "currently"'s as interesting as everyone else.

There was a conference in August where Sony was showing off their Cell + RSX blade server, someone at the conference mentioned it was using OpenGL 1.5... odd, nvidia's been at 2.0 for a while, at least for x86. I wonder if they're just waiting on decent linux + PPC opengl drivers. A deal with YDL perhaps?

[audi100quattro]

Is the hypervisor code running on an SPE? Reading some of the CELL docs, they mention a state where one of the SPE's can be made to go into a secure mode, none of it's local stores/registers are accessible except a small part so it can still communicate with the PPE. Since there are are only 6 SPE's accessible in linux, this should be where the hypervisor is running, and Sony could just as easily make two hypervisors, a gameos hv, and otheros hv putting more restrictions on the later.

What I'm unsure about is if each SPE has a "dedicated" bus to the RSX, the docs also show atleast two other buses than the EIB, a 1024bit, and a 12x8bit one, neither of which is for the XDR. IBM says it's for connecting to another CELL and general purpose I/O... any clarification of which buses are used for what in the PS3 would be appreciated. :)

[jhamby]

I find it interesting how quickly some people jumped to the conclusion that Sony is planning to intentionally screw over Linux users by preventing them from accessing some/all of the functionality in order to keep it "exclusive" to Game OS. What purpose would that serve? Sony's revenue stream is based on game sales, so clearly they want to maximize those and minimize game piracy. But Linux hacking is useless to copy protection piracy. It's more than likely that the reason for reserving one of the SPU's and putting it into secure mode is to facilitate full hard drive encryption or at least encryption of the game OS partition (has anyone pulled the HD from their PS3 to check if their Linux partitions are encrypted also?) and for game copy protection. It's completely alright for the purposes of cool Linux hacks (not involving pirating warez) that we never get access to what's on that SPU, and I think everyone understands that.

But Sony is also going to make some profit from sales of the PS3 as they achieve cost reductions in new revisions, as they did for PS2, even if they had to sell it at a loss back in 2006. This is where politics may come into play. Certainly the Playstation division is going to come into competition with the Vaio division as the PS3 is seen as more PC-like. The good news for the Vaio division is that their PC's can run Windows and the PS3 (blessedly) can not, thus ensuring that the two product lines only compete in the Linux PC space, a much smaller (and geekier) demographic. If that geekier demographic decides to buy 25% more PS3's in 2008 (and Sony can sell them at a profit) if Linux supports 3D vs. otherwise, it's a winning situation for them to spend sufficient resources to make this possible (and for the positive PR that will sell more PS3's to non-hobbyists).

The PS3 is much more akin to the late and lamented Commodore Amiga computer, where the sheer amount of intellectual property involved in the custom chips and the ROM's makes the machine itself nearly impossible to counterfeit, due to the technical expertise involved and the unavailability of the custom chips, certainly at anywhere near the prices that Sony pays for them. Whereas the XBox 360, on the other hand, and the Wii both strike me as simpler and more "pirate-able" designs.

What impresses me about the Sony Linux project, and leads me to believe that Sony probably has something up their sleeves in terms of (semi-)official RSX access (whether through an Nvidia developed binary only driver or an Xorg-based open source driver), is the knowledge that Sony has named engineers officially contributing (including Geoff's git kernel repository) under their Sony.com email addresses. This leads me to give them the benefit of the doubt that at the very least they are working to provide some form of lower-level access to the same hardware that the Game OS has access to (minus a small number of copy protection HV calls, perhaps).

I think that people are also confused because "screwing over Linux users and hobbyists" is inarguably (and admittedly) part of Microsoft's business model for the XBox 360 and people are naturally assuming that because both Microsoft and Sony are "big evil company" that they are both big and evil in the same ways. I won't argue as to the relative evilness of either company, but keep in mind that one makes a large portion of its revenues from sales of a certain OS called Windows, and the other company... seemingly can't write a Windows application to save their lives, at least from my experiences with SonicStage, their eBook reader sync program, the crap that came on the old Vaio desktop that I bought some years ago, and so on. When I read the grotesque hackeries involved in getting an XBox to boot Linux (step 4 is literally "Buy King Kong and make an image" since that was the game they found the buffer overflow exploit in), I knew which console I was going to ask Santa for for Christmas! :-)

P.S. I would really like to know what kernel game OS is based on. If it was developed by Sony in Japan, my money is on TRON. My second guess would be NetBSD or perhaps FreeBSD. Certainly it would not be anything tainted in any way by GPL licensed code.

[thecoogs]

Thats a good post J, i think you could be right and Sony are just waiting for the right time to "introduce" the RSX access. It serves no purpose in blocking the acces to the RSX as this will just push hackers to look for major flaws in the security. Has any website pushed for a response from Sony on this issue? I have saw the open letter on the main page but would Sony respond to something like that?

[anthraxx]

Interesting post, jhamby, but you assume sony (as company) thinks and acts as rationally and informed as you.

Some people think hacking is bad, and dont know the difference between hacking some obscure 3rd party os for ps3 trying to enable rsx access, and hacking the ps3 for selling copyrighted games.
Anyway, maybe they are also scared that people start to sell linux live dvds (or even blue ray discs), filled with gigabytes of emulators and gamezz (tux racer? doom? quake [123]?), ready 2 play.

And i dont see Sony as geek-friendly. As gadget-geek-with-money friendly, maybe. I remember aiobo or the sony bmg rootkit desaster...

But maybe someone can proove me wrong? :-)

Edit: If you list Free- and NetBSD, Dont forget OpenBSD. Its probably the most restricting with the licensing of their system, 100% blob free, and secure! :-)

[natron]

And, getting back on topic:

Do we know if 2.10 blocks RSX access?

[ps2devman]

Yep, it does. You upgrade, you're screwed (if you are a true coder).

About previous posts... Sony is ignoring Linux users who lost screen output. No speech. Nada. Bad sign.

[jhamby]

And i dont see Sony as geek-friendly. As gadget-geek-with-money friendly, maybe. I remember aiobo or the sony bmg rootkit desaster...

But maybe someone can proove me wrong? :-)

I don't see "Sony" as a single company but rather a loose coalition of fiefdoms. I agree that most of them are not "geek-friendly", but the PS2 with Linux experiment was apparently successful enough that the Playstation division was willing to continue the experiment for PS3.

Personally, I think that PS3 Linux is at least partly a ploy to increase the penetration of home computers into the Japanese market, as PC sales are beginning to decline there compared to other gadgets like the PS3 and mobile phones, according to a recent AP story. More teenage PC hackers in Japanese homes equals more future Japanese game developers down the road, just like so many Americans of a certain age (I'm 30) got our start into programming by playing with Commodore 64's and other 8-bits as kids. I also base this theory on Gamasutra's recent interview with Akira Yamaoka, where he complains about the lack of young Japanese game developers compared to Americans. If this is even remotely true then crippling the Linux port for game development would be the last thing Sony would want to do to encourage potential future game developers who bought PS3's.

Speaking of independent game developers, wouldn't it make more sense for Sony to allow Linux access to the full capabilities of the hardware and then when someone comes up with a great new indie game, they can swoop in and license it up, exactly like they did with Everyday Shooter, a truly awesome game that was originally written for PC to sell to GameTap, but Sony came along and offered the author a better deal to sell it for PS3 instead.

Yep, it does. You upgrade, you're screwed (if you are a true coder).

About previous posts... Sony is ignoring Linux users who lost screen output. No speech. Nada. Bad sign.

I agree that they're ignoring Linux users and that they broke some stuff in the latest update, but I don't think that this is necessarily a bad sign, but rather the way that tech companies usually operate, because there is so much competition and legal/financial implications that engineers are generally not allowed to speak publically about anything that hasn't been cleared. It's also somewhat in the nature of Linux (at least from my experience) that things tend to change and break in the kernel when the interfaces aren't nailed down fully, or rather that Linux kernel hackers are more willing to break things and cause grief in the short term in a quest to do things the "right away" in the next version.

This reminds me also of what happened when Apple first started selling Intel-based Macs. I bought one of the first Intel iMacs and remember waiting for them to release the source code for Darwin for Intel. There were many rumors that Apple was withholding the Intel Darwin source on purpose, and many speculations similar to what people are supposing for Sony: that Apple couldn't release the Intel kernel code for legal reasons, or they didn't want hobbyists to patch the kernel, or whatever. I asked a friend who worked at Apple and he said he didn't know what was happening because that wasn't his group's decision to make. A few months later, Apple released the source and everyone forgot about the "controversy". They were probably just cleaning up the code and making sure everything was ready before releasing it, and I suspect Sony is similarly waiting for the go-ahead that everything is ready before announcing anything. Keep in mind that December is a bad month for development because so many people take time off for the holidays.

[ldesnogu]

I don't think Sony is all evil. But it's a big company with many dev teams and marketing teams, all with different targets and understanding.
For instance, I am ready to bet that the Sony guys who are working on the PS3 kernel don't even know all what is in a firmware upgrade...

[d-range]

Personally, I think that PS3 Linux is at least partly a ploy to increase the penetration of home computers into the Japanese market, as PC sales are beginning to decline there compared to other gadgets like the PS3 and mobile phones, according to a recent AP story. More teenage PC hackers in Japanese homes equals more future Japanese game developers down the road, just like so many Americans of a certain age (I'm 30) got our start into programming by playing with Commodore 64's and other 8-bits as kids. I also base this theory on Gamasutra's recent interview with Akira Yamaoka, where he complains about the lack of young Japanese game developers compared to Americans. If this is even remotely true then crippling the Linux port for game development would be the last thing Sony would want to do to encourage potential future game developers who bought PS3's.

Speaking of independent game developers, wouldn't it make more sense for Sony to allow Linux access to the full capabilities of the hardware and then when someone comes up with a great new indie game, they can swoop in and license it up, exactly like they did with Everyday Shooter, a truly awesome game that was originally written for PC to sell to GameTap, but Sony came along and offered the author a better deal to sell it for PS3 instead.

I can see Sony maybe putting up something like XNA for PS3 linux in the future, if the PS3 linux homebrew scene starts getting interesting enough for them to us it as a marketing tool. Right now XNA on the 360 doesn't seem very succcessful because the validation and distribution of XNA code by MS is too restrictive, but if MS might open it up more Sony is ready to respond quickly, just like they did with the DivX support. They can always release a binary RSX driver with a signed and encrypted piece of userland code with which you can write real games, provided that you get a key from Sony through some kind of 'developer subscription' service like MS's 'XNA authoring club', or whatever it was called again. For now we'll just have to wait and see I guess, or hope some really smart guy like some of them here finds other ways to get to the RSX.

[aegiswings]

Actually, I think that Sony is blocking access to the RSX mostly because NVIDIA is making them. The RSX is based on NVIDIA's G70 series of chips and it is programmed the same way (3D features accessed through the curie class, etc.). They don't want people to know how their GPUs work which is why they only provide closed-source drivers for Linux. Sure, Sony could provide an OpenGL ES library for use on the PS3, but that's one thing more they'd have to support and it still might contain NVIDIA IP that NVIDIA doesn't want released. To open up the RSX without providing a library would be to invite hackers to reverse engineer NVIDIA's GPUs and that is something they definitely don't want to encourage. NVIDIA is very protective of their IP. Having worked with the source for NVIDIA's drivers before, I feel that what the people in the Rennoveau project what done so far is amazing, but I think they have a long way to go to get something that is really useful.