It seem like these function perfom TILES & ZCULL setup.
First parameters of these functions change from 0 to number of color & depth tiles ( params of lv1_gpu_memory_allocate ).
The hunt for HV's FIFO/Push buffer...
Re: 0x300 & 0x301 entries
I'm mildly surprised no one's replied yet, but that is an interesting find. Lends credence to the theory that the hypervisor doesn't block the RSX at all, with the problem merely being a lack of documentation of the required functions.IronPeter wrote:It seem like these function perfom TILES & ZCULL setup.
First parameters of these functions change from 0 to number of color & depth tiles ( params of lv1_gpu_memory_allocate ).
Which gives me hope that the Yellow Dog Linux for the new Sony Zego might bring an RSX driver to the PS3 also. Okay, not much hope, but a little.
To be totally complete (thx to sandworm who reported it in linux forum -link below), be aware that JimParis contribution to geoff kernel (ps3 ram extended thru gpu ram) has been officially (and silently as usual) shutdown in fw 2.50. Linux users counting on it will once again regret their firmware upgrade... There is really someone silly in command at Sony...ps2devman wrote:I'll try to answer you by gathering what have been done so far :
Thanks to IronPeter, you get control over 70% of the power of a Nv40 GPU (named RSX) on PS3's with firmwares < 2.10 (if you have 2.10 or above you have no GPU under your control, only a 2D space that is sent to screen every frame by Hypervisor itself through your authorized call).
http://wiki.ps2dev.org/ps3:rsx is where are gathered RSX related infos.
http://ps3rsx.googlecode.com/svn/trunk/ is IronPeter's 3D sample
(Control over GPU is useful for 2 things. One is Hardware Accelerated 3D)
http://mandos.homelinux.org/~glaurung/ps3/ is Glaurung's kernel patch
(Other thing is kernel control of 2D bitblits with specific properties.)
IronPeter's last 3D samples are tuned to run with Glaurung's kernel mod.
If you run Linux or OtherOS software (Mc made one) and use Glaurung's method to open RSX to regular kernel control, you obtain 2D hardware acceleration in a compatible enough way so all 2D ports you do will get accelerated. 3D ports is another affair. There is no friendly OpenGL port or similar made to take advantage of IronPeters's discoveries. So you can do accelerated 3D but by programming it at very low level. So no direct 3D ports are possible. Also the lack of TILE and ZCOMP access reduces by 30% the performance and the number of PS3's with firmware<2.10 is probably low on the planet at the moment...
So that's the current situation.
I assume lastest posts you see above in this thread are the lastest attempts to unlock RSX on firmwares >= 2.10 (failed so far).
There are projects in progress for firmwares >= 2.10 involving SPE's to replace a GPU by a set of several SPE's (CPU is named Cell, holding 1 PPE and 6 free to use SPE's). Also, no OpenGL or similar yet for taking advantage of SPE's.
Thus, this thread is still very interesting to survey...
(Note that my own firmwares are <2.10 and I don't plan to upgrade them!)
About performances :
fw>=2.10 : All direct ports will be slow (until SPE based mod works).
fw<2.10 : 2D direct ports will be fast (if you apply Glaurung's mod).
3D direct ports will be slow (won't use RSX unless recoded entirely).
JimParis pushed a mod that should work on all firmwares under Linux.
It's the ability to use 252Mb of gpu-side ram as an extension of the limited 256Mb cpu-side ram. I guess this extra ram is seen as a fast media storage. Still a 2D direct port that needs 500Mb will fail (or be very slow), for example. Needs to rewrite a few to take advantage of the extra 252Mb because, even if 'swapping' is possible (as said in JimParis' ps3nvram driver description, I doubt it will do any good to a piece of software that didn't expect to have only 256Mb of physical ram... So it's better to reduce the amount of memory a software port needs and switch manually at proper -chosen- time).
http://forums.ps2dev.org/viewtopic.php?t=10352
EDIT: False alarm (ps3vram fixed, see below).
Last edited by ps2devman on Fri Nov 07, 2008 1:27 am, edited 1 time in total.
I don't think it's a mistake. Not even a little bit.
Higher Sony ranks decided officialy (between them) to shutdown anything discovered that may make PS3 appear as a good computer (their new policy since when Kutagari got removed). But they never do any announcement, or reply to public explanation requests, to be sure fw updaters get trapped and that new manufactured PS3's don't appear as good computers at all. I won't be estonished if a new model of PS3 do not allow OtherOS stuff at all, in future. I'm pretty sure PS4 won't.
For sure a word is missing for something decided but not announced, so I said official but silent.
Their absolute objective is to follow Nintendo tracks now. Toy for high profit. And screw the devs!
Higher Sony ranks decided officialy (between them) to shutdown anything discovered that may make PS3 appear as a good computer (their new policy since when Kutagari got removed). But they never do any announcement, or reply to public explanation requests, to be sure fw updaters get trapped and that new manufactured PS3's don't appear as good computers at all. I won't be estonished if a new model of PS3 do not allow OtherOS stuff at all, in future. I'm pretty sure PS4 won't.
For sure a word is missing for something decided but not announced, so I said official but silent.
Their absolute objective is to follow Nintendo tracks now. Toy for high profit. And screw the devs!
Odd, then, that Sony employee Geoff Levand would state on IRC then that it was unintentional broken in the FW update.
The last I'd heard, ps3vram was buggy and unsafe anyway. See http://ozlabs.org/pipermail/cbe-oss-dev ... 05513.html
The last I'd heard, ps3vram was buggy and unsafe anyway. See http://ozlabs.org/pipermail/cbe-oss-dev ... 05513.html
But hating on Sony is obviously so much fun... Who cares about facts!jonathan wrote:Odd, then, that Sony employee Geoff Levand would state on IRC then that it was unintentional broken in the FW update.
Let's keep the conspiracy theories (and they are just that, there's no proof for them) off the forums, some people will take them as fact.ps2devman wrote:I don't think it's a mistake. Not even a little bit.
Higher Sony ranks decided officialy (between them) to shutdown anything discovered that may make PS3 appear as a good computer (their new policy since when Kutagari got removed).
Is this the "let's propagate unfounded rumours" thread? Seriously, until something is proven it makes no sense to "speculate" unless you have another agenda. It's the same as the "PSP GO will kill your cat" threads...zaphod wrote:well, i have it on fairly good authority that on the new slim ps3s coming out later this year otheros support is getting removed completely.
I'm 15 years old and want to start hunting. I live near Allentown, Pennsylvania and just wanted some tips.? I need tips on what equipment, any good hunting locations or anything that would help. Thanks!
_____________________
yahoo keyword tool ~ overture ~ traffic estimator ~ adwords traffic estimator
_____________________
yahoo keyword tool ~ overture ~ traffic estimator ~ adwords traffic estimator
Last edited by lenaxin on Sun Jul 26, 2009 4:08 pm, edited 1 time in total.
What relation would this have to the updated PS3VRAM code they're using in the YDL 6.2 release? Do they use any of the operational functions?
Also the few people I've seen that actually have done rational research on the security of the PS3 have all suggested this:
The x360 actually had more security, just a sloppy bloated design. You open up and PS3 and the PCB is a clean design and you can immediately tell how it works in abstract. The x360 had one data mishandle and it flopped the security and revealed other vulnerabilities that where otherwise protected.
EDIT: Why are people even trying to get pass the hypervisor security for the push buffer operations? You have SIMD acceleration and DMA already without the RSX, just write kernel level code for OpenGL to interface with as has already been suggested.
It's not going to matter anyway. You see what kind of vendor support existing distros with OpenGL have. Nobody is going to spend years with content creation and engine development on a platform that doesn't yield much profit and frowns out of ignorance on priced software licenses. Demoscene doesn't even do much with Linux.
The cell is perfect for discreet mathematics and game engines; provided the game studio gets to use Sony licensing. If you wrote a bare metal game engine for the PS3 Sony would lock vital functions from a firmware update.
Also the few people I've seen that actually have done rational research on the security of the PS3 have all suggested this:
- CBE has the bootloader which does a signature check based on common key and loads the gameos thread from SLC NAND into the 7th SPE. The CBE is the first powered chip. The 7th SPE is identical to others, just a supervisor of sorts do to it's order of loading. The thread here dictates a lot and most importantly continues the trusted processing with signing.
- gameos uses a combination of PPC process modes and virtual addressing in the global space to filter for hypervisor calls. There are more hypervisor calls than what's in the Linux kernel source but no way to learn them other than low level probing because they are all cryp text on the SLC NAND and the 7th's local store is possibly protected. The gameos-SPE local store has it's globalization and internal EIB addressing controlled internally like every other one does; you could code another hypervisor like game os with secondary privileges even from the boot loader and run Linux in a 3rd PPE state and proxy hypervisor calls; or do a really good bootkit.
- The gameos code on the supervisor SPE puts linux in a virtualized state using the PPC process modes and the RISC is executed by the PPE in a lesser privileged mode/thread, not on a SPE exclusively as is commonly suggested; they are just extended resources. The hypervisor calls are the equivalent to protected mode calls.
- Main RAM has no ASLR-w^x-NX etc.. it doesn't need it. It's all given to the otheros environment and only protected by linux kernel allocation if configured. local stores belonging to SPEs don't either as they're also given away. The gameos SPE doesn't have execute security on it's local store but if gameos would have to allow the addressing, so most likely no go.
- gameos runs some of it's own signed processes in the same state as otheros. It also runs game images in that same state, no more details are known here but the only logical conclusion is it sets a state flag to allow the buffer operations. This allows the gameos to use it's own exception handler in the privladged CPU mode which is just as good as page locking for preventing stack and heap overflows. So if you're ever fuzzing the XMB browser or BRD loading or whatever else and you get a black screen or some error you know why. The put anything that accepts unknown inputs in that state for good reason.
The x360 actually had more security, just a sloppy bloated design. You open up and PS3 and the PCB is a clean design and you can immediately tell how it works in abstract. The x360 had one data mishandle and it flopped the security and revealed other vulnerabilities that where otherwise protected.
EDIT: Why are people even trying to get pass the hypervisor security for the push buffer operations? You have SIMD acceleration and DMA already without the RSX, just write kernel level code for OpenGL to interface with as has already been suggested.
It's not going to matter anyway. You see what kind of vendor support existing distros with OpenGL have. Nobody is going to spend years with content creation and engine development on a platform that doesn't yield much profit and frowns out of ignorance on priced software licenses. Demoscene doesn't even do much with Linux.
The cell is perfect for discreet mathematics and game engines; provided the game studio gets to use Sony licensing. If you wrote a bare metal game engine for the PS3 Sony would lock vital functions from a firmware update.