diff --git a/documentation/linux_configuration.pdf b/documentation/linux_configuration.pdf
index 80033ce..4284513 100644
Binary files a/documentation/linux_configuration.pdf and b/documentation/linux_configuration.pdf differ
diff --git a/documentation/linux_configuration.tex b/documentation/linux_configuration.tex
index ca360ca..c8ed134 100644
--- a/documentation/linux_configuration.tex
+++ b/documentation/linux_configuration.tex
@@ -2137,69 +2137,107 @@ Laufe der Zeit verschwinden. Ändern Sie diese Option nicht, wenn Sie nicht wiss
 
 \subsubsection{Build a relocatable kernel}
 CONFIG\_RELOCATABLE [=y] \textbf{[Y]}\\
-This builds a kernel image that retains relocation information so it can be loaded someplace besides the default 1~MB.
-The relocations tend to make the kernel binary about 10~\% larger, but are discarded at runtime.
-One use is for the kexec on panic case where the recovery kernel must live at a different physical address than the
-primary kernel.
-Note: If CONFIG\_RELOCATABLE=y, then the kernel runs from the address it has been loaded at and the compile time
-physical address (CONFIG\_PHYSICAL\_START) is used as the minimum location.
+Dadurch wird ein Kernel-Image erstellt, das die Informationen über den Standortwechsel beibehält, so dass es an
+einem anderen Ort als den standardmäßigen 1~MB geladen werden kann.
+Die Verschiebungen machen das Kernel-Binary etwa 10~\% größer, werden aber zur Laufzeit verworfen.
+Eine Anwendung ist der kexec on panic-Fall, bei dem der Wiederherstellungs-Kernel an einer anderen
+physikalischen Adresse liegen muss als der primäre Kernel.
+Anmerkung: Wenn CONFIG\_RELOCATABLE=y ist, dann läuft der Kernel von der Adresse aus, an der er geladen wurde,
+und von der zur Kompilierzeit physische Adresse (CONFIG\_PHYSICAL\_START) als Mindeststandort verwendet.
 
 \paragraph{Randomize the address of the kernel image (KASLR)}$~$\\
 CONFIG\_RANDOMIZE\_BASE [=y] \textbf{[Y]}\\
-In support of Kernel Address Space Layout Randomization (KASLR), this randomizes the physical address at which the
-kernel image is decompressed and the virtual address where the kernel image is mapped, as a security feature that
-deters exploit attempts relying on knowledge of the location of kernel code internals.
-On 64-bit, the kernel physical and virtual addresses are randomized separately. The physical address will be anywhere
-between 16~MB and the top of physical memory (up to 64~TB). The virtual address will be randomized from 16~MB up to
-1~GB (9 bits of entropy). Note that this also reduces the memory space available to kernel modules from 1.5~GB to 1~GB.
-On 32-bit, the kernel physical and virtual addresses are randomized together. They will be randomized from 16~MB up to
-512~MB (8 bits of entropy).\\
-Entropy is generated using the RDRAND instruction if it is supported. If RDTSC is supported, its value is mixed into
-the entropy pool as well. If neither RDRAND nor RDTSC are supported, then entropy is read from the i8254 timer. The
-usable entropy is limited by the kernel being built using 2~GB addressing, and that PHYSICAL\_ALIGN must be at a
-minimum of 2~MB. As a result, only 10 bits of entropy are theoretically possible, but the implementations are further
-limited due to memory layouts.\\
-If unsure, say Y.
+Zur Unterstützung der Kernel Address Space Layout Randomization (KASLR) werden
+die physische Adresse, an der das Kernel-Image dekomprimiert wird, und
+die virtuelle Adresse, auf die das Kernel-Image abgebildet wird,
+randomisiert. Dies ist ein Sicherheitsmerkmal, das Exploit-Versuche verhindert,
+die auf der Kenntnis des Speicherorts von Kernel-Code-Interna beruhen.
+Bei 64-Bit werden die physische und die virtuelle Adresse des Kernels getrennt randomisiert.
+Die physische Adresse liegt irgendwo zwischen 16~MB und dem Anfang des physischen Speichers
+(bis zu 64~TB). Die virtuelle Adresse wird von 16~MB bis zu 1~GB randomisiert
+(9 Bits Entropie).
+Beachten Sie, dass dadurch auch der für Kernel-Module verfügbare Speicherplatz
+von 1,5~GB auf 1~GB reduziert wird.
+Bei 32-Bit werden die physischen und virtuellen Adressen des Kernels zusammen
+randomisiert. Sie werden von 16~MB bis zu 512~MB randomisiert (8 Bits Entropie).\\
+Die Entropie wird mit dem RDRAND-Befehl erzeugt, sofern er unterstützt wird.
+Wenn RDTSC unterstützt wird, wird sein Wert ebenfalls in den Entropie-Pool
+gemischt. Wenn weder RDRAND noch RDTSC unterstützt werden, wird die Entropie aus
+dem i8254-Zeitgeber gelesen. Die nutzbare Entropie ist dadurch begrenzt, dass der
+Kernel mit 2~GB-Adressierung aufgebaut ist und dass PHYSICAL\_ALIGN mindestens
+2~MB betragen muss.
+Infolgedessen sind theoretisch nur 10 Bits Entropie möglich, aber die
+Implementierungen sind aufgrund des Speicherlayouts noch weiter eingeschränkt.\\
+Wenn Sie unsicher sind, sagen Sie Y.
 
 \subsubsection{Alignment value to which kernel should be aligned}
 CONFIG\_PHYSICAL\_ALIGN [=0x200000] \textbf{[0x200000]}\\
-This value puts the alignment restrictions on physical address where kernel is loaded and run from. Kernel is compiled
-for an address which meets above alignment restriction.\\
-If bootloader loads the kernel at a non-aligned address and CONFIG\_RELOCATABLE is set, kernel will move itself to
-nearest address aligned to above value and run from there.
-If bootloader loads the kernel at a non-aligned address and CONFIG\_RELOCATABLE is not set, kernel will ignore the
-run time load address and decompress itself to the address it has been compiled for and run from there. The address
-for which kernel is compiled already meets above alignment restrictions. Hence the end result is that kernel runs
-from a physical address meeting above alignment restrictions.\\
-On 32-bit this value must be a multiple of 0x2000. On 64-bit this value must be a multiple of 0x200000.\\
-Don't change this unless you know what you are doing.
+Dieser Wert legt die Ausrichtungsbeschränkungen für die physikalische Adresse fest, von der der Kernel geladen und
+ausgeführt wird. Der Kernel wird für eine Adresse kompiliert, die den obigen Ausrichtungsbeschränkungen entspricht.
+Wenn der Bootloader den Kernel an einer nicht ausgerichteten Adresse lädt und CONFIG\_RELOCATABLE gesetzt ist,
+verschiebt sich der Kernel an die nächstgelegene Adresse, die auf den obigen Wert ausgerichtet ist, und wird von
+dort aus gestartet.
+Wenn der Bootloader den Kernel an einer nicht ausgerichteten Adresse lädt und CONFIG\_RELOCATABLE nicht gesetzt ist,
+ignoriert der Kernel die Ladeadresse zur Laufzeit und dekomprimiert sich an die Adresse, für die er kompiliert wurde,
+und läuft von dort aus. Die Adresse, für die der Kernel kompiliert wurde, erfüllt bereits die oben genannten
+Ausrichtungsbeschränkungen. Das Endergebnis ist also, dass der Kernel von einer physikalischen Adresse aus läuft,
+die die oben genannten Ausrichtungsbeschränkungen erfüllt.
+Bei 32-Bit muss dieser Wert ein Vielfaches von 0x2000 sein. Bei 64-Bit muss dieser Wert ein Vielfaches von 0x200000 sein.\\
+Ändern Sie dies nicht, wenn Sie nicht wissen, was Sie tun.
 
 \subsubsection{Randomize the kernel memory sections}
 CONFIG\_RANDOMIZE\_MEMORY [=y] \textbf{[Y]}\\
-Randomizes the base virtual address of kernel memory sections (physical memory mapping, vmalloc \& vmemmap).
-This security feature makes exploits relying on predictable memory locations less reliable. The order of
-allocations remains unchanged. Entropy is generated in the same way as RANDOMIZE\_BASE. Current implementation
-in the optimal configuration have in average 30,000 different possible virtual addresses for each memory section.\\
-If unsure, say Y.
+Randomisiert die virtuelle Basisadresse von Kernel-Speicherabschnitten (physische Speicherzuordnung, vmalloc \& vmemmap).
+Dieses Sicherheitsmerkmal macht Exploits, die sich auf vorhersehbare Speicherplätze verlassen, weniger zuverlässig. Die Reihenfolge der
+Zuweisungen bleibt unverändert. Entropie wird auf die gleiche Weise wie bei RANDOMIZE\_BASE erzeugt. Aktuelle Implementierung
+in der optimalen Konfiguration haben im Durchschnitt 30.000 verschiedene mögliche virtuelle Adressen für jeden Speicherabschnitt.\\
+Wenn Sie unsicher sind, sagen Sie Y.
 
 \subsubsection{Linear Address Masking support}
 CONFIG\_ADDRESS\_MASKING [=y] \textbf{[Y]}\\
-Linear Address Masking (LAM) modifies the checking that is applied to 64-bit linear addresses, allowing software
-to use of the untranslated address bits for metadata.\\
-The capability can be used for efficient address sanitizers (ASAN) implementation and for optimizations in JITs.
+Linear Address Masking (LAM) ändert die Prüfung, die auf lineare 64-Bit-Adressen angewandt wird, und ermöglicht der Software
+die nicht übersetzten Adressbits für Metadaten zu verwenden.\\
+Diese Fähigkeit kann für die effiziente Implementierung von Adress-Sanitizern (ASAN) und für Optimierungen in JITs genutzt werden.
 
 \subsubsection{Disable the 32-bit vDSO (needed for glibc 2.3.3)}
 CONFIG\_COMPAT\_VDSO [=n] \textbf{[N]}\\
-Certain buggy versions of glibc will crash if they are presented with a 32-bit vDSO that is not mapped at the
-address indicated in its segment table.\\
-The bug was introduced by f866314b89d56845f55e6f365e18b31ec978ec3a and fixed by
-3b3ddb4f7db98ec9e912ccdf54d35df4aa30e04a and 49ad572a70b8aeb91e57483a11dd1b77e31c4468.
-Glibc 2.3.3 is the only released version with the bug, but OpenSUSE 9 contains a buggy "glibc 2.3.2".\\
-The symptom of the bug is that everything crashes on startup, saying:
-texttt{dl\_main: Assertion `(void \*) ph-$>$p\_vaddr == \_rtld\_local.\_dl\_sysinfo\_dso}\\
-Saying Y here changes the default value of the vdso32 boot option from 1 to 0, which turns off the
-32-bit vDSO entirely. This works around the glibc bug but hurts performance.\\
-If unsure, say N: if you are compiling your own kernel, you are unlikely to be using a buggy version of glibc.
+Bestimmte fehlerhafte Versionen der glibc stürzen ab, wenn sie mit einem 32-Bit vDSO konfrontiert werden, das nicht auf die in
+der Segmenttabelle angegebene Adresse abgebildet ist.
+Adresse zugeordnet ist, die in der Segmenttabelle angegeben ist.\\
+Der Fehler wurde eingeführt durch f866314b89d56845f55e6f365e18b31ec978ec3a und behoben durch\\
+3b3ddb4f7db98ec9e912ccdf54d35df4aa30e04a und 49ad572a70b8aeb91e57483a11dd1b77e31c4468.\\
+Glibc~2.3.3 ist die einzige veröffentlichte Version mit dem Fehler, aber OpenSUSE 9 enthält eine fehlerhafte
+\glqq glibc 2.3.2\grqq{}.
+Das Symptom des Fehlers ist, dass alles beim Start abstürzt und sagt:\\
+\texttt{dl\_main: Assertion \`~(void \*) ph-$>$p\_vaddr == \_rtld\_local.\_dl\_sysinfo\_dso}\\
+Wenn Sie hier Y sagen, wird der Standardwert der Bootoption vdso32 von 1 auf 0 geändert, wodurch die
+32-Bit vDSO vollständig deaktiviert wird. Dies umgeht zwar den Glibc-Bug, beeinträchtigt aber die Leistung.\\
+Wenn Sie unsicher sind, sagen Sie N: Wenn Sie Ihren eigenen Kernel kompilieren, ist es unwahrscheinlich,
+dass Sie eine fehlerhafte Version der glibc verwenden.
 
+\subsubsection{vsyscall table for legacy applications () \texorpdfstring{$\rightarrow$}{->}}
+Legacy-Benutzercode, der nicht weiß, wie er den vDSO finden kann, erwartet, dass er drei Syscalls ausgeben kann,
+indem er feste Adressen im Kernel-Bereich aufruft.
+Da dieser Ort nicht mit ASLR randomisiert wird, kann er dazu verwendet werden, die Ausnutzung von Sicherheitslücken
+zu unterstützen.
+Diese Einstellung kann zur Boot-Zeit über den Kernel-Befehlszeilenparameter
+\texttt{vsyscall=[emulate|xonly|none]} geändert werden.\\
+Der Emulationsmodus ist veraltet und kann nur noch über die Kernel-Befehlszeile aktiviert werden.
+Auf einem System mit ausreichend aktueller glibc (2.14 oder neuer) und ohne statische Binärdateien können Sie
+\glqq None\grqq{} ohne Leistungseinbußen verwenden um die Sicherheit zu verbessern.\\
+Wenn Sie unsicher sind, wählen Sie \glqq Nur Ausführung emulieren\glqq{}.
+
+\paragraph{Emulate execution only}$~$\\
+CONFIG\_LEGACY\_VSYSCALL\_XONLY [=n] \textbf{[N]}\\
+Der Kernel fängt und emuliert Aufrufe in die feste vsyscall-Adresszuordnung und lässt keine Lesezugriffe zu.
+Diese Konfiguration wird empfohlen, wenn der Userspace den Legacy-Vsyscall-Bereich verwenden könnte, aber keine
+Unterstützung für die binäre Instrumentierung von Legacy-Code benötigt wird. Sie entschärft bestimmte Verwendungen
+des vsyscall-Bereichs als Puffer zur Umgehung von ASLR.
+
+\paragraph{None}$~$\\
+CONFIG\_LEGACY\_VSYSCALL\_NONE [=n] \textbf{[N]}\\
+Es wird überhaupt keine vsyscall-Zuordnung geben. Dies eliminiert jegliches Risiko einer ASLR-Umgehung aufgrund
+der festen vsyscall-Adressen-Zuordnung. Versuche, die vsyscalls zu verwenden, werden an dmesg gemeldet, so dass
+entweder alte oder bösartige Userspace-Programme identifiziert werden können.
 
 \end{document}