UPD Disable the 32-bit vDSO

documentation/linux_configuration.tex

@@ -2112,4 +2112,94 @@ CONFIG\_HZ\_1000 [=n] \textbf{[N]}\\
 1000~Hz ist die bevorzugte Wahl für Desktop-Systeme und andere Systeme, die schnelle interaktive
 Reaktionen auf Ereignisse erfordern.
 
+\subsubsection{Physical address where the kernel is loaded}
+CONFIG\_PHYSICAL\_START [=0x1000000] \textbf{[0x1000000]}\\
+Dies gibt die physikalische Adresse an, unter der der Kernel geladen wird. Wenn der Kernel nicht verschiebbar ist
+(CONFIG\_RELOCATABLE=n), dekomprimiert sich bzImage an die oben genannte physikalische Adresse und wird von dort
+aus gestartet. Andernfalls wird bzImage von der Adresse aus gestartet, an der es vom Bootloader geladen wurde,
+und ignoriert die obige physikalische Adresse. In normalen kdump-Fällen muss diese Option nicht gesetzt/geändert
+werden, da bzImage nun als vollständig relozierbares Image (CONFIG\_RELOCATABLE=y) kompiliert und zum Laden und
+Ausführen von einer anderen Adresse verwendet werden kann. Diese Option ist vor allem für die Leute nützlich,
+die kein bzImage für die Erfassung des Crash-Dumps verwenden wollen und stattdessen vmlinux einsetzen wollen.
+vmlinux ist nicht relocatable, daher muss ein Kernel speziell kompiliert werden, um von einem bestimmten
+Speicherbereich (normalerweise ein reservierter Bereich) zu laufen, und diese Option ist sehr nützlich.
+Wenn Sie also bzImage zum Erfassen des Crash-Dumps verwenden, lassen Sie den Wert hier unverändert auf
+0x1000000 und setzen Sie CONFIG\_RELOCATABLE=y.\\
+Andernfalls, wenn Sie vmlinux für die Aufzeichnung des Crash-Dumps verwenden wollen, ändern Sie diesen Wert
+auf den Beginn des reservierten Bereichs. Mit anderen Worten, er kann auf der Grundlage des "X"-Wertes gesetzt
+werden, wie er im "crashkernel=YM@XM"-Befehlszeilen-Boot-Parameter angegeben ist, der an den panic-ed-Kernel
+übergeben wird. Weitere Details zu Crash Dumps finden Sie in Documentation/admin-guide/kdump/kdump.rst.
+Die Verwendung von bzImage für die Aufzeichnung des Crash-Dumps wird empfohlen, da man nicht zwei Kernel
+erstellen muss. Derselbe Kernel kann als Produktionskernel und als Erfassungskernel verwendet werden. Die obige
+Option sollte verschwinden, nachdem die Unterstützung von relocatable bzImage eingeführt wurde. Sie ist aber noch
+vorhanden, weil es Benutzer gibt, die weiterhin vmlinux für die Dump-Erfassung verwenden. Diese Option sollte im
+Laufe der Zeit verschwinden. Ändern Sie diese Option nicht, wenn Sie nicht wissen, was Sie tun.
+
+\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.
+
+\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.
+
+\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.
+
+\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.
+
+\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.
+
+\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.
+
+
 \end{document}