Teoria; eCOS como S.O base en Ps3

LuzbelFullHD escribió:
"The Vault is implemented as an SPE running in a special mode where it has effectively disengaged itself from the bus, and by extension, the rest of the system"

Bueno, con esto queda contestado si el Vault es sinónimo de SPE.

En cuanto al número de RNG, por un lado dicen:
"the secure, authenticated communication is achieved by the three core security features and also an on-chip hardware random number generator"

Lo de "an on-chip" parece dar a entender un solo chip , pero como un SPE en modo aislado "está desenganchado del bus, y por extensión , del resto del sistema", yo diría que , por lógica, cada SPE tendría que tener su propio RNG.
Si no fuese así, el SPE "aislado" no tendría forma de asegurar que no le están manipulando el RNG y no podría fiarse de los números "aleatorios" que le llegan por el bus.
En ningún sitio he visto escrito explicitamente que cada SPE tenga su RNG, pero no creo que a los de IBM se les haya pasado esto por lo alto.

La figura 7 también da a entender que el RNG está dentro, pero como dices, puede ser una abstracción


Gracias por la aclaración, es lo mismo que yo pensaba, lo lógico y deseable desde el putno de vista de la seguridad es que cada spe tenga su RNG,pero no he visto aclarado en ninguna parte si es uno por spe o uno por cell.Es más por "on a chip" yo entendería uno por cell.

Yo no se mucho de hardware,pero según tengo entendido generar números realmente aleatorios requiere bastante precisión y sobre todo llevar un análisis de los resultados obtenidos para garantizar que el valor generado es realmente aleatorio,todo eso se traduce en hardware extra hardware a repetir 6 veces,parece lógico unificar el RNG para reducir costes.

La cuestión es si el estudio de los RNG's del cell es un frente de ataque o realmente no se puede conseguir nada.
hombre no digo que sea imposible pero aparte de que una y la otra lo que tienen en comun es el xmb dudo que por este camino se consiga nada,pero todas las ideas son buenas aun que ya te digo una es de marte y la otra de jupiter a si que no creo que sea posible esto.en fin por probar XD
FJTR escribió:Se que es una locura, pero alguien ha probado a conectar una psp a la ps3 y meterle a la psp la bateria de pandora? es que creo recordar que la ps3 se encendia con la bateria pandora.


ya digo, no me mateis por ello, pero creo haberlo leido por aqui


Pero para hacer el pandora necesitas apagar la PSP por lo que se perderia la conexion con la PS3. o no?
LuzbelFullHD escribió:
La contrapregunta es: ¿ puedo tener un GameOS que me cargue ejecutables sin firmar ? ¿ o es obligatorio por el modo de trabajo de la CPU ? En este caso la restricción no la pone el kernel, sino más abajo , el hypervisor y el HW del Cell .



Es obligatorio. Existe la Key Root y la Master ROOt y el hyper esta dentro del cell

Al fin y al cabo tanto el GameOS, como el OtherOS se ejecutan en el mismo HW.


No, Otheros lo hace en una version capada de hardware, no "ataca" a la maquina real, sino a una version "reducida"
hay... almas de cantaro...

me hacen gracia los que preguntan el firm que se está usando para las pruebas xDDDDD

A MR.SANDMAN NO LE INTERESA CARGAR JODIDOS BACKUPS.

NO PODEIS IMAGINAR LA POTENCIA DE PROCESO QUE TIENE UN BICHO DE 400E CUANDO LAS MAQUINAS CON CELL COMERCIALES VALEN UN PASTÓN! xDD
castanha escribió:
Pero para hacer el pandora necesitas apagar la PSP por lo que se perderia la conexion con la PS3. o no?



la cosa era hacer el pandora con la psp conectada por usb a la ps3, al hacerlo la ps3 se encendia y se quedaba con la pantalla en negro......no me acuerdo el usuario que lo posteo, pero esta en el foro,,,,hace unos tres meses????
devnul escribió:
Es obligatorio. Existe la Key Root y la Master ROOt y el hyper esta dentro del cell

No, Otheros lo hace en una version capada de hardware, no "ataca" a la maquina real, sino a una version "reducida"


Entonces, en los servidores Blade que vende IBM con Cell, ¿ también van todos los ejecutables firmados y son .SELF ?
Según dices si, ya que en los Blade accederás al HW real, ya que no vas a pagar una pasta por un servidor para terminar usando un linux que ataca a una máquina virtual ...
Buenos dias

Me acabo de levantar como tantos otros, que por estas fechas tienen que trabajar, animo!

Quisiera comentar lo sucedido.


No me he registrado para buscar protagonismo, ni quiero cargar copias en ps3, ni perder el tiepo de mi vida, ( cual es limitado) para dar falsas esperanzas a un colectivo tan grande.

Humildemente ya escribi anteriormente, que no estoy en posesion de la verdad absoluta.

Intento aplicar los conocimientos adquiridos profesionalmente a este campo, y por supuesto tengo carencias en muchos aspectos relacionados con el.

Devnul, he estado leyendo los post sobre el hotel, me han hecho comprender gratamente varios problemas a los que no me habia parado a pensar realmente.

Creo que tu forma de explicar el comportamiento de la seguridad de ps3, simplemente es fantastica y si ningun pero.

Humildemente, vuelvo a pedir disculpas si alguien se ha sentido ofendido con mis explicaciones, ya que quizas, no tenga el poder de sistetizar mis ideas con claridad y desenboquen en un concepto totalmente absurdo.

Quisiera poder proseguir con lo que se ha venido estudiando en el hilo, pero como bien comenta el compañero devnul, hay muchas cuestiones inconclusas.

Si que pido una colaboracion por parte de todos, y no la pido por exalzarme a los cielos, ni por buscar un minuto de gloria, ni nada de eso.

Esto lo hago de buena voluntad, con ganas de poder disfrutar de un buen momento y poder compartirlo totalmente.


Quisiera comentar este vinculo que he encontrado en las licencias oficiales de ps3;

Mersenne Twister

http://en.wikipedia.org/wiki/Mersenne_twister

He encontrado un pequeño problema en los discos duros, una vez copiado.

Cuando inserto el disco, la consola me pide formatear.

Si cuando acaba el formateo, saco el disco e instento buscar algo de informacion anterior al mismo, no encuentro nada.

Por eso creo que el Mersenne twister, se utilice para el borrado del disco, bueno aparte de poder utilizarse en varios entornos mas, tales como la encriptacion, calculo aleatorio para generar IA, etc


Comento todo esto, por que me gustatia saber si mersenne tiene algo que ver con la encriptacion o borrado de datos del disco duro.

Un saludo.
No lo conozco personalemnte pero tiene mi respeto.

No me ofendo por sus comentarios, entiendo su postura incial y he explicado en el post anterior por que.

Si seria realmente grato poder disponer de los conocimientos de devnul, ya que tiene por la mano el tema del procesador cell.

Comentar tambien, que cell no lo controla todo, creo. ya que si la controladora de la wifi trabaja con eCOS , ( sistema operativo embebido basado en linux) se podria modificar parte de ese firmware, para abir una puerta de enlace entre el la capa de seguridad cero y uno. ( esto solo es una teoria )

La controladora de disco tiene su parte auonoma, y creo que se podria mirar algo por ahi

Un saludo
No me gusto el comportamiento de devnul antes y ahora me gusta menos, devnul vino un dia postio sobre hotel y un una banda de links con informacion y expreso sus teorias y a las 3 horas tenia gente ofreciendole regalarle un PS3...ahora viene lee un post de alguien que quizas intente hacer lo mismo que el y JUA!!! lo quema en el fogon porque tiene un lio con su pc...LOL
.ubo. está baneado por ""todos los que tiene xbox tiene amigos pleiperos y medio tontos" y después clon..."
editado ----------------
cmhacks escribió:Quisiera comentar este vinculo que he encontrado en las licencias oficiales de ps3;

Mersenne Twister



"Licenses of software used on application title

Applies when PPU libmit19937.a is used in the title only.
Please refer to the title's manual for verification.

* 1.Mersenne Twister
"

Yo, por esto, entiendo que "Mersenne Twister" es usando en algunos juegos ( o aplicaciones en un sentido más amplio) , pero no en todos y tampoco en el software del sistema en si.

Además, si seguimos los enlaces:

http://www.scei.co.jp/ps3-license/index.html ->
http://www.scei.co.jp/ps3-license/mt.html ->
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html ->
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/efaq.html

"Mersenne Twister is not cryptographically secure. (MT is based on a linear recursion. Any pseudorandom number sequence generated by a linear recursion is insecure, since from sufficiently long subsequence of the outputs, one can predict the rest of the outputs.)"

por lo que no merece la pena usarlo para temas criptográficos
( aunque en el FAQ explican algunas formas de solucionar esto ).

A mi parecer, esta libreria la usarán algunos juegos de Sony como generador de eventos aleatorios.
Bueno dejando aparte rivalidades y malos rollos.

Aunque algunas personas estubieran "equivocadas", considero que toda prueva es bienvenida.

Hasta ahora gracias a este Hilo, creo que hemos avanzado un poco en cosas que desconociamos.

Ejemplo.
Que eCos fuese el Sistema Operativo "total o parcial" de la ps3 o de alguno de sus componentes.

Considero que ya con eso la mayoria de investigadores que han aparecido actualmente "ni siquiera lo han comentado".

Cosa que es de agradecer por parte del creador.

Otro ejemplo es el estudio que ha echo perdiendo su "valioso tiempo" en estar desmontando su Disco duro y en vez de estar matando marcianitos como la mayoria estabamos, el estaba enchufandolo a un aparato para su estudio.

Que su manera de pensar de como funcionan otras cosas estubiera mal planteada por su parte, tampoco pasa nada.
Para eso estan otras personas rebatiendo ideas.
creo que este hilo puede llegar a buen puerto, si todos luchamos para el mismo lado.

Quizas con los descubrimientos de este hilo sumados con los de otros, a alguien se le encienda una luz de repente y consiga adentrarse un poco mas.

De todos modos me parecio leer en este mismo post que alguien por mediacion de las partidas guardadas o algo asi. Estaba consiguiendo algo. Y mi pregunta es. Lo maximo que puede conseguir es estar tambien "por debajo del hiper" no?
Y se esta siguiendo su trabajo y agradeciendoselo.
Aclaracion: No estoy echando por tierra el otro estudio, si no todo lo contrario, desde aqui le doy todo mi apoyo tambien.

Lo que no se si entre ese estudio y este algo se podra sacar.
Pero si que estoy seguro que entre "TODOS" los estudios alguien lo sacara.

Un saludo y buen dia a todos.
ANIMOS Y BUEN ROYO!!!
Por favor lo pido

Devnul tiene todo mi respeto, entiendo su forma de expresarse,ya que he teorizado mucho con parted de cell que no conozco.

Por eso le pido disculpas, ya que tiene parte de razon en suspalabras, esten escritas de una forma u otra.

No convirtamos el hilo en una disputa personal, ya que por mi parte no existe.


Espero que sepais comprender mi postura.

Un saludo


LuzbelFullHD, si, veo que posiblemente sea para generar eventos aleatorios en juegos que requieran IA, etc, pero se me hace extraño que se utiliza a nivel interno, no es mas que eso.

Igualmente estoy mirando todos los documentos sobre las licencias y estoy centrado en el de la empresa mercury, creadora de hypervision ( creo que esto es asi, si no lo es, por favor, no dudeis en rectuficarme )

Un saludo


Extrachato

Exacto, mi motivacion es la colaboracion entre todos los miembros de la comunidad,

Cualquiera que tenga un buen concepto, puede aplicarlo fisicamente, aunque no lleve a buen puerto, puede llegar a rozarlo.

Un saludo
@cmhacks
La gran mayoria estamos contigo, y te animamos a que sigas en tu hilo, que a la postre lo es, aunque *alguno se empeñe en ser el protagonista .
.ubo. está baneado por ""todos los que tiene xbox tiene amigos pleiperos y medio tontos" y después clon..."
cmhacks escribió:Por favor lo pido

Devnul tiene todo mi respeto, entiendo su forma de expresarse,ya que he teorizado mucho con parted de cell que no conozco.

Por eso le pido disculpas, ya que tiene parte de razon en suspalabras, esten escritas de una forma u otra.

No convirtamos el hilo en una disputa personal, ya que por mi parte no existe.


Espero que sepais comprender mi postura.

Un saludo


perdon, tienes toda la razon, perdon.

edito coño, que pesaso. :P
Creo que ante todo, debemos recobrar la postura y el buen sentido de las palabras, no solo ver el lado malo de los comentarios y rebatirlos en una sarta de acusaciones que no llevaran a algo en claro, es un hecho innegable que si todos miramos hacia el mismo lugar, podremos ver más detalles e irlos platicando para lograr conformar una verdadera visión del panorama, a voltear y discutir con el que tenemos al lado por la sencilla razón que el vió una parte más a la derecha o a la izquierda que la parte que nosotros vimos...

En su momento, devnul ha demostrado con su forma coloquial de comentar su investigación que posee un cierto conocimiento acerca de cell y el hypervisor, ahora, cmhacks, ha demostrado su afán de investigar y hacer teorías a nivel hardware en base a estudiar el funcionamiento del sistema, simplemente puedo decir, que es aplausible y gratificante su labor respecto al estudio de un sistema tan intrigante como es el ps3.

Señores, ustedes dos han hecho mucho más que los autoproclamados grupos de hackers que han aparecido en ultimas fechas, esperemos que su investigación y nuestros aportes (ya sean minimos, teoricos y hasta graciosos y fuera de contexto) puedan llegar a buen puerto...

Un saludo y gracias por proveernos de esta información con la forma desinteresada que nos muestran [bye]
siento ser tan pesado con lo mismo, pero... podria alguien que sepa de linux (pq yo, sinceramente nidea) investigar sobre el proyecto ps3grid que es un folding español? es mas que nada pq se ejecuta desde el otheros y supongo que requiere en gran parte del rsx, seria absurdo ejecutar tal cantidad de informacion tan solo sobre 256 mb de ram y 6 spe.... a parte de que este codigo, q posiblemente sea mas facil de reben.. digo.. abrir, tambien esté firmado sea por sony o no, ya que si el HV lo mira todo, sera que tiene que mirar esto tambien, no?
fidillo escribió:http://www.ps3grid.net/live.php

Salu2


no... si a ver... yo en el fondo... muy en el fondo agradezco el link ,pero ya lo puse hara como unos 100 mensajes antes.... mi pregunta no era como instalarlo sino si alguien puede investigar en como narices consigue hacer uso de los 6 spus si es que lo hace.

pronto!
jodiendooo escribió:siento ser tan pesado con lo mismo, pero... podria alguien que sepa de linux (pq yo, sinceramente nidea) investigar sobre el proyecto ps3grid que es un folding español? es mas que nada pq se ejecuta desde el otheros y supongo que requiere en gran parte del rsx, seria absurdo ejecutar tal cantidad de informacion tan solo sobre 256 mb de ram y 6 spe.... a parte de que este codigo, q posiblemente sea mas facil de reben.. digo.. abrir, tambien esté firmado sea por sony o no, ya que si el HV lo mira todo, sera que tiene que mirar esto tambien, no?


Es una distribución Linux que se ejecuta en modo OtherOS , con un cliente especializado para aprovechar los 6 SPE que puedes usar con el Cell de la PS3 en modo OtherOS.
No veo el porque ni creo que necesite de acceso a capacidades 3D del
RSX, ni que necesite más de 256 MB (Obviamente cuanta mas RAM mejor, pero aquí se trata de dividir las tareas en pequeños paquetes que puedan procesar en paralelo los SPE. ¡¡¡ Y los SPE solo tienen 256Kb !!! El procesador principal solo se limita a repartir los trabajos entre los SPE )
Si miras su distro LIVE preparada para ejecutarse directamente desde un pendrive USB, verás que ni siquiera lleva instalado el entorno gráfico X-Windows de linux, asi que de necesitar el RSX poco, excepto para el modo consola. No lo he ejecutado, pero esto seguro que se limita a conectarse por internet, baja un paquete a procesar, procesarlo en los SPU y devolverlo al servidor central.

En términos de seguridad, es equivalente a instalar cualquier otro Linux que hay para PS3 ( YellowDog, Fedora, Gentoo, etc. ) y funciona sobre HW virtualizado con el HV controlando el acceso a los límites definidos para cualquier OtherOS.

Si encuentras un fallo de seguridad para linux en modo OtherOS, también te servirá para el ps3grid y viceversa


Por cierto , ya podían informar en la página de que van a calcular en tu PS3:
En el SETI sabías que era para buscar vida extraterrestre
En Folding para plegado de proteínas (que se supone muy útil para luchar contra el cáncer )
Pero aquí te dicen:
"This workunit investigates the conformational differences that arise when TPI enzymes undergo tyrosine nitration as a consequence of inflammation, defective mithocondrial respiration and oxydative stress."

¿ esto que ***** es ?

jodiendooo escribió:mi pregunta no era como instalarlo sino si alguien puede investigar en como narices consigue hacer uso de los 6 spus si es que lo hace.

Muy fácil, cualquier distro Linux para OtherOS te permite usar las 6 SPU.
Necesitas un SDK que proporciona gratis IBM, en el que tienes todas las herramientas necesarias para compilar y cargar programas en las SPU
gracias! sigamos pues ahora con lo que estabamos...
Chicos, esto que ha pasado lo veo algo "normal".

No apalearme [poraki] que ahora me explico:

Últimamente hay muchos lammers entre nosotros sacando fakes y muchas mierdas. Es totalmente lógico que si devnull llega y lee algo que no es totalmente certero, se suba por las nubes.

Ya que a priori ignora si los aportes de cmhacks o incluso los mios propios son de buena fe o son sólo más basuras a lo que últimamente estamos acostumbrados.

Pero hablando se entiende la gente.

Yo, siempre, agradeceré que devnull ponga sus conocimientos para que todos los demás nos hagamos un poco más cultos en arquitectura CELL.

Y también es de agradecerle a cmhacks cualquier tipo de experimento que lleve a cabo, tanto a el como a cualquier otra persona.

Un experimento puede ser más o menos certero, pero seguro que gracias a los resultados de cada uno, se podrán hacer otros o pueden llegar nuevas ideas. O simplemente no volver a hacer algo que ya se vio que no tenía salida.

Es simple.

Sólamente debemos unirnos y que cada cual aporte lo que MEJOR SEPA O PUEDA ya que no todos somos ingenieros.

Yo me quedo en nivel de técnico y algo muy básico de electrónica, pero lo que si me ha enseñado la experiencia, es que no por ser técnico o ingeniero no pueda llegar pepe (que sólo anda por windows) y nos de un conocimiento nuevo.

:-| :-| :-| :-| :-| :-| :-| :-| :-|

EDITO:

¿Sabeis cuantos experimentos fallidos le hizo falta a Edison hasta lograr crear la "bombilla"?
Es totalmente lógico que si devnull llega y lee algo que no es totalmente certero, se suba por las nubes.

Perdona pero que yo sepa aqui nadie esta en posicion de aseverar quien esta o no en lo que realmente es certero.....
Aqui, mientras no se demuestre lo contrario, todo es teoria venga de fulanito o de menganito....

Por tanto el que llegue aqui un tipo en mode "catacrack", echando por tierra una teoria, y lo haga otro "teorico", es un tanto sorprendente.

A ver si estos ultimos se unen, y de la teoria nos vamos a la practica. [rtfm]
¿Porque no dejamos el tema de devnull de una *** vez pesados? Ya se ha comentado páginas atras, devnull ha dicho que él mismo reconoce que no lo hizo bien Y PUNTO, y ahora está aqui ayudando mas que ninguno junto a otros 3 o 4.

Dejemos de llenar esto de posts tontos, ya se han hecho 2 páginas hablando de ello, ahora dejen que la gente postee cosas útiles y sigamos con la dinámica del hilo.

Porfavor! xD

PD: Que nadie conteste mi post ni con +1 ni con chorradas xD
LuzbelFullHD escribió:"This workunit investigates the conformational differences that arise when TPI enzymes undergo tyrosine nitration as a consequence of inflammation, defective mithocondrial respiration and oxydative stress."

¿ esto que ***** es ?



Esta unidad de trabajo investiga las diferencias de configuración que suceden cuando la enzima TPI (triosafosfato isomerasa) pasa por un proceso de de nitracion de tirosina como consecuencia de inflamación, una respiración celular incorreta y stress oxidativo.

La traducción es un poco libre pero creo que se entiende bien.

Es decir lo que hacen es investigar como se organiza la TPI cuando la célula se estresa por varios factores.

Si tenemos en cuenta que según dicen por ahi el proceso de envejecimiento se origina en la mitocondrias, y esto viene a investigar una situación de stress en las mismas...tiene pinta de ser asquerosamente interesante,aunque puede que no este relacionado para nada con lo del envejecimiento,desgraciadamente no soy biólogo.
Bueno, a ver si alguien tiene tiempo y ganas y nos hace un resumen.
.ubo. está baneado por ""todos los que tiene xbox tiene amigos pleiperos y medio tontos" y después clon..."
keops80 escribió:Chicos, esto que ha pasado lo veo algo "normal".

No apalearme [poraki] que ahora me explico:

Últimamente hay muchos lammers entre nosotros sacando fakes y muchas mierdas. Es totalmente lógico que si devnull llega y lee algo que no es totalmente certero, se suba por las nubes.



llamarlo " subirse por las nubes" es muy suave maxo, tu ves" logico" que insulte y se pnga como seha puesto? pufff se ha creido que es dios como le decian en sus hilos o algo asi... esto es 100000000 veces mas interesante y productivo que sus macros post del hotel, llenos de links y mucha "teoria", bien que le trataron con RESPETO todo el mundo, y mira ahora.

please seguid y dejad los OFFTOPIC por que uno lleva a otro, y devenul que se vaya a construir el hotel.

-------------------------------------------------------------------------
system_042 no habia leido tu post, sorry tienes razon.
wah_wah_69 escribió:tiene pinta de ser asquerosamente interesante,aunque puede que no este relacionado para nada con lo del envejecimiento,desgraciadamente no soy biólogo.


Cientos de PS3 trabajan en un proyecto que podría usarse para tratar el Alzheimer
sirix105 está baneado por "clon de usuario baneado"
wah_wah_69 escribió:
Esta unidad de trabajo investiga las diferencias de configuración que suceden cuando la enzima TPI (triosafosfato isomerasa) pasa por un proceso de de nitracion de tirosina como consecuencia de inflamación, una respiración celular incorreta y stress oxidativo.

La traducción es un poco libre pero creo que se entiende bien.

Es decir lo que hacen es investigar como se organiza la TPI cuando la célula se estresa por varios factores.

Si tenemos en cuenta que según dicen por ahi el proceso de envejecimiento se origina en la mitocondrias, y esto viene a investigar una situación de stress en las mismas...tiene pinta de ser asquerosamente interesante,aunque puede que no este relacionado para nada con lo del envejecimiento,desgraciadamente no soy biólogo.


el envejecimiento es una suma de factores, pero se supone q son los radicales libres generados en la respiracion celular miticondiral los que hacen q los telomeros de los cromosomas se acorten paulativamente y al final la celula no se puede dividir mas y muere, por eso no somos inmortales, si pudieramos mantener la regeneracion de unbebe en una persona adulta no moririamos, bueno a nivel neuronal nose q pasaria pero el resto del cuerpo viviria para siempre, pero no producir radicales libres es imposible pork sino las celulas no respiran y sin respirar no obtenemos aTP y sin atp no tenemos energia para los procesos vitales y morimos,.

uan manera de producir radicales libres mas lentamente es ingerir antioxidantes q solo estan en los vegetales, y nosotros no producimos.
Zagales devnull ya pidio disculpas unas paginas atras así que callarse ya de una put* vez que no haceis na más que llevar el post por el camino que no conviene

edito: y de paso abrid un hilo de biologia en ps3 que los tiros tampoco van por ahi...
.ubo. escribió: esto es 100000000 veces mas interesante y productivo que sus macros post del hotel, llenos de links y mucha "teoria", bien que le trataron con RESPETO todo el mundo, y mira ahora.



Sin la teoria de algebra, sin las propiedades de conjuntos, numeros enteros, etc... jamas haras una operacion aritmetica entre dos numeros dados.

PUedes teorizar como se hace A + B = C para cualquier entero y si para cualquier entero C - B = A, pero para ello, necesitas saber la teoria.

Ahora vamos a algo mas real que una simple suma.

Cuando alguien dice que quiere descifrar cualquier cosa cifrada, SABIENDO la teoria, esta parte esta totalmente descartada,porque matematicamente es posible, pero no en un tiempo finito tal que nosotros lleguemos a sobrevivir, es decir, demasiado tiempo de calculo (aun usando ps3 en una granja)

Cuando se quieren interceptar paquetes, modificar el codigo etc etc.. hace falta saber que es la Key Master y la Key Root y un largo etc.

La teoria, por muy aburrida que sea, es la base fundamental de cualquier estudio,hipotesis,ensayo o intento de practica.

Si no se sabe como funciona un cell, es absurdo plantearse segun que o perder el tiempo investigando sobre X cuando lo que realmente es mas productivo, es leerse el tocho impresionante de los white papers del cell. Pero claro, es mas facil

a) que se lo lea otro
b) que te lo cuente otro
c) darle palmaditas en la espalda a otro...

Si no se sabe de mecanica cuantica, ni de fisica cuantica, puedes teorizar todo lo que quieras respecto a los dos estados que puede tener una cosa, pero por ese motivo, ya empiezas mal porque en mecania y fisica cuantica, se tienen todos los estados posibles a la vez, al mismo tiempo que no se tiene ninguno. Por ello, la teoria, es necesaria (la critica no va a chmhacks, sino a quien me decia algo sobre lo de la teoria)

Apartir de aqui, sabiendo como va el cell, donde reside el hypervisor y que es... si es software, o es hardware (algo tan "simple" como eso cambia mucho la forma de enfrentarse a su funcionamiento),la reparticion de la carga de trabajo, y la imposibilidad de cargarselo con un DDOS (que es lo primero que se probó y se pensó) con un TDDOS a cualquier puerto abierto, hace que una y otra vez, se invierta tiempo en temas que leyendo (si, la teoria) se veria desde otro punto de vista y solo plantear la hipotesis, se responderia.

Respecto al OtherOs, esta (es libre y publico) el SDK del CEll, podemos programar las SPE sin problema alguno, se puede hacer homebrew, y un largo etc... y no, ahi no va firmado nada. Porque?

Si un niño pequeño tiene un globo, la realidad es todo el conjunto. Si somos el aire que esta dentró del globo, nuestra realidad es el globo, y no existe nada mas para nosotros. OtherOs esta dentro de un Globo, todo lo que hagas ahi dentro (sin acceder a la rsx al completo) es valido.

Pensar, que cuando se dice que no hay acceso a la aceleracion por hardware 3D NO QUIERE DECIR, que no haya aceleracion por software en 3D.

EDITADO:

Por cierto, si alguien quiere tomarselo en serio.... aqui tiene todo lo que necesita

--> he IBM Cell BE Software Sample and Library Source Code package, together with the accompanying system simulator, kernel, and development tool chains, gives serious developers first-hand programming experience on the revolutionary Cell BE architecture. The package provides a rich set of optimized standard Synergistic Processor Element (SPE) C library routines that greatly reduce the development cost and enhance the performance of SPU programs. A variety of application-oriented libraries, including Fast Fourier Transform (FFT), image, audio resample, math, game math, intrinsics, matrix operation, multi-precision math, noise generation, oscillator, surface, synchronization, and vector, are also included in order to demonstrate the versatility of Cell BE architecture.

---> http://www.bitpipe.com/detail/RES/1148656659_938.html?src=econsult

http://www-01.ibm.com/chips/techlib/techlib.nsf/products/IBM_SDK_for_Multicore_Acceleration

http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/1DFEF31B3211112587257242007883F3

http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/FC857AE550F7EB83872571A80061F788

http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/30B3520C93F437AB87257060006FFE5E

http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F



En lugar de suposiciones, leerse como se inicializa


This document describes the sequences for initializing a Cell Broadband Engine CMOS SOI 10KE processor, from Power-On Reset (POR) through calibration of the memory and I/O interfaces and the PowerPC Processor Element (PPE) firmware.

http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/BD3F1F4C3DB32C7487257142006131BC


1. Overview of the Cell Broadband Engine Processor .............................................. 17
1.1 Hardware Overview ......................................................................................................................... 17
1.1.1 The Processor Elements ....................................................................................................... 18
1.1.2 Element Interconnect Bus ..................................................................................................... 19
1.1.3 Memory Interface Controller .................................................................................................. 19
1.1.4 Cell Broadband Engine Interface ........................................................................................... 20
1.1.5 Detail Block Diagram ............................................................................................................. 23
1.2 Clock Domains ............................................................................................................................... 25
1.3 System Configuration ...................................................................................................................... 27
1.4 System Controller Overview ............................................................................................................ 29
2. Initialization Sequences ........................................................................................... 31
2.1 Power-On Reset Sequence ............................................................................................................ 32
2.1.1 POR Sequence Summary ..................................................................................................... 32
2.1.2 Reset Detection ..................................................................................................................... 35
2.1.3 POR Phase 0 ......................................................................................................................... 36
2.1.4 POR Phase 1 ......................................................................................................................... 37
2.1.5 POR Phase 2 ......................................................................................................................... 37
2.2 Firmware Sequence ........................................................................................................................ 56
2.2.1 Firmware-Sequence Flowchart and Pseudocode .................................................................. 57
2.2.2 Initialization of MIC, XDR I/O Cells, and XDR DRAM ............................................................ 62
2.3 Debug of the POR Sequence .......................................................................................................... 90
2.3.1 POR Phase 1 Check ............................................................................................................. 92
2.3.2 POR Phase 2 Entry Check .................................................................................................... 92
2.3.3 RQ and DQ Debugging ......................................................................................................... 92
2.3.4 Configuration-Ring Load Check ............................................................................................ 93
2.3.5 FlexIO Calibration Check ....................................................................................................... 94
2.3.6 POR Sequence Completion Check ....................................................................................... 94
2.3.7 Power-Off Sequence ............................................................................................................. 95
3. Serial Peripheral Interface ........................................................................................ 97
3.1 SPI Operation ................................................................................................................................. 97
3.1.1 SPI Conventions .................................................................................................................... 97
3.2 SPI Protocol ................................................................................................................................... 98
3.2.1 SPI Command ........................................................................................................................ 98
3.2.2 SPI Address ........................................................................................................................... 99
3.2.3 SPI Data ............................................................................................................................... 105
3.3 SPI Sequence Types ..................................................................................................................... 105
3.3.1 Simple Write Sequence ....................................................................................................... 106
3.3.2 Simple Read Sequence ....................................................................................................... 106
3.3.3 Polling ................................................................................................................................. 106
3.3.4 ICB Sequences .................................................................................................................... 107
3.4 SPI Registers ............................................................................................................................... 113
3.4.1 SPI Status Register .............................................................................................................. 113
3.4.2 Write Configuration Ring (wr_config_ring) ......................................................................... 117
3.4.3 ICB Poll Register (icb_poll) ................................................................................................ 117
3.4.4 Read CBE Chip ID (rd_chip_id) .......................................................................................... 118
3.4.5 Read Serial Number Register (rd_serial_num0, rd_serial_num1) ...................................... 119
3.4.6 Read Voltage ID (rd_VID) .................................................................................................... 120
3.4.7 Read Partial Good Register (rd_partial_good) ................................................................... 121
3.4.8 Read Linear Thermal Diode Calibration Register (rd_lin_therm_diode) ............................ 122
3.4.9 Read POR Status Register (rd_por_status) ....................................................................... 123
3.4.10 Read ICB Data Register (rd_icb_data) ............................................................................. 124
4. Configuration Ring .................................................................................................. 125
4.1 Load Path ..................................................................................................................................... 125
4.2 Bit Descriptions ............................................................................................................................. 126
5. Signal Descriptions ................................................................................................. 141
5.1 Signal Groups ............................................................................................................................... 141
5.2 Input/Output-Signal Layout ............................................................................................................ 142
5.3 Signal Descriptions ........................................................................................................................ 142
5.3.1 FlexIO Interface ................................................................................................................... 142
5.3.2 FlexIO Power Supplies and References .............................................................................. 144
5.3.3 XDR Memory Interface: Channel 0 ...................................................................................... 145
5.3.4 XDR Memory Serial Interface: Channel 0 ............................................................................ 146
5.3.5 Memory XIO Interface Power Supplies and References: Channel 0 ................................... 147
5.3.6 XDR Memory Interface: Channel 1 ...................................................................................... 148
5.3.7 XDR Memory Serial Interface: Channel 1 ............................................................................ 148
5.3.8 XDR Memory XIO Interface Power Supplies and References: Channel 1 .......................... 149
5.3.9 Serial Peripheral Interface ................................................................................................... 149
5.3.10 Core PLL ............................................................................................................................ 151
5.3.11 Miscellaneous I/O Signals .................................................................................................. 151
5.3.12 Miscellaneous Test I/O ...................................................................................................... 152
5.3.13 Power Supply ..................................................................................................................... 153
Appendix A. Memory-Mapped I/O Registers ............................................................. 155
A.1 Classification of Registers ............................................................................................................. 155
A.2 MMIO-Access Rules for 32- and 64-Bit Registers ........................................................................ 156
A.3 MMIO Memory Map ...................................................................................................................... 156
Appendix B. Fault Isolation Register Overview ....................................................... 159
B.1 Local FIRs .................................................................................................................................... 160
B.1.1 Local FIR Logic Diagrams ................................................................................................... 161
B.1.2 Setting, Resetting, and Masking Errors in Local FIRs ......................................................... 163
B.2 Global FIR Registers .................................................................................................................... 163
B.2.1 Global Checkstop FIR ......................................................................................................... 163
B.2.2 Global Recoverable FIR ...................................................................................................... 164
B.2.3 Global FIR Error Enable Mask ............................................................................................ 164
B.2.4 Global FIR Mode ................................................................................................................. 164
B.2.5 Global FIR for Special Attention and Machine Check ......................................................... 165
B.2.6 Local Recoverable Error Counters and Local Error Counter Status ................................... 165
Appendix C. Livelock Resolution Mode .................................................................... 167
C.1 System Controller Actions ............................................................................................................ 167
C.2 Configuration Ring Settings .......................................................................................................... 168
C.3 Fault Isolation Bit Settings ............................................................................................................ 168
C.4 Operating-System Requirements ................................................................................................. 168
Appendix D. DQ Pin Mapping .................................................................................... 171
D.1 Syndrome-to-Pin Mapping ............................................................................................................ 171
D.2 DQ Pin-to-Byte in Cache Line Mapping ........................................................................................ 174
Appendix E. Memory Interface Controller ................................................................ 175
E.1 MIC Features ............................................................................................................................... 176
E.2 Basic Functional Description ........................................................................................................ 177
E.2.1 Command Selection Rules .................................................................................................. 177
E.2.2 Coherency and Memory Model ........................................................................................... 177
E.3 MIC Configuration Details ............................................................................................................. 177
E.3.1 MIC Control Configuration ................................................................................................... 177
E.3.2 XDR DRAM Controller Configuration .................................................................................. 178
E.3.3 Dataflow Configuration ........................................................................................................ 184
E.3.4 Sample MIC Configuration .................................................................................................. 185
E.4 Special Modes .............................................................................................................................. 187
E.4.1 Slow Mode .......................................................................................................................... 187
E.4.2 Fast Path Mode ................................................................................................................... 188
E.4.3 Token Manager (Resource Allocation Manager) ................................................................ 188
E.4.4 High-Priority Reads ............................................................................................................. 188
E.4.5 Speculative Read Mode ...................................................................................................... 189
E.4.6 Early Read Support ............................................................................................................. 189
E.5 Scrub Function and Error Correction Code Functions .................................................................. 189
E.6 Setting Up Refreshes .................................................................................................................... 191
E.7 Refresh Considerations ................................................................................................................ 192
E.8 Write Mask Function ..................................................................................................................... 193
E.9 Main Memory Information ............................................................................................................. 193
E.9.1 Memory Capacity ................................................................................................................ 193
E.9.2 Real-to-Physical Address Mapping ..................................................................................... 194
E.9.3 Memory Banks .................................................................................................................... 197
E.10 Starting, Stopping, Restarting, and Initializing the MIC .............................................................. 198
E.10.1 Starting the MIC ................................................................................................................. 198
E.10.2 Stopping the MIC ............................................................................................................... 198
E.10.3 Restarting the MIC ............................................................................................................. 198
E.10.4 Initializing the MIC ............................................................................................................. 198
E.11 DD 3.X Errata ..............................................................................................................................

Y ENTONCES, dime que la teoria no sirve. Que prefieres .ubo. suposicines o realidad? Pues ahi tienes realidad, pero claro... es pesado leerse 200 paginas como minimo para saber como funciona, no?



Me cansé de pastear, aqui teneis el recurso principal: http://www-01.ibm.com/chips/techlib/techlib.nsf/products/Cell_Broadband_Engine

Y sin esta teoria, no se hace una leche, porque o sabes de mecanica, o el coche de fernando alonso, ni lo arreglas, ni lo mejoras.

PD: la critica, no va para chmhacks
Esque en lugar de quedarse "sentado" (es una expresion) mirando "como parece que funcoina" leches, leerse realmente como funciona que pasos sigue, que carga,como, que tamaño tiene por donde pasa,etc etc etc... Y ENTONCES plantear todas las hipotesis que se os vengan a la cabeza y mas, faltaria mas, valga la redundancia

De lo que me quejo y lo que me mosquea, es que despues de haberme leido mas de 2000 santas paginas del cell, alguien que no se ha leido NI UNA me diga que la teoria no sirve, ESO SI me enciende.

This document covers the initialization of the Cell Broadband Engine (CBE) processor, from first
applying power to the step just before loading a hypervisor or an operating system. It includes the
early power-on reset (POR) sequence, calibration of memory and I/O interfaces, and the
PowerPC Processor Element (PPE) firmware sequence. It is written for system designers and
laboratory engineers involved in booting the CBE processor. It does not cover any specific
system design. Therefore, the only system requirements covered are those that apply to any
system built around the CBE processor. Documents that are frequently referred to are listed in
Section Related Publications on page 11.
Even though the main focus of this document is about the initialization of the CBE processor,
additional topics are included (as appendixes) that apply to typical operation and are not part of
the initialization: fault isolation registers, livelock resolution mode, and memory interface
controller information.
The term YRAC (Yellowstone Rambus application-specific integrated circuit [ASIC] cell) is an old
term for the Rambus extreme data rate (XDR) I/O Cell (XIO). The old term still appears in register
names.
Redwood Rambus Access cell (RRAC) is an old term for the FlexIO cell. The old term still
appears in register names


PD: Todos los que hemos estudiado ingenieria de sistemas sabemos linux,particiones etc (leelo en tono jocoso :P y distendido) :P

PD2: Lo que yo no voy a hacer es decir, ei... estoy haciendo esto o estoy haicendo aquello... Yo cuando tenga algo, lo postearé tal cual, que es como se deberian hacer las cosas, y no con tanto fake basura, q si video en youtube, que si contador en una pagina web si mil tonterias, q dudo muchisimo que ni uno solo de ellos de los tropecientos manuales sobre el funcionamiento del cell,del hypervisor,etc se hayan leido ni una sola linea.
Nononono que no te lo decia a ti hombre, era a .ubo. :)

Respecto a la cantidad de procesadores del cell

There are nine processor elements in the CBE processor—one PPE and eight identical Synergistic
Processor Elements (SPEs). All processor elements are connected to each other and to
the on-chip memory and I/O controllers by the high-bandwidth, coherent EIB.
The PPE is the control processor. It contains a 64-bit, dual-thread PowerPC Architecture™
reduced instruction set computer (RISC) core with a traditional PowerPC virtual-memory
subsystem. It has 32 KB level-1 (L1) instruction and data caches and a 512 KB level-2 (L2)
unified (instruction and data) cache. It is intended primarily for controlling operations, running
operating systems, managing system resources, and managing SPE threads. It can run existing
PowerPC Architecture software and system-control code. The instruction set for the PPE is an
extended version of the PowerPC instruction set. It includes the vector/single instruction multiple
data (SIMD) multimedia extensions and associated C and C++ intrinsic extensions.
The eight SPEs are SIMD processor elements that are optimized for data-rich operations allocated
to them by the PPE. Each of these identical elements contains a RISC core, 256 KB software-
controlled local store for instructions and data, and a 128-bit, 128-entry unified register file.
The SPEs support a special SIMD instruction set, the Synergistic Processor Unit Instruction Set
Architecture, and a unique set of commands for managing tasks such as direct memory access
(DMA) transfers between main storage and an SPE’s local store and for interprocessor
messaging. An SPE relies on DMA transfers to asynchronously move data and instructions
between main storage and its local stores while the SPE computes simultaneously. Each SPE
has a PowerPC-architecture-compatible memory-management unit. SPE DMA transfers access
main storage using PowerPC effective addresses. As in the PPE, SPE address translation is
governed by PowerPC Architecture segment and page tables, which are loaded into the SPEs by
privileged software on the PPE. The SPEs are not intended to run a formal operating system.
An SPE communicates with the system by means of its memory flow controller (MFC). An SPE
uses a channel interface for this communication. SPE channels are unidirectional access ports,
between the SPE execution units and the SPE MFC, to function-specific registers and queues
implemented in and managed by the MFC. The PPE and other devices in the system, including other SPEs, can also access this MFC state through the MFC memory-mapped I/O (MMIO)
registers and queues, which are visible in the main-storage address space. The SPE channels
and their corresponding MMIO state support functions such as DMA control, mailboxes, and
signal-notification between all processor elements in the system.

Element Interconnect Bus
The EIB is the communication path for commands and data between all processor elements on
the CBE processor and the on-chip controllers for memory and I/O. The EIB supports full
memory-coherent and symmetric multiprocessor operations.
The EIB manages four 16-byte-wide data rings, which interconnect all units on the chip. Each
ring transfers 128 bytes at a time. Two rings run clockwise, and two rings run counterclockwise.
Each unit has one on-ramp and one off-ramp. Units attached to the rings can drive and receive
simultaneously. Multiple transfers can be in-process concurrently on each ring.
The EIB internal maximum bandwidth is 96 bytes per processor cycle, and it can support more
than 100 outstanding DMA memory requests between main storage and the SPEs. The EIB does
not support any particular quality-of-service (QoS) behavior other than to guarantee forward
progress. However, the EIB contains a token manager unit, and software can use it to regulate
the rate at which particular devices are allowed to make EIB command requests.

The memory interface controller (MIC) provides the interface between the EIB and main storage.
It supports one or two XDR memory interfaces (channels), which together support from 64 MB to
64 GB of XDR dynamic random access memory (DRAM). The interfaces are often referred to as
XIO cell interfaces.
Memory accesses on each interface are 1 to 8, 16, 32, 64, or 128 bytes, with coherent memoryordering.
Up to 64 reads and 64 writes can be queued. A token manager provides feedback
about queue levels.
The MIC supports multiple software-controlled modes, including fast-path mode (for reduced
latency when command queues are empty), high-priority read (prioritizes PPE reads and SPE
atomic reads in front of all other reads), early read (a read can start before a previous write is
completed), speculative read1, and slow mode (power management). The MIC implements a
closed-page controller (bank rows are closed after being read, written, or refreshed), memory
initialization, memory scrubbing, and auxiliary trace data storage (a debug feature).
Error correction code (ECC) protects the XDR DRAM memory with multibit error detection and
optional single-bit error correction. Additional features include optional early read, write-masking,
initial and periodic timing calibration, dynamic width control, subpage activation, dynamic clock
gating, and 4, 8, or 16 memory banks.

etc ec... q si lo preferiis tecnico, lo suelto tecnico, pero vamos a mi me parece que es mejor la explicacion "simple" del hotel, pero bueno.. ahora para quien se quejaba del hotel, ahi tiene todos los recursos tecnicos oficiales.

Respecto a su inicializacion

The entire initialization
is performed in two sequences:
1. Power-on reset (POR) sequence—This hardware sequence requires the assistance of an
external system controller, and it occurs before code runs on the CBE processor.

2.-Firmware Sequence—This sequence starts the execution of code on the PowerPC Processor
Element (PPE). It initializes the extreme data rate (XDR) I/O cell (XIO) memory interface,
dynamic random access memory (DRAM), and some of the PPE hardware-implementation
dependent (HID) special-purpose registers (SPRs


Una de las cosas mas interesantes, son estas dos:

Because the HID1 SPR defaults to all zeros during POR, the PPE takes a system reset interrupt
and starts thread 0 from the address specified in the PPE SReset Vector field of the configuration
ring. As a result of the system reset interrupt, the hypervisor and 64-bit-mode bits, MSR[HV] and
MSR[SF], are both set to ‘1’, so that the PPE comes up in hypervisor mode.
From this point forward, the system controller does not participate in CBE initialization. If the
ATTENTION signal switches to active after the POR sequence is complete, it indicates that an
error condition has occurred and that the CBE processor needs the system controller’s help. In
this case, the system controller must read the rd_spi_status register to determine what caused
the ATTENTION signal and take appropriate action.

y esto otro

Firmware Sequence Pseudocode
The following pseudocode is an example of firmware initialization sequence.
entry: (This is at offset 0x100 and can be in ROM or XDR)
IF executing in ROM
Call init_regs.
Initialize the I/O bridge chip and other system-specific devices.
Select an SPE.
Call init_spe.
Copy the PPE XIO/XDR initialization code into the SPE local store.
Call the XIO/XDR initialization function (code located in SPE).
Clear the NCRS0 bit in the MMIO EIB_Cfg Register.
Copy the ROM code into the XDR memory.
Stop thread 0, and start thread 1 (thread 1 starts at 0x100 in the XDR memory).
ELSE
IF thread 1 is executing
Call init_regs.
Stop thread 1, and start thread 0 (thread 0 starts at 0x100 in the XDR memory).
ELSE
Complete the initialization for the rest of the system components.
Load and execute the operating system.
ENDIF
ENDIF

init_regs:
// Set the syserr_wakeup, en_prec_mchhk, qattn_mode, en_syserr, and en_attn bits in
// HID0.
Write SPR HID0 with 0x000000AB00000000.
// Set the dis_sysrst_reg bit in HID1 to disable the thread 0 PPE SReset vector
// address in the configuration ring. This makes 0x100 the reset vector for
// thread 0. This also enables the L1 instruction cache.
Write SPR HID1 with 0x9C30104000000000.
// Enable the L1 data cache.


Write SPR HID4 with the 0x00003F0000000000 ORed into the original value.
// Set RMSC to 1110b which sets the real address boundary at 2 TB
// (0x2000000000000000000).
Write with mask SPR HID6 masking the original value with 0xFFFFFFC300000000 and ORing
in the value 0x0000003800000000.
// Set the RMI bit in LPCR to make the memory above the real address
// boundary (the RMSC in HID6) guarded and noncacheable for data.
Write SPR LPCR with 0x0000000000000002 ORed into the original value.
// Set the DISP_CNT field in TSCR to 4, and set the bits PBUMP, FPCF, and PSCTP.
Write TSCR with 0x200D0000.
// Set the TTIM field in the TTR register to 0x01F4.
Write SPR TTR with 0x00000000000001F4.
// Disable the timebase by clearing tb_enable in HID6.
Write HID6 with the original value ANDed with 0xFFFEFFFFFFFFFFFF.
// Write the TBR Register with the Timebase_mode (internal or external time base sync
// mode) and the Timebase_setting which is the divisor for the internal time base if
// the CBE is operating in internal sync mode.
Write MMIO TBR with the Timebase_setting and Timebase_mode.
// Set tb_enable in HID6 to enable the time base.
Write HID6 with the original value ORed with 0x0001000000000000
return
The function init_spe initializes an SPE so that PPE code can be copied into its LS and run by
the PPE.



Y esto de pastear es un rollo, asi que la info la teneis en los pdf, que como podeis comprobar son ASQUEROSAMENTE UTILES.
Refloto una cuestión mia planteada hace n-mil mensajes

devnul escribió:Es obligatorio. Existe la Key Root y la Master ROOt y el hyper esta dentro del cell

No, Otheros lo hace en una version capada de hardware, no "ataca" a la maquina real, sino a una version "reducida"


Entonces, en los servidores Blade que vende IBM con Cell, ¿ también van todos los ejecutables firmados y son .SELF ?
Según dices si, ya que en los Blade accederás al HW real, ya que no vas a pagar una pasta por un servidor para terminar usando un linux que ataca a una máquina virtual ...
TIenes la respuesta justo arriba :) no recordaba tu nick
devnul escribió:TIenes la respuesta justo arriba :) no recordaba tu nick


Pues no la veo entre tanto post .... :-(
El hypervisor, es el propio cell (que se activa o no en funcion de lo mencionado anteriormente) es decir, que es HARDWARE e intrinseco al cell.

No confundamos el cell como procesador y como "consola" es decir, las firmas digitales en un server con ell obviamente, no son de sony xD sino seria el chollo de su vida para sony xD!
LuzbelFullHD escribió:
Pues no la veo entre tanto post .... :-(


Mis dudas vienen por cosas como esta:


http://www.ibm.com/developerworks/blogs/page/powerarchitecture?entry=030708_forum_watch

"If you are running Linux, then your ability to access these Privilege 1 registers will depend upon whether Linux is running on top of a Hypervisor. For example, on a PS3, Linux runs on a Hypervisor. Therefore, only the Hypervisor will be able to access these registers. If you are running on a blade, Linux runs on the bare metal and therefore you can either build a custom kernel or construct a kernel load module read the thermal sensor registers."

Bien , de esto deducimos que el linux que se ejecuta en los servidores Blade sería mas parecido al GameOS de PS3 que al linux que se ejecuta en el OtherOS de PS3. Es decir, que ataca al HW real y no a uno virtualizado

¿ pero, por lo que dices, esto no implicaría que el linux de las blades, y los binarios de sus aplicaciones , debería ser SELF ? (*)
Sin embargo , el linux que bajas para una blade ( lo puedes sacar del http://www.bsc.es ) es normal ¿¿¿¿????

(*) Obviamente ,como dices, las firmas de estos ejecutables no serán de Sony ...

pero sigo sin ver claro porque si accedes al HW real del Cell tu código y datos deben estar firmados y encriptados en todo momento
.ubo. está baneado por ""todos los que tiene xbox tiene amigos pleiperos y medio tontos" y después clon..."
devnul escribió:Nononono que no te lo decia a ti hombre, era a .ubo. :)



pues ya que me citas por activo y por pasivo, pues habra que contestarte...

tas lucio, relee,por que maxo solo he dicho que este post me interesa mas que tu teoria, tengo derecho a que no me guste ni me interese tu hotel, creo yo, asi que todo ese rollo que has soltao de la teoria no se a que viene, "teoria" sobre la "teoria" , muy interesante, pero no viene a cuento.

dije esto:
" esto es 100000000 veces mas interesante y productivo que sus macros post del hotel, llenos de links y mucha "teoria", bien que le trataron con RESPETO todo el mundo, y mira ahora."


dime, tu como sabes que no he leido ni UNA sola pagina sobre el cell.. ? pero si no he dicho ni mu...... ?¿? esto es un poco flipante.

cita del que todo lo sabe:
"De lo que me quejo y lo que me mosquea, es que despues de haberme leido mas de 2000 santas paginas del cell, alguien que no se ha leido NI UNA me diga que la teoria no sirve"

sigue con tus tochos please.
LuzbelFullHD escribió:Bien , de esto deducimos que el linux que se ejecuta en los servidores Blade sería mas parecido al GameOS de PS3 que al linux que se ejecuta en el OtherOS de PS3.


"Ma o Meno" La ventaja es que puedes tener un linux "moldeable" un custom linux, solo con aquello que te interesa y en diferentes modulos para cargar diferentes realidades virtuales sobre una misma maquina

pero, por lo que dices, esto no implicaría que el linux de las blades, y los binarios de sus aplicaciones , debería ser SELF ?

Sin embargo , el linux que bajas para una blade ( lo puedes sacar del http://www.bsc.es ) es normal ¿¿¿¿????


Confundes el uso de la NAND :) no extrapoles el uso que se le da a la nand, para la ps3, que el uso que tiene para un servidor "normal"

Lo que si se podria hacer (aunque va contra la filosofia linux) es que solo un Unix cifrado pudiera correr en esa maquina (aunque en terminos de seguridad tiene su logica) es mas, que una distribucion que tu quieras o te desarrolle la empresa X, te la firme y solo puedas ejecutarla tu, tambien tendria sentido (si estan dispuestos a gastarse mucha pasta,claro)


(EDITO) --> .ubo. --> .Yo no tengo ninguna teoria, te estoy contando como funciona internamente el cell.

ime, tu como sabes que no he leido ni UNA sola pagina sobre el cell.. ? pero si no he dicho ni mu...... ?¿? esto es un poco flipante.


coño,porque te gusta la expliicacion de una cosa, q no funciona como te han dicho que funciona :) de ahi lo se hijo mio :)
devnul escribió:Confundes el uso de la NAND :) no extrapoles el uso que se le da a a nand, para la ps3, que el uso que tiene para un servidor "normal"



¿¿¿??? Creo que efectivamente es aquí donde está mi confusión ...
A ver si consigo ya aclararme del todo ...
¿ a qué te refieres con la NAND ? ¿ a donde se guarda el firmware o ROM inicial ?

Si es así , vuelvo a mi pregunta inicial, una vez asegurado que el firmware es correcto, que impide a ese firmware cargar un ejecutable sin encriptar de cualquier dispositivo y ponerlo a ejecutar


devnul escribió:Lo que si se podria hacer (aunque va contra la filosofia linux) es que solo un Unix cifrado pudiera correr en esa maquina (aunque en terminos de seguridad tiene su logica) es mas, que una distribucion que tu quieras o te desarrolle la empresa X, te la firme y solo puedas ejecutarla tu, tambien tendria sentido (si estan dispuestos a gastarse mucha pasta,claro)


Con esto conseguirías que en tu Blade solo se pudiese ejecutar ese Linux en concreto , y así tendrías la seguridad de que ningún hacker ha podido manipularlo ¿ no ?
Vamos, que es lo que ha hecho Sony , cambiando Blade por PS3 , y Linux por el SO que usen en el XMB ¿ voy bien ?

Ahora la pregunta del millón ¿ cómo se conseguiría esto ?

¿ qué necesitas activar o programar en los Cell de tu Blade, para que pasen de cargar cualquier cosa en el arranque a que solo se permita ejecutar ese kernel de linux y binarios firmados ?

Volviendo a la pregunta anterior, ¿ sólo el kernel estaría firmado o también deberían firmarse las aplicaciones que cargue ese kernel ?

Ah, y por cierto, no veo porque esto estaría en contra de la filosofía linux. Mientras que devuelvas los fuentes (sin las claves de encriptación) a la comunidad, no hay problema en hacer una versión "segura"


Muchas gracias por la paciencia, que no paro de preguntar :-)
Si, vas bien :)

Pues cuando se inica el PPE hay un modo especifico en que se torna en hypervisor mode, si se consiguen cambiar los dos bits que hace que se entre en ese modo, a tomar x culo el hypervisor :)

Mi trono por 2 bits (vease la ironia) ;)

(edito: has ampliado la pregunta, voy a comer y luego te contesto) :)
Hola a todos, haber se pedia que devnul echara un vistazo y lo ha echo pero, cmhacks comentanos algo de tus descubrimientos y ya que uno y otro sois los que mas conocimientos teneis poneros en contacto, no?
De la union nace la fuerza, asinque que la fuerza os acompañe
mmm después de leer algunos post sin mucho conocimiento e informarme acerca del tema, tan solo he de decir una cosa.
En primer lugar respecto a las teorias de la gente, tan solo puedo decirles que se informen antes de postear teorias y que si creen que van por buen camino que las prueben ellos mismos, que posteen sus resultados les animo a que prueben con sus ps3 que por algo estan aqui en el foro de Scene para colaborar con ella.

En cuanto a las criticas a algunos users que han intentado colaborar y que saben del tema, tan solo darles animo desde aquí y ofrecerles colaboración para ir adelante. Si supierais lo que ha hecho Devnul mas de uno de aquí estaría ahora mismo besandole los pies.

Bueno lo único que puedo pediros es calma y que colaboréis un poco más y como antes os dije os animo a que probéis vosotros mismos.
Yo me leeria las 200 y pico páginas, pero lo malo es que no se casi nada de inglés, me pasa como a google...
devnul escribió:Si, vas bien :)
Pues cuando se inica el PPE hay un modo especifico en que se torna en hypervisor mode, si se consiguen cambiar los dos bits que hace que se entre en ese modo, a tomar x culo el hypervisor :)
Mi trono por 2 bits (vease la ironia) ;)
(edito: has ampliado la pregunta, voy a comer y luego te contesto) :)


Si, el flag del procesador MSR[HV] si no me equivoco.

Veamos, ...

1) Si arranco una Blade, el firmware lo primero que hace es desactivar el modo hypervisor , y a partir de ahí , como una CPU normal
2) Si arranco una Blade, y en el firmware mantengo el modo hypervisor , todo lo que cargue debería ir firmado y ser comprobado. Supongo que en el arranque de mi firmware pongo una SPU en modo aislado y la dedico a verificar los ejecutables que entran.

Supongo que el firmware en ambos casos, está encriptado ya que el PPE se arranca por defecto en modo hypervisor -> para que veas que me leo los docs. ;-)

Pero si mantengo el modo hypervisor, ¿ la firma de lo que cargue es la misma de la que uso para cargar el firmware ?

Con esto tendríamos el linux seguro del que hablabamos antes.


3) Si arrancas una PS3 en modo GameOS, el modo HV sigue activado para que el Cell controle que todo lo que se carga esta firmado y es correcto , pero basicamente el acceso esta permitido a todo el HW real

4) Si arrancas una PS3 en modo OtherOS, el modo HV sigue activado, y se crea una máquina virtual sobre la que se ejecuta el OtherOS . Al ser una máquina virtual los procesos del OtherOS van sin encriptar, aunque para acceder al HW usan llamadas al HV, que está aisladito y protegido en una SPU en modo aislado, aceptando como únicas entradas controladas las syscalls


Obviamente el modo 3 y el 2 serían lo mismo, y podríamos desperdiciar una costosa Blade usandola en modo 4 con un linux "capado"

Ah, y el modo 1 sería lo que todos queremos en nuestra PS3.
Pero si me confirmas que esto es así, no queda otra que conseguir la firma de Sony, y firmar un "custom firmware" que meteriamos en la flash y que al arrancar desactivase el HV.
Desarrollar un firmware que inicialize y arranque la máquina es poco menos que imposible, ¡¡¡ y mucho menos obtener la firma de Sony !!!
Claro que si tenemos la firma de Sony y tenemos nuestro propio firmware, el dejar el HV activado o no nos da igual, ya que lo controlariamos.


¿ es así , maestro ? ;-) porque, la verdad, que no creo que sea así ...
Pues venga, llamemos a Sony a que nos de unos autografos (Firmas) xDDDDDDDDDD.

Modo1: Jodido de cojones....

Alguna idea?

Salu2
cmhacks escribió:
Buenas

Intentare explicar bien que es el hypervision

El sistema de seguridad de Ps3, en realidad no es un sistema de seguridad propiamente dicho.

Cuando le das corriente a Ps3, es el primer programa que carga, y este programa llamado hypervision, hacer que se cargue la misma informacion en 8 procesadores diferentes.

Si anulas hypervision, matas la consola.

Una vez cargado hypervision en todos los nucleos, se procede a la carga del sistema operativo, que puede ser eCOS, Ecos es un mini linux alijerado.

Ese minilinux no lo controla el hypervision, lo unico que controla es que el sistema operativo que carga, sea el de sony y no el de manolito el hacker.




Pues no... no hace eso. Lo que hace es lo siguiente:

Power-On Reset Sequence

2.1.1 POR Sequence Summary
The POR sequence is a hardware sequence that relies on handshaking between the CBE
processor and the system controller. The system controller is responsible for supplying the
appropriate data to the CBE processor when requested and for coordinating the initialization of
CBE support chips, such as the clock generator and companion chips.
The following major activities are accomplished during the POR sequence:

• Initialize the CBE core logic, reset the internal state, and set up the core phase-locked loop
(PLL).

• Adjust the VRM voltage according to the voltage identifier (VID) information stored in the
CBE processor.

• Load the configuration-ring data.

• Calibrate the FlexIO interface (initialization, bit calibration, and byte calibration).

• Initialize the I/O interface.


Start

Set HARD_RESET = INACTIVE
Wait ATTENTION = ACTIVE
PLL data interally loaded from fuses
Set HARD_RESET = ACTIVE
Set POWER_GOOD = INACTIVE
Initialize Clock Generators
Initialize Power Supplies
Set POWER_GOOD = ACTIVE
ATTENTION = INACTIVE
Confirm rd_spi_status[10:11] = '10'
Adjust VRM Voltage
Write Configuration-Ring Data
Wait ATTENTION = ACTIVE
Confirm rd_spi_status[10:11] = '01'
Ready to calibrate FlexIO
Calibrate FlexIO
Set wr_spi_status[8] = '1'
I/O calibration complete
Start PPE System Reset Interrupt

To start POR phase 0, the system controller must drive the POWER_GOOD and HARD_RESET
signals to zero. Next, the power supplies and reference clocks must be activated. The CBE
power supplies must be turned on in the following order:
1. I/O voltage supplies (VDD_IO).
2. CBE core voltage supply (VDD).
3. Analog voltage supplies (VDD_A).
At this point, the VID value for the VRM is not available to be read. Therefore, at this point, the
VRM needs to be set to a default VID value (see the Cell Broadband Engine Datasheet). The
final VID value becomes available later in the POR sequence.
A minimum time (see the Cell Broadband Engine Datasheet) after the power supplies and the
reference clocks have stabilized, the POWER_GOOD signal can be raised to active.

POR Phase 1
The CBE processor uses four signals, SYS_CONFIG[0:3], to determine the internal steps that
occur during the POR sequence. For typical booting of the CBE processor, these signals are tied
to ground (GND). These signals are tied to GND or MC2_VDDIO through resistors on the system
board.
Phase 1 of the POR sequence begins with the switching of the POWER_GOOD signal from inactive
to active. During phase 1, the PLL configuration register will be set up from internal storage
(fuses) as a result of the SYS_CONFIG[0:3] pins being set to ‘0000’. The PLL configuration
register is an internal register that is not accessible in the memory-mapped I/O (MMIO) register
space.
After a minimum time (see the Cell Broadband Engine Datasheet) has elapsed, counting from
the rising edge of POWER_GOOD, the HARD_RESET signal can be changed to inactive. This
triggers the next phase (Phase 2).

Phase 2 of the POR sequence starts when the HARD_RESET signal changes from active to
inactive. The following steps occur during POR Phase 2:

1. Adjust the VRM according to the VID value and
load the configuration ring

2. Calibrate the FlexIO interface,

3. Start the PPE

The adjustment of the VRM according to the VID value and the configuration-ring load are
treated as one event notification from the CBE processor.
The CBE processor signals the system controller that configuration data is required by activating
the ATTENTION signal. The system controller then reads bits [10:11] of the Read SPI Status
Register (rd_spi_status) to determine the cause of the ATTENTION signal. The VRM value
must be set to the VID value stored in CBE processor before loading the configuration-ring data.

VRM Adjustment with VID Value
When the CBE processor activates the ATTENTION signal, the system controller reads the SPI
Read Voltage ID (rd_VID) Register. This register contains 8 bits of VID information, to which the
VRM should be set. At this point, the CBE voltage can be adjusted. After the CBE core VDD
voltage has stabilized to the new VRM setting (stabilization is dependent on the VRM chosen),
the system controller proceeds with loading the configuration ring

Configuration-Ring Load

The configuration ring provides chip-level configuration information

This ring is defined as a write-only location, the SPI Write
Configuration Ring (wr_config_ring) register, at SPI register address x‘0001’ in the CBE pervasive
logic. The configuration ring can only be written by the system controller during the POR
sequence. The system controller reads the Read SPI Status Register (rd_spi_status) to determine
when the configuration ring can be written. If rd_spi_status[10:11] = ‘10’, then the CBE
processor is ready for the configuration-ring data to be loaded.

The configuration-ring write operation differs from writes to other SPI registers in several ways:
• The length of the data portion is flexible. This is not the case for all other SPI registers. The
CBE processor determines the end of the configuration-ring data not by fixed length, but by a
start bit plus the number of bits in the configuration ring.
• Configuration-ring data must be scanned in reverse bit order. The configuration ring is 2697
bits long (0:2696). Data is scanned in from bit 2696 (least significant bit) to bit 0 (most significant
bit). Therefore, the data portion in Figure 2-5 will have a start bit followed by bit 2696, bit
2695, and so forth, to bit 0. This only applies to the data portion of the SPI protocol, and not
for the command or address portions.
• Access to the wr_config_ring SPI register is only effective one time during POR, when
requested explicitly from the CBE processor. An attempt to write this register during any
other time has no effect.

The CBE FlexIO interfaces

perform two types of calibration at POR:

• Bit Calibration—This adjusts the bits within each 8-bit-wide Rambus channel for differences
in circuit, wiring, and loading delays between the multiple bits of the Rambus channel. Bit calibration
also calibrates the signal driver current and driver impedance, and it equalizes the
eight data bit timings to center the data eye around the clock edges.

• Byte Calibration—This equalizes the timings of the 8-bit channel groups that make up the
FlexIO interfaces (IOIF0 and IOIF1). Byte calibration also establishes the correct envelope
framing on the interface by detecting the location of the start-of-envelope pattern.
Only the FlexIO interfaces are calibrated during the POR sequence. The XIO memory interface is
calibrated during the firmware sequence

After the system controller has finished writing the configuration-ring data, the system controller
again waits for the ATTENTION signal to go active on the CBE processor. When the ATTENTION
signal is active, the system controller reads the SPI Status (rd_spi_status) Register
(Section 3.4.1.1 on page 114) to determine if rd_spi_status[10:11] = ‘01’, indicating that the
CBE processor is ready to start FlexIO calibration
rd_spi_status[10:11] is not ‘01’). The system controller then sends a series of SPI commands
to the CBE processor to do the calibration. Bit calibration is performed first, followed by byte-calibration.

Code on page 50 is complete, the system controller sets wr_spi_status[8] = ‘1’ to indicate that
the I/O calibration is complete. The POR state machine then sets the status in the
rd_por_status[8:9] to ‘01’ to reflect this.

Firmware Sequence

After the system controller has notified the CBE processor that I/O calibration has completed (as
indicated by wr_spi_status[8] = ‘1’), the POR state machine sets rd_por_status[8:9] to ‘01’ to
indicate that I/O calibration has completed and is no longer active. The POR sequence is then
complete, and the POR state machine instructs the PPE to begin running code. This indicates
the beginning of the firmware sequence

Because the HID1 SPR defaults to all zeros during POR, the PPE takes a system reset interrupt
and starts thread 0 from the address specified in the PPE SReset Vector field of the configuration
ring. As a result of the system reset interrupt, the hypervisor and 64-bit-mode bits, MSR[HV] and
MSR[SF], are both set to ‘1’, so that the PPE comes up in hypervisor mode.
From this point forward, the system controller does not participate in CBE initialization. If the
ATTENTION signal switches to active after the POR sequence is complete, it indicates that an
error condition has occurred and that the CBE processor needs the system controller’s help. In
this case, the system controller must read the rd_spi_status register to determine what caused
the ATTENTION signal and take appropriate action.

The associated code, which
follows this figure, is typically written in PPE assembler code. It is shown here as pseudocode for
readability and because some external devices, such as an I/O bridge chip and read-only
memory (ROM), exist in a system but are beyond the scope of this document. The XIO and
memory interface controller (MIC) initialization is part of the PPE firmware sequence and is
discussed in more detail in Section 2.2.2 Initialization of MIC, XDR I/O Cells, and XDR DRAM on
page 62.
The flowchart and pseudocode assume that the system has already initialized an interface to an
I/O bridge chip by means of the SPI interface, and that the following firmware is already loaded
into a ROM attached to the I/O bridge chip, such that the entry point is at the address specified in
the PPE SReset Vector field of the configuration ring, with the low-order address bits equal to
x‘100’.
The firmware is run from ROM the first time through the sequence. Then, the HID1 register is
initialized so that thread 0 will go to address x‘00 0000 0100’ the next time thread 0 is used
(which, in this example, is in the extreme data rate [XDR] memory space). After calibrating the
XIO interface and initializing the XDR DRAM, using the local store (LS) memory space for one of
the SPEs as memory for the PPE, the PPE copies the code from ROM to XDR memory and then
starts thread 1.
The calibration of the XIO interface and the initializing of XDR DRAM uses the LS memory space
of one Synergistic Processor Element (SPE) as instruction and data memory for the PPE. The
XIO calibration is performed from an SPE’s LS rather than ROM, because using this read/write
memory simplifies the creation of a stack in C code. To use an SPE’s LS, the PPE first enables
LS-address translation by setting the S and D bits in the MFC_SR1 register for the selected SPE
(see the memory map chapter of the Cell Broadband Engine Programming Handbook for
details). As an alternative, XIO calibration can be done from ROM without using an SPE’s LS
memory, but in that case the code is typically written in assembly language.
After calibrating the XIO interface and initializing memory with good error correcting code (ECC),
the PPE copies the code from ROM to the PPE’s XDR memory space and then starts thread 1 to
initialize the registers for thread 1. Thread 1 always starts at address x‘00 0000 0100’, which is in
XDR memory. Thread 1 initializes the registers used by thread 1, and then the code switches to
thread 0 again (also at x‘0000000100’) to complete the rest of the system firmware initialization.
This completes the firmware sequence.

etc...


LuzbelFullHD --> Ahi esta :) (hay icono d aplausos?) :P
501 respuestas
15, 6, 7, 8, 911