Bootvorgang der Ps3 [Tag 3]

Jetzt haben wir also einen groben Überblick über die interessanten Teile der Ps3 Hardware und die Kommunikation der einzelnen Elemente. Was wir als nächstes wissen müssen: Was passiert beim/nach dem Booten der Ps3 und "wo". Das wird das heutige Thema sein.



Als erstes möchte ich etwas klar stellen, und zwar den Unterschied zwischen einem SPE(Synergistic Processing Element) und einem SPU(Synergistic Processing Unit). Beim Lesen hat es mich etwas verwirrt, dass in einem Text immer wieder von SPE und SPU im gleichen Zusammenhang geredet wurde, allerdings ohne genaue Erläuterung.

Die Antwort ist:
SPE - Der SPU(der "Prozessor"), MFC(Memory Flow Controller) und LS(Local Storage) alles in einem.
SPU - Nur der Prozessor
Ich habe diese Informationen auch in den letzten Post eingefügt.

Aber lasst uns jetzt über den Boot Prozess reden. Wie viele von euch sicher bereits wissen, gibt es einen Unterschied zwischen dem Boot Prozess in Firmware Versionen bis 3.56 und denen darunter. Da der Unterschied im Wesentlichen nicht so riesig ist, werde ich auf den neueren Boot Prozess nicht großartig eingehen, da wir uns eh mit der Firmware 3.55 beschäftigen werden. Schließlich läuft auf dieser bereits Linux und wir können dank CFW eigenen Code ausführen.

Was passiert zuerst?


Wir drücken Power -> Das System Controller(der sog. SysCon - Der Haupt-Konfigurationschip auf dem Ps3 motherboard) bootet von seiner eigenen ROM(Read Only Memory), sendet den Cell Konfigurationring (dort sind eine Menge Optionen gespeichert, nichts worüber ich jetzt reden werde) zur Cell und betätigt den Cell reset(Da die Cell noch nicht gestartet wurde, startet sie ganz normal). Erinnert ihr euch an die Exploits in denen es um die sog. "Cell Reset Line" ging? Das war damit gemeint. Die Cell resetten. Genau wie wir an unserem Computer einen Resetschalter haben.

Die Cell lädt jetzt den bootloader(bootldr), der(im verschlüsselten Zustand) im NAND/NOR(je nachdem welches Ps3 Modell ihr habt) Speicher unserer Ps3 ist. Danach initialisiert die Cell ihren eigenen RAM(Random Access Memory) und lädt den bootloader in einen isolierten SPU.

Was ist ein isolierter SPU?


Ein SPE der im isolation mode läuft hat sich selbst vom Bus gelöst, d.h. die Anwendung welche auf diesem SPU läuft hat nur Zugriff auf den eigenen LS und hat keine Verbindung nach draußen. Dies wird durch die SPE Secure Application(geladen vom SPE Secure Loader) gemacht. Dieser Loader überprüft außerdem, ob diese Anwendung(bei uns bootldr und später metldr) modifiziert wurde oder Ähnliches. Diese Anwendung wird immer dann gestartet, wenn ein SPE im isolation mode laufen soll. Die einzige Interaktion von außerhalb, welche mit diesem SPE möglich ist, ist die aktuelle Anwendung abzubrechen, welche auf dem SPU läuft. Danach wird allerdings alles gelöscht, d.h. der LS ist leer und wir können hinterher keine sensiblen Daten mehr auslesen.

Was wir uns aber für später merken können(evtl. interessant):


"However, an area of the isolated SPE's LS is left open to data transfers to and from other units on the bus for communication purposes. The application running on the isolated SPE is responsible for ensuring that the data coming through the open communication area of its LS is safe" - Zitat aus der IBM Dokumentation.

Das heisst so viel: Ein kleiner Bereich des LS ist nach wie vor für den Datentransfer offen für bestimmte Kommunikation, der SPE muss jeweils entscheiden ob das, was über diesen Kanal ankommt, sicher ist.

Aber lasst uns weiter machen. Der verschlüsselte bootldr ist jetzt in unserem isolierten SPU. Jetzt übernimmt eine Methode die sich "Secure Runtime Boot" nennt. Diese entschlüsselt und verifiziert den bootldr und führt ihn danach aus.

Was ist Runtime Secure Boot?


Die Anwendung(bootldr in unserem Beispiel) wird in den LS des SPE geschoben. Danach wird es verifiziert, also wieder auf Modifikation untersucht und andere Sachen(die mir noch nicht bekannt sind). Mit Hilfe eines Algorithmus und dem Root Key unserer Ps3(der Masterkey) wird die Überprüfung abgeschlossen.
Wenn diese Überprüfung fehlschlägt, wird der Boot Prozess unterbrochen.

Lasst uns annehmen, dass diese Überprüfung erfolgreich war.Bootldr wird jetzt ausgeführt. Bootldr entschlüsselt jetzt lv0 und verschiebt es in den PPU Ram und der PPU führt lv0 aus. Danach geht alles ganz schnell. Lv0 lädt metldr(läuft auch in einem SPU im isolation mode) und übergibt lv1ldr,lv2ldr,appldr,isoldr und rvkldr zu metldr. Diese loader laden verschiedene SELF Dateien. Metldr hat die Keys um diese loader zu entschlüsseln und die loader wiederum haben die Keys um die SELF Dateien zu entschlüsseln. Da wir uns heute aber nicht mit Verschlüsslung beschäftigen werde ich darauf jetzt nicht näher eingehen.


Das ist im Grunde die sog. Chain of Trust(Viele von euch werden sie bereits kennen):

Im Vergleich dazu, der Baum zu den Firmware Versionen über 3.55(Alle loader sind in lv0)

Das ist alles für Heute, da ich denke, dass der Post lang genug ist ;)

- Als nächstes kommt: Verschiedene Ebenen, was sind SELFs und welche sind wichtig. Vllt. auch ein bisschen Kryptografie. Ich denke wir werden bald Linux installieren und experimentieren :)