Ich versuche, eine zusammengesetzte Datei zu zerlegen, die aus mehreren Teilen besteht, von denen einer ein unkomprimierter Kernel ist, der zwischen mehreren anderen Dateien liegt. Ich versuche, die genaue Länge des Kernel-Teils zu finden, was sich als schwierig erweist.
Gibt es im vmlinux-Header einen Hinweis darauf, wie viele Daten der Bootloader vor der Ausführung lesen soll, oder wird angenommen, dass alle Inhalte der vmlinux-Datei bei der Übergabe vom Bootloader geladen werden sollen?
Akzeptierte Antwort:
Die schnelle Antwort ist „nein“, aber wenn dies ein ELF-Image ist, können Sie mit etwas Hacking wahrscheinlich den Kernel finden. Siehe readelf unten hacken.
Der Bootloader ist dafür verantwortlich, das Format der Datei zu kennen, in der sich der Kernel und das Root-Dateisystem befinden. Dazu gehört, die Größe der Kernel-Datei zu kennen, in welchem Format auch immer. Auf PowePC und Blackfin ist der Bootloader dafür verantwortlich, den gesamten Kernel zu dekomprimieren, wenn er komprimiert ist, und ihn an seinen endgültigen Speicherort im RAM zu schreiben. Auf ARM könnte sich der Kernel selbst dekomprimieren und der Bootloader muss nur die rohe Kerneldatei an einen geeigneten Ort im RAM kopieren und die Ausführung starten.
Wenn der Kernel sich selbst dekomprimiert, dann können die Symbole, die die Größe der komprimierten Kerneldatei angeben, irgendwo im Dekomprimierungscode am Anfang der Datei sein oder auch nicht, abhängig vom verwendeten Dekomprimierungsalgorithmus, aber Sie haben keine Möglichkeit dazu zu wissen, wo ohne eine Linker-Map für den spezifischen Kernel-Build. Sicherlich hat der Bootloader keine Möglichkeit, dies zu erfahren.
Der unkomprimierte Kernel-Code selbst wird von zwei Symbolen eingeschlossen, _stext und _end deren Adressen der Anfang und das Ende des Kernels selbst sind, aber nicht den Umfang eines eingeschlossenen initramfs enthalten, wenn ein initramfs in die Kernel-Binärdatei gelinkt wurde. Der Umfang des initramfs wird vom Linker in zwei Kernelsymbolen festgelegt, __initramfs_start und __initramfs_end . Bootloader haben im Allgemeinen nicht die Fähigkeit, die Kernel-Symboltabelle zu lesen (sie befindet sich in der System.map Datei), und ohne diese Fähigkeit hätten sie keine Möglichkeit zu wissen, wo das _end ist und __initrams_end Symbole sind in der Kernel-Datei. Das heißt, die Position der Symbole ist kein fester Offset vom Beginn der Binärdatei. Sie wird zur Verbindungszeit bestimmt und kann je nach Kernel-Build-Konfiguration variieren.
Bei einem unkomprimierten Kernel im ELF-Format können Sie den Anfang der vmlinux-Datei wahrscheinlich identifizieren, indem Sie nach dem ELF-Header suchen (177 E L F im od -c Dump der zusammengesetzten Datei). Sie können dann readelf -e ausführen oder objdump -h auf dem Rest der Datei ab diesem Punkt, um den Abschnitt mit dem höchsten Datei-Offset zu finden (.shstrtab ). Addieren Sie die Abschnittsgröße zu diesem Offset hinzu und das bringt Sie zum Ende von vmlinux. Ich habe diese Methode mit einem nicht gestrippten PPC-vmlinux getestet und eine Größe erhalten, die genau der eigenständigen vnlinux-Dateigröße entsprach. Nach dem Strippen des Kernels lieferte diese Methode ein Ergebnis, das 1283 Byte weniger als die Größe des entfernten Bildes war.
Eingebettete Systeme verwenden normalerweise ein Dateiformat wie mkimage um Kernel, rootfs, Gerätebaum und andere Komponenten zu packen. U-boot zum Beispiel ist mkimage-fähig, also weiß es, wo die Kernel-Binärdatei in der mkimage-Datei beginnt und endet, und es weiß, ob der Kernel komprimiert ist oder nicht und an welche RAM-Adresse die Kernel-Datei geschrieben werden soll.