Verified Commit 76a0db1e authored by Sebastian Endres's avatar Sebastian Endres
Browse files

Final fixes.

parent 005612be
Pipeline #29139 failed with stage
in 1 minute and 8 seconds
......@@ -8,7 +8,7 @@ Dabei werden sie klassischerweise komplett vor der Ausführung in binären Masch
Daraus ergeben sich allerdings einige Probleme:
Einerseits muss man schon bei der Übersetzung spezifisches Wissen über die Zielmaschine besitzen.
Man muss beispielsweise die Zielarchitektur und mögliche Erweiterungen kennen, wie z.\,B. Vektor- oder Floatingpointeinheiten, aber teilweise sogar Annahmen über den Aufbau des gesamten Systems treffen, also beispielsweise wie viele CPU-Kerne maximal vorhanden sein werden.
Dieses Wissen ist aber häufig nicht vorhanden und die Realität zeigt, dass die verwendete Hardware häufig äußerst unterschiedlich ist.
Dieses Wissen ist aber häufig nicht vorhanden und die Realität zeigt, dass die verwendete Hardware äußerst unterschiedlich ist.
Ein General Purpose Betriebssystem wie \emph{Linux} wird beispielsweise auf hoch performanten Server- oder Clustersystemen genauso verwendet wie auf Heimcomputern oder aber sogar auf mobilen Geräten, wie Smartphones, und auf eingebetteten Systemen, wie Steuerrechnern.
Deshalb werden Möglichkeiten benötigt, das Betriebssystem anzupassen.
......@@ -45,25 +45,24 @@ Bootloader werden heute schon zum Laden von Betriebssystemen verwendet.
Wenn dieses Programm klein genug ist und wenn die Anzahl an benötigten Varianten dieses Bootloaders, um einen Großteil von Zielsystemen abzudecken, klein genug ist, könnten diese als Bestandteil des Betriebssystemabbildes mit verteilt werden.
Aufgabe dieses Programms ist es, den Zwischencode des eigentlichen Betriebssystems just-in-time für die Zielarchitektur zu kompilieren.
Das kann zum großen Teil während des Starts des Betriebssystems, also zur Bootzeit, erfolgen.
Je nachdem, wie ausgeprägt der Just-in-Time-Compiler ist, können aber Teile auch erst später bei Bedarf übersetzt werden.
Je nachdem, wie der Just-in-Time-Compiler ausgeprägt ist, können Teile auch erst später bei Bedarf übersetzt werden.
Da der Compiler im Gegensatz zum Ahead-of-Time-Compiler im klassischen Ansatz auf der Zielhardware selbst ausgeführt wird, kann er in einem vorhergehenden Schritt konkrete Informationen zum Zielsystem sammeln und bei der Übersetzung mit einbeziehen.
Es ist zu hoffen, dass dadurch bisher kaum genutzte Funktionen (hauptsächlich CPU-Instruktionen) erkannt und intensiv verwendet werden können.
Des Weiteren kann oben genannte Komplexität aus dem Betriebssystemcode entfernt werden.
Denn das ist eher Aufgabe des Compilers und nicht der Programmierenden.
Dadurch wäre eine saubere Trennung der Belange möglich, ohne Performance zu verlieren.
Des Weiteren kann oben genannter selbst modifizierender Code aus dem Betriebssystem entfernt werden, da das eher Aufgabe des Compilers und nicht der Programmierenden ist.
Dadurch ist eine saubere Trennung der Belange möglich, ohne Performance zu verlieren.
Ein sauberer Code kann, wie später genauer erklärt, vom Compiler besser optimiert werden.
Es ergäben sich sogar neue Möglichkeiten, die bisher nicht oder schwer umsetzbar sind.
Wenn der Zwischencode nicht nur hardware- sondern auch sprachunabhängig ist und viele Sprachen in diese Zwischensprache übersetzt werden können, dann ist es möglich, sich für die Entwicklung nicht auf eine oder wenige Sprachen festzulegen.
Beispielsweise gibt es in einem Betriebssystem viele Teile, die einfacher durch weiter entwickelte Sprachen als C oder C++ programmiert werden können.
Funktionen, bei der weniger die Maschine als der Logikablauf im Vordergrund stehen, könnten beispielsweise mit Rust, Python oder Haskell programmiert werden, wenn sich das anbietet und dann in den gleichen Zwischencode übersetzt und vereint werden.
Da heutzutage immer noch eine Hauptursache für Sicherheitslücken in Betriebssystemen Unzulänglichkeiten der Programmiersprache sind (z.\,B. Arrayüberläufe, Over- und Underflows), würde dieser Ansatz zur Sicherheit und Zuverlässigkeit entscheidend beitragen.
Funktionen, bei der weniger die Maschine als der Logikablauf im Vordergrund stehen, könnten beispielsweise mit Rust, Python oder Haskell programmiert werden, wenn sich das anbietet, und dann in den gleichen Zwischencode übersetzt und vereint werden.
Da heutzutage immer noch eine Hauptursache für Sicherheitslücken in Betriebssystemen Unzulänglichkeiten der Programmiersprachen sind (z.\,B. Arrayüberläufe, Over- und Underflows), würde dieser Ansatz zur Sicherheit und Zuverlässigkeit entscheidend beitragen.
Außerdem könnte über den Bootloader eine Schnittstelle für sauberes und universelles Live-Patching des Kernels geschaffen werden.
In dieser Arbeit wurde versucht, einen Prototypen eines solchen Bootloaders für die neue \emph{ARMv8 AArch64} Architektur (siehe \cref{sec:instructionset}) am Beispiel des \emph{Raspberry Pis} (siehe \cref{sec:rpi}) zu erstellen.
Als leistungsfähiger und stark optimierender \acl{JIT} wurde das \emph{LLVM}-Compilerframework samt \emph{\ac{LLVM-IR}} gewählt (siehe \cref{sec:llvm}), um von der großen Community und der weit vorangeschrittenen Entwicklung des Projektes zu profitieren.
Für die \emph{x86}-Architektur hat Dustin Nguyen bereits einen Prototypen angefertigt, der in der Lage ist, einen \emph{FreeBSD}-Kernel zur Laufzeit zu kompilieren und zu booten und hat dabei große Speedups erreicht~\cite{Dustin} (siehe \cref{sec:furtherWork}).
Es gab noch weitere ähnliche Ansätze in der Wissenschaft, die im \cref{sec:similarProjects} kurz angesprochen werden.
Es gab noch weitere ähnliche Ansätze in der Wissenschaft, die im \cref{sec:similarProjects} angesprochen werden.
Aufgrund des großen Aufwandes und vielerlei Probleme mit der Toolchain (siehe \cref{sec:architecture}) ist der Bootloader, der aus dieser Arbeit resultiert, nur teilweise funktionsfähig und es können leider noch keine aussagekräftigen Analysen stattfinden.
% vi: spell spelllang=de
This diff is collapsed.
......@@ -138,7 +138,7 @@ Diese wiederum benötigt Funktionalität einer C-Standardbibliothek (libc).
\vspace{-4cm}
\begin{flushright}
\includegraphics[width=.8\textwidth]{figures/bootcamp_hierarchy.pdf}
\caption{Hierarchie der Komponenten von Bootcamp}
\caption{Hierarchie der Komponenten von \emph{Bootcamp}}
\label{fig:bootcamp-hierarchie}
\end{flushright}
\vspace{-1.7cm}
......@@ -489,7 +489,7 @@ Ein anderer großer Teil der Modifikationen besteht aus Auskommentieren von Chec
\begin{figure}[H]
\centering{}
\includegraphics[width=\textwidth]{figures/build_bootcamp.pdf}
\caption{Kompilierprozess von Bootcamp}
\caption{Kompilierprozess von \emph{Bootcamp}}
\label{fig:buildprocess}
\end{figure}
......@@ -505,7 +505,7 @@ Der Videocore des \emph{Raspberry Pi}s lädt, wenn es eine Datei mit diesem Name
\begin{figure}[H]
\centering{}
\includegraphics[width=\textwidth]{figures/preparation_of_os.pdf}
\caption{Vorverarbeitung des Betriebssystemcodes für Bootcamp}
\caption{Vorverarbeitung des Betriebssystemcodes für \emph{Bootcamp}}
\label{fig:osBuildprocess}
\end{figure}
......
......@@ -116,7 +116,7 @@
@online{LWNARM64,
author = {Jonathan Corbet},
title = {{Supporting multi-platform ARM kernels}},
title = {{Supporting 64-bit ARM systems}},
journal = {LWN.net},
year = {2012},
month = {05},
......@@ -202,7 +202,7 @@
@article{JavaHotSpot,
author = {Kotzmann, Thomas and Wimmer, Christian and M\"{o}ssenb\"{o}ck, Hanspeter and Rodriguez, Thomas and Russell, Kenneth and Cox, David},
title = {Design of the Java HotSpot\&Trade; Client Compiler for Java 6},
title = {Design of the Java HotSpot Client Compiler for Java 6},
journal = {ACM Trans. Archit. Code Optim.},
issue_date = {May 2008},
volume = {5},
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment