UPD Hibernation
This commit is contained in:
Binary file not shown.
@@ -1015,7 +1015,7 @@ Sagen Sie N, wenn Sie unsicher sind.
|
||||
CONFIG\_CGROUP\_BPF [=y] \textbf{[Y]}\\
|
||||
Erlaubt das Anhängen von eBPF-Programmen an eine cgroup mit dem
|
||||
bpf(2)-Syscall-Befehl\\
|
||||
texttt{BPF\_PROG\_ATTACH}.\\
|
||||
\texttt{BPF\_PROG\_ATTACH}.\\
|
||||
In welchem Kontext auf diese Programme zugegriffen wird, hängt von der Art des Attachments ab.
|
||||
Zum Beispiel werden Programme, die mit BPF\_CGROUP\_INET\_INGRESS angehängt werden,
|
||||
auf dem Ingress-Pfad von inet-Sockets ausgeführt.
|
||||
@@ -1369,9 +1369,9 @@ Wenn Sie unsicher sind, sagen Sie Y.
|
||||
|
||||
\subparagraph{Specify the maximum number of memory regions for the elfcorehdr}$~$\\
|
||||
CONFIG\_CRASH\_MAX\_MEMORY\_RANGES [=8192] \textbf{[8192]}\\
|
||||
Für den Pfad des Systemaufrufs texttt{kexec\_file\_load()} ist die maximale Anzahl
|
||||
Für den Pfad des Systemaufrufs \texttt{kexec\_file\_load()} ist die maximale Anzahl
|
||||
der Speicherbereiche anzugeben, die der elfcorehdr-Puffer/das elfcorehdr-Segment aufnehmen kann.
|
||||
Diese Regionen werden über texttt{walk\_system\_ram\_res()} ermittelt, z.B. die
|
||||
Diese Regionen werden über \texttt{walk\_system\_ram\_res()} ermittelt, z.B. die
|
||||
'System RAM'-Einträge in /proc/iomem. Dieser Wert wird mit NR\_CPUS\_DEFAULT kombiniert und mit
|
||||
\texttt{sizeof(Elf64\_Phdr)} multipliziert, um die endgültige elfcorehdr-Speicherpuffer-/Segmentgröße
|
||||
zu bestimmen. Der Wert 8192 beispielsweise deckt ein (dünn besiedeltes) 1TiB-System ab,
|
||||
@@ -2240,4 +2240,152 @@ Es wird überhaupt keine vsyscall-Zuordnung geben. Dies eliminiert jegliches Ris
|
||||
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.
|
||||
|
||||
\subsubsection{Built-in kernel command line}
|
||||
CONFIG\_CMDLINE\_BOOL [=n] \textbf{[N]}\\
|
||||
Ermöglicht die Angabe von Boot-Argumenten für den Kernel zur Erstellungszeit. Auf einigen Systemen
|
||||
(z.B. eingebetteten [embedded]) ist es notwendig oder praktisch, einige oder alle Kernel-Boot-Argumente mit
|
||||
dem Kernel selbst bereitzustellen (d.h. sich nicht darauf zu verlassen, dass der Bootloader sie bereitstellt).
|
||||
Um Kommandozeilenargumente in den Kernel zu kompilieren, setzen Sie diese Option auf Y und geben Sie dann
|
||||
die Boot-Argumente in CONFIG\_CMDLINE ein. Bei Systemen mit voll funktionsfähigen Bootloadern
|
||||
(d.h. nicht eingebetteten) sollte diese Option auf N gesetzt bleiben.
|
||||
|
||||
\subsubsection{Enforce strict size checking for sigaltstack}
|
||||
CONFIG\_STRICT\_SIGALTSTACK\_SIZE [=n] \textbf{[N]}\\
|
||||
Aus historischen Gründen ist MINSIGSTKSZ eine Konstante, die mit der AVX512-Unterstützung bereits zu klein wurde.
|
||||
Fügen Sie einen Mechanismus hinzu, um die strenge Überprüfung der Sigaltstack-Größe gegen die tatsächliche Größe
|
||||
des FPU-Rahmens zu erzwingen. Diese Option aktiviert die Überprüfung standardmäßig. Sie kann auch über die
|
||||
Kernel-Kommandozeilenoption \texttt{strict\_sas\_size} unabhängig von diesem Konfigurationsschalter gesteuert werden.
|
||||
Das Aktivieren dieser Option könnte bestehende Anwendungen zerstören, die einen zu kleinen Sigaltstack zuweisen,
|
||||
aber \glq funktionieren\grq{}, weil sie nie ein Signal geliefert bekommen.\\
|
||||
Sagen Sie N, wenn Sie diese Prüfung nicht wirklich erzwingen wollen.
|
||||
|
||||
\subsubsection{Kernel Live Patching}
|
||||
CONFIG\_LIVEPATCH [=n] \textbf{[N]}\\
|
||||
Geben Sie hier Y an, wenn Sie Kernel-Live-Patching unterstützen wollen. Diese Option hat keine Auswirkungen auf die
|
||||
Laufzeit, bis ein Kernel-\glqq Patch\grqq{}-Modul die von dieser Option bereitgestellte Schnittstelle verwendet,
|
||||
um einen Patch zu registrieren, was dazu führt, dass Aufrufe der gepatchten Funktionen auf den neuen Funktionscode
|
||||
im Patch-Modul umgeleitet werden.
|
||||
|
||||
\section{Mitigations for speculative execution vulnerabilities \texorpdfstring{$\rightarrow$}{->}}
|
||||
CONFIG\_SPECULATION\_MITIGATIONS [=y] \textbf{[Y]}\\
|
||||
Sagen Sie hier Y, um Optionen zu aktivieren, die Abhilfemaßnahmen für Hardware-Schwachstellen durch spekulative
|
||||
Ausführung ermöglichen. Wenn Sie N sagen, werden alle Abhilfemaßnahmen deaktiviert. Sie sollten wirklich wissen,
|
||||
was Sie tun, um dies anzugeben.
|
||||
|
||||
\subsection{Remove the kernel mapping in user mode}
|
||||
CONFIG\_PAGE\_TABLE\_ISOLATION [=y] \textbf{[Y]}\\
|
||||
Diese Funktion reduziert die Anzahl der Hardware-Seitenkanäle, indem sie sicherstellt, dass die meisten
|
||||
Kernel-Adressen nicht in den Benutzerraum abgebildet werden. Siehe Documentation/arch/x86/pti.rst für
|
||||
weitere Details.
|
||||
|
||||
\subsection{Avoid speculative indirect branches in kernel}
|
||||
CONFIG\_RETPOLINE [=y] \textbf{[Y]}\\
|
||||
Kompilieren Sie den Kernel mit den retpoline Compiler-Optionen, um Datenlecks zwischen Kernel und Benutzer
|
||||
zu verhindern, indem spekulative indirekte Verzweigungen vermieden werden. Erfordert einen Compiler mit
|
||||
\texttt{-mindirect-branch=thunk-extern} Unterstützung für vollen Schutz. Der Kernel kann langsamer laufen.
|
||||
|
||||
\subsubsection{Enable return-thunks}
|
||||
CONFIG\_RETHUNK [=y] \textbf{[Y]}\\
|
||||
Kompiliere den Kernel mit der Compileroption return-thunks, um Datenlecks zwischen Kernel und Benutzer zu
|
||||
verhindern, indem Rückgabespekulationen vermieden werden. Erfordert einen Compiler mit
|
||||
\texttt{-mfunction-return=thunk-extern} Unterstützung für vollen Schutz. Der Kernel kann langsamer laufen.
|
||||
|
||||
\paragraph{Enable UNRET on kernel entry}$~$\\
|
||||
CONFIG\_CPU\_UNRET\_ENTRY [=y] \textbf{[Y]}\\
|
||||
Kompiliere den Kernel mit Unterstützung für die \texttt{retbleed=unret}-Abschwächung.
|
||||
|
||||
\subsection{Mitigate RSB underflow with call depth tracking}
|
||||
CONFIG\_CALL\_DEPTH\_TRACKING [=y] \textbf{[Y]}\\
|
||||
Kompiliere den Kernel mit Call-Depth-Tracking, um das Intel SKL Return-Speculation-Buffer (RSB) Underflow-Problem
|
||||
zu entschärfen. Die Entschärfung ist standardmäßig ausgeschaltet und muss in der Kernel-Befehlszeile über die
|
||||
Option \texttt{retbleed=stuff} aktiviert werden. Für nicht betroffene Systeme ist der Overhead dieser Option
|
||||
marginal, da die Verfolgung der Aufruftiefe zur Laufzeit generierte Call Thunks in einem vom Compiler generierten
|
||||
Padding-Bereich und Call Patching verwendet. Dies erhöht die Textgröße um $\sim 5$\%. Bei nicht betroffenen Systemen
|
||||
ist dieser Platz ungenutzt. Auf betroffenen SKL-Systemen führt dies zu einem erheblichen Leistungsgewinn gegenüber
|
||||
der IBRS-Abschwächung.
|
||||
|
||||
\subsubsection{Enable call thunks and call depth tracking debugging}
|
||||
CONFIG\_CALL\_THUNKS\_DEBUG [=n] \textbf{[N]}\\
|
||||
Aktiviere Call/Ret-Zähler zur Erkennung von Ungleichgewichten und baue ein lautes dmesg über die Erzeugung von
|
||||
Callthunks und Call-Patching zur Fehlersuche ein. Die Debug-Ausdrucke müssen in der Kernel-Befehlszeile mit
|
||||
\texttt{debug-callthunks} aktiviert werden. Aktivieren Sie dies nur, wenn Sie Call Thunks debuggen wollen,
|
||||
da dies einen spürbaren Laufzeit-Overhead erzeugt. Wenn Sie unsicher sind, sagen Sie N.
|
||||
|
||||
\subsection{Enable IBPB on kernel entry}
|
||||
CONFIG\_CPU\_IBPB\_ENTRY [=y] \textbf{[Y]}\\
|
||||
Kompiliere den Kernel mit Unterstützung für die \texttt{retbleed=ibpb}-Abschwächung.
|
||||
|
||||
\subsection{Enable IBRS on kernel entry}
|
||||
CONFIG\_CPU\_IBRS\_ENTRY [=y] \textbf{[Y]}\\
|
||||
Kompiliere den Kernel mit Unterstützung für die \texttt{spectre\_v2=ibrs}-Abschwächung.
|
||||
Dadurch werden sowohl spectre\_v2 als auch retbleed auf Kosten der Leistung abgeschwächt.
|
||||
|
||||
\subsection{Mitigate speculative RAS overflow on AMD}
|
||||
CONFIG\_CPU\_SRSO [=y] \textbf{[N]}\\
|
||||
Aktiviert die SRSO-Abschwächung, die auf AMD Zen1-4-Maschinen benötigt wird.
|
||||
|
||||
\subsection{Mitigate Straight-Line-Speculation}
|
||||
CONFIG\_SLS [=y] \textbf{[Y]}\\
|
||||
Kompiliere den Kernel mit Straight-Line-Speculation-Optionen, um ihn vor Straight-Line-Speculation zu
|
||||
schützen. Das Kernel-Image könnte etwas größer sein.
|
||||
|
||||
\subsection{Force GDS Mitigation}
|
||||
CONFIG\_GDS\_FORCE\_MITIGATION [=n] \textbf{[N]}\\
|
||||
Gather Data Sampling (GDS) ist eine Hardware-Schwachstelle, die unberechtigten spekulativen Zugriff auf
|
||||
Daten ermöglicht, die zuvor in Vektorregistern gespeichert wurden. Diese Option ist gleichbedeutend mit
|
||||
der Einstellung \texttt{gather\_data\_sampling=force} in der Befehlszeile. Die Mikrocode-Abschwächung
|
||||
wird verwendet, falls vorhanden, andernfalls wird AVX als Abschwächung deaktiviert. Auf betroffenen
|
||||
Systemen, denen der Microcode fehlt, wird jeder Userspace-Code, der AVX bedingungslos verwendet, bei
|
||||
gesetzter Option abbrechen. Das Setzen dieser Option auf Systemen, die nicht für GDS anfällig sind, hat
|
||||
keine Auswirkungen.\\
|
||||
Im Zweifelsfall sagen Sie N.
|
||||
|
||||
\section{Power management and ACPI options \texorpdfstring{$\rightarrow$}{->}}
|
||||
Energieverwaltung und ACPI-Optionen
|
||||
|
||||
\subsection{Suspend to RAM and standby}
|
||||
CONFIG\_SUSPEND [=y] \textbf{[Y]}\\
|
||||
Ermöglicht dem System, in Ruhezustände einzutreten, in denen der Hauptspeicher mit Strom versorgt wird und
|
||||
somit sein Inhalt erhalten bleibt, wie z. B. der Suspend-to-RAM-Zustand (z. B. der ACPI S3-Zustand).
|
||||
|
||||
\subsection{Hibernation (aka `suspend to disk')}
|
||||
CONFIG\_HIBERNATION [=y] \textbf{[Y]}\\
|
||||
Aktiviert die Funktion \glqq Suspend to Disk\grqq{} (STD),
|
||||
die in den Benutzeroberflächen gewöhnlich als \glqq Ruhezustand\grqq{}
|
||||
bezeichnet wird. STD setzt das System an einen Haltepunkt und schaltet es aus; beim Neustart wird dieser Haltepunkt
|
||||
wiederhergestellt. Sie können Ihren Rechner mit \texttt{echo disk > /sys/power/state} in den Ruhezustand versetzen,
|
||||
nachdem Sie \texttt{resume=/dev/swappartition} in der Kernel-Befehlszeile in der Konfigurationsdatei Ihres Bootloaders
|
||||
angegeben haben. Alternativ können Sie auch die zusätzlichen Userland-Tools verwenden, die unter
|
||||
\url{http://suspend.sf.net} verfügbar sind. Im Prinzip sind weder ACPI noch APM erforderlich, obwohl beispielsweise
|
||||
ACPI für die letzten Schritte verwendet wird, wenn es verfügbar ist. Einer der Gründe für die Verwendung von
|
||||
Software-Suspend ist, dass die Firmware-Hooks für Suspend-Zustände wie Suspend-to-RAM (STR) oft nicht sehr gut mit
|
||||
Linux funktionieren. Es wird ein Abbild erstellt, das in der aktiven Auslagerungsdatei gespeichert wird.
|
||||
Beim nächsten Start übergeben Sie dem Kernel das Argument \texttt{resume=/dev/swappartition}, damit er das gespeicherte
|
||||
Abbild erkennt, den Speicherstatus daraus wiederherstellt und wie zuvor weiterarbeitet.
|
||||
Wenn Sie nicht wollen, dass der vorherige Zustand wiederhergestellt wird, verwenden Sie das Kernel-Befehlszeilenargument
|
||||
\texttt{noresume}. Beachten Sie jedoch, dass fsck auf Ihren Dateisystemen ausgeführt wird und Sie mkswap auf der
|
||||
Swap-Partition ausführen müssen, die für den Suspend verwendet wird. In begrenztem Umfang funktioniert es auch mit
|
||||
Swap-Dateien (für Details siehe $<$file:Documentation/power/swsusp-and-swap-files.rst$>$).
|
||||
Sie können jetzt booten, ohne den Vorgang fortzusetzen, und ihn später fortsetzen, aber in der Zwischenzeit können Sie
|
||||
die Swap-Partition(en)/Datei(en), die am Suspendieren beteiligt waren, nicht verwenden. In diesem Fall dürfen Sie auch
|
||||
nicht die Dateisysteme verwenden, die vor dem Suspendieren gemountet waren. Insbesondere dürfen Sie keine
|
||||
journalisierten Dateisysteme mounten, die vor dem Suspending gemountet wurden, da diese sonst auf unschöne Weise
|
||||
beschädigt werden. Weitere Informationen finden Sie in $<$file:Documentation/power/swsusp.rst$>$.
|
||||
|
||||
\subsubsection{Userspace snapshot device}
|
||||
CONFIG\_HIBERNATION\_SNAPSHOT\_DEV [=y] \textbf{[Y]}\\
|
||||
Gerät, das von den uswsusp-Werkzeugen verwendet wird. Sagen Sie N, wenn kein Snapshotting aus dem Userspace benötigt
|
||||
wird, dies reduziert auch die Angriffsfläche des Kernels. Im Zweifelsfall sagen Sie Y.
|
||||
|
||||
\subsubsection{Default resume partition}
|
||||
CONFIG\_PM\_STD\_PARTITION [=] \textbf{[~]}\\
|
||||
Die Standard-Wiederaufnahmepartition ist die Partition, auf der die Suspend-to-Disk-Implementierung nach einem
|
||||
Suspend-Disk-Image suchen wird. Die hier angegebene Partition wird für fast jeden Benutzer anders sein. Es sollte eine
|
||||
gültige Swap-Partition sein (zumindest im Moment), die vor dem Suspendieren eingeschaltet wird. Die angegebene
|
||||
Partition kann durch die Angabe von:\\
|
||||
\texttt{resume=/dev/<anderes Gerät>}\\
|
||||
überschrieben werden, wodurch die Partition für die Wiederaufnahme auf das angegebene Gerät gesetzt wird.
|
||||
Beachten Sie, dass es derzeit keine Möglichkeit gibt, das Gerät anzugeben, auf dem das suspendierte Image
|
||||
gespeichert werden soll. Es wird einfach das erste verfügbare Swap-Gerät ausgewählt.
|
||||
|
||||
\end{document}
|
||||
|
||||
Reference in New Issue
Block a user