Glad my points were good, was afraid it would be flagged as stupid rambling
Yes, I understand the difficulty of getting out of VM and everything involved (user/kernel space/etc..) but who knows, it's still worth the shot.. I mean, yes the VM was designed not to be broken out from, but the whole PS3 was designed that way too..
By the way, when I said "the first code we can execute", I meant "from the XMB firmware OS".
Also, about OtherOS, it's not the same thing, IMHO. I'm not in the loop with the PS3 dev stuff (and I still can't access the dev forum
) but I was guessing that the OtherOS was running as native code on the processor in it's own space, we could break through there, that's one door, one opportunity, but the VM is just yet another door that might not be as secure as the OtherOS system... They probably put a lot of security over OtherOS because they knew people would try to break in from there.. maybe they didn't put as much effort in the BD-J VM since it's not the "natural" way to go for breaking in...
Also the VM is running from the firmware OS, so maybe it's already one step closer to the kernel... In either case, it's better to be slamming two doors at once rather than just one, whichever breaks first will be the gate to our freedom!
Anyways, I'm just thinking of a buffer overflow, you get your code run from there and you can execute whatever you want, any sandbox or watchdog or whatever would not be able to prevent/protect a buffer overflow, unless the kernel/processor has a specific 'sandbox' flag that can be set on a process... but again, maybe we could use the buffer overflow to inject code into another higher-level security process and use that instead to gain access..
To conclude: nothing is 100% secure!
I just hope you guys didn't completely drop this opportunity.
p.s.: Wasn't there also some other way to execute unsigned code from an older firmware version ?
Keep it up!