tom/kernel_dell_tom
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

UPD vsyscall table

Browse Source
This commit is contained in:
Thomas Kuschel
2023-12-08 20:35:07 +01:00
parent c6030a2f18
commit 9abcb4e0ab
2 changed files with 86 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

134
documentation/linux_configuration.tex
View File

@@ -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}