Informationen zum monatlichen Bericht zum Linux-Kernel
Linux-Lesefeld
Die monatliche Berichtsspalte zum Linux-Kernel enthält eine Zusammenfassung der wichtigsten First-Line-Entwicklungstrends der Linux-Kernel-Community in diesem Monat, sodass die Leser die aktuellsten Entwicklungstrends des Linux-Kernels leichter nachverfolgen können.
Aus Platzgründen geben wir nur einen groben Überblick über die neueste Technologie. Technische Details finden Sie in den folgenden Artikeln. Leser können auch gerne einen Beitrag zur Community der Lesecodefelder leisten.
Die Hauptverantwortlichen dieses Monatsberichts:
Zhang Jian, Liao Weixiong, Chenwei, Xia
Vorherige Links:
Linux Reading Field - Linux Kernel Monatsbericht (Juni 2020)
Linux Reading Field - Linux Kernel Monatsbericht (Juli 2020)
Linux Reading Field-Linux Kernel Monatsbericht (August 2020)
Linux Reading Field - Linux Kernel Monatsbericht (September 2020)
阅码场征稿Linux阅码场征集Linux工程师一线研发心得；工程师、高校学生老师、科研院所研研究人员对Linux某一技术要点深入分析的稿件。您的文章将获得近十万一线Linux工程师的广泛受众。投稿要求：原创且从未在任何媒体、博客、公众号发表过的文章。高屋建瓴、深刻全面地论述一个技术点或者面。投稿请微信联系小月：linuxer2016录取的稿件，我们也会奉上微薄的稿酬聊表寸心，稿费标准为300-500元/篇。
Erstens, Architektur bezogen
1.1 ARM / arm64 set_fs
补丁 集 1 ： ARM: Entfernen Sie die Aufrufer von set_fs und die Implementierung
Patch-Set 2: arm64: entferne set_fs () und Freunde
Was halten Sie von fs im Kernel-Code? Dateisystem? Das Bild ist jedoch kaputt, das fs, über das wir heute sprechen werden, ist tatsächlich das fs-Register von x86 [1]. Die Version 0.1 des Kernels führte set_fs ein, um den Adressbereich des Benutzerraums (`set_fs (USER_DS)`) und des Kernelraums (`set_fs (KERNEL_DS)`) festzulegen. Ursprünglich setzte set_fs nur das x86-fs-Register, und andere Architekturen folgten ebenfalls dem Namen set_fs. Es ist in Ordnung, wenn nur der Name verwechselt wird. Das Problem ist, dass set_fs genauso zu schützen scheint
Es ist ein Angriffspunkt. Wenn die entsprechende Einschränkung "set_fs (USER_DS)" nicht festgelegt ist, wenn vom Kernel zum Benutzerbereich zurückgekehrt wird, kann der Benutzerbereich unbegrenzten Speicherplatz beanspruchen. Es gab ähnliche Berichte in 2010 (CVE-2010-4258) und 2016.
Das auf set_fs [2] basierende Härten schien ein Weg zu sein, wurde jedoch abgelehnt, da es die Leistung von Kernel-Systemaufrufen beeinträchtigen würde. Daher gibt es nur eine Option: set_fs entfernen. emm, vor drei Jahren war dies das Ergebnis von Community-Diskussionen vor drei Jahren. In diesem Jahr setzte Christoph Hellwig seinen ursprünglichen Vorschlag fort. Derzeit ist der Kerncode-Teil des Kernels fertiggestellt, und die verbleibenden Architekturen müssen geändert werden. In diesem Monat werden die ARM- und ARM64-Architektur-Patches zur Überprüfung eingereicht.
Für ARM64 ist es zusätzlich zum Bereinigungscode erforderlich, sich mit dem Code zu befassen, der die Kernel- und Benutzerbereichsumschaltung umfasst, die hauptsächlich aus drei Teilen besteht: SDEI, PAN und UAO. Für ARM müssen zusätzlich zum Löschen des set_fs-Codes mehrere Systemaufrufe von oabi verarbeitet werden.
参考资料
[1]https://lwn.net/Articles/722267/
[2]https://lwn.net/Articles/721305/1.2 KASan für ARM
Kernel Address SANitizer (KASAN) ist ein dynamischer Speicherfehlerdetektor, der hauptsächlich nach Out-of-Bounds und nachträglicher Verwendung sucht. Derzeit werden X86-, ARM64-, RISC-V-, PowerPC- und andere Architekturen unterstützt.
Linus Walleij hat diesen Monat den vierzehnten Patch von KASan for Arm gesendet - dies ist die Unterstützung der ARM-Architektur für KASan - im Vergleich zum Patch im letzten Monat hat Linus seinen Absturz auf der Qualcomm APQ8060-Plattform repariert. Das hofft er auch Kann von Florian und Ard gemeldete Probleme beheben.
KASan von ARM64 erhöht die Erkennung von Speicherfehlern basierend auf dem Hardware-Tag. Diese Reihe von Patches wendet die Funktionen der Memory Tagging Extension (MTE) auf KASan an, generiert bei jeder Speicherzuweisung ein zufälliges Tag und überprüft es bei jedem Speicherzugriff automatisch. Wenn es nicht übereinstimmt, wird ein Tag-Fehler generiert und KASan meldet den Fehler.
(Patchname: kasan: Hardware-Tag-basierten Modus für arm64 hinzufügen)
1.3 Führen Sie das IMA-Messprotokoll auf kexec auf ARM64 fort
Die Implementierung jeder Architektur des Kernels weist sowohl Gemeinsamkeiten als auch Merkmale auf, und häufig werden Nachzügler eine Änderung der Implementierung einer früheren Architektur als allgemeiner betrachten. Die RISC-VNUMA-Arbeit, die wir im monatlichen Kernel-Bericht vorgestellt haben, basiert auf ARM64. Das heutige Patch-Set ist ähnlich.
IMA (Integrity Measurement Architecture) ist eine der beiden Hauptkomponenten der Kernintegrität. IMA kann die Integrität der Datei überprüfen, wenn sie ausgeführt oder geöffnet wird. Für kexec (kexec unterstützt das Starten eines neuen Kernels vom aktuellen Kernel): IMA kann den Kernel, die Initramfs und die Befehlszeile überprüfen. Die vier Patches von Lakshmi sollen diese Funktion ergänzen, die derzeit von ARM64 nicht unterstützt wird.
1.4 Zusätzlich zu den oben genannten Patches gibt es viele Patches, die es wert sind, im Oktober beachtet zu werden. Z.B
Stellen Sie die TDP-MMU vor
Der Zweck besteht darin, die Hot-Migrationsleistung von virtuellen Speichermaschinen auf TB-Ebene zu verbessern. Die Bedeutung von TDP ist: zweidimensionales Paging. Derzeit wird TDP MMU in Googles 12TiB m2-ultramem-416 VM mit 416 vCPUs verwendet, um die erforderliche Hot-Migration-Leistung bereitzustellen.
Die Motivation für diese Arbeit besteht darin, Seitenfehler in sehr großen virtuellen Maschinen parallel zu verarbeiten. Wenn die VM über Hunderte von vCPUs und TB Speicher verfügt, ist die MMU-Sperre von KVM einer extremen Konkurrenz ausgesetzt, was zu einer Soft-Lockup oder einer großen Verzögerung bei der Verarbeitung von Seitenfehlern im Gastbetriebssystem führt.
Unterstützung für asymmetrische AArch32-Systeme hinzufügen
Der Zweck besteht darin, die aarch32-Anwendung im Benutzerbereich zu verwenden, wenn nur ein Teil der arm64-CPU die aarch32 EL0-Betriebsumgebung unterstützt. Anmerkungen: Die arm64-CPU kann zwei Betriebsumgebungen haben (EE: Ausführungsumgebung), nämlich aarch64 und aarch32.
PKS: Unterstützung für PKS (Protection Keys Supervisor) hinzufügen
Dies ist eine Kernel-Arbeit ähnlich der PKU (User Space Memory Protection Keys). Die erwarteten Verwendungsszenarien sind vertrauenswürdige Schlüssel und PMEM.
2. Core-Kernel-bezogen
2.1 Schlafbare Tracepoints
Die aktuellen Tracer können nicht auf Daten im Benutzermodus zugreifen, da sie keine Seitenfehler behandeln können. Dies ist jedoch manchmal erforderlich.
Diese Reihe von Patches implementiert ein Framework, mit dem Tracer Seitenfehler im Tracepoint-Framework behandeln können, und verschiedene Tracer werden in Zukunft entsprechende Änderungen vornehmen.
2.2 Kernplanung v8
Die Kernplanung ist eine Funktion, mit der vertrauenswürdige Prozesse gleichzeitig auf dem gemeinsam genutzten Ressourcen-CPU ausgeführt werden können. Der Hauptzweck besteht darin, Seitenkanalangriffe auf Kernebene zu eliminieren, ohne die SMT-Funktion zu deaktivieren.
Standardmäßig ändert diese Funktion kein aktuelles Planungsverhalten. Der Benutzer muss entscheiden, welche Aufgaben gleichzeitig im selben Kern ausgeführt werden können. Wenn beispielsweise ein Prozess A ausgeführt wird, sind die Hyperthreads desselben Kerns entweder inaktiv oder können nur Prozesse ausführen, denen der Prozess A vertraut.
2.3 KFENCE v5: Ein Tool zur Erkennung von Speicherfehlern mit geringer Abtastung
Das Hauptmerkmal von KFENCE besteht darin, mit möglichst geringem Leistungsverlust verschiedene Speicherfehler in der Leitung abzutasten. Im Vergleich zu KASAN ist die Genauigkeit von KFENCE nicht so hoch, aber KFENCE hat nur geringe Auswirkungen auf die Leistung und kann in einer großen Anzahl von Produktionsumgebungen eingesetzt werden. Kann auch Speicherfehler erkennen.
Diese Patch-Serie bietet KFENCE-Unterstützung für Arm- und x86-Architekturen.
3. Dateisystem und Blockebene
3.1 Blockieren der Anforderungsfilterung und Blockieren des Geräte-Snapshot-Moduls
* Patch: https://lwn.net/Articles/834867/
* veeamsnap ：
https://github.com/veeam/veeamsnap/
Der Patch-Autor stammt von veeam, einem Unternehmen, das Linux-Backup-Lösungen anbietet. Seit langem wird ein Blockgerätesicherungsdienst in Form eines Kernelbaummoduls (veeamsnap) bereitgestellt. Diese Übermittlung ist ein Versuch, seinen Hauptfunktionsbaustein in den Hauptzweig zusammenzuführen.
Der Patch implementiert zwei Funktionen, blk-filter und blk-snap:
blk-filter implementiert das Abfangen von BIO-Anforderungen für Blockgeräte und fängt die BIO-Anforderungen sehr früh ab, ohne die Anforderungsverarbeitungswarteschlange überhaupt zu beeinflussen. Neben dem Abfangen des gesamten Speichermediums wird auch das Abfangen bestimmter Blockgeräte in Partitionseinheiten unterstützt. Es gibt auch eine Funktion, die das dynamische Aktivieren und Deaktivieren von Filterfunktionen unterstützt. Wenn das Blockgerät geladen ist, kann es automatisch mit dem Filtern der BIO-Anforderung beginnen. Wenn das Blockgerät entfernt wird, wird auch der Filter automatisch entfernt.
blk-snap implementiert Snapshot- und Block Change Tracking-Funktionen. Es besteht kein Zweifel, dass es auf Schwarzfilter beruht. Es wurde entwickelt, um eine Sicherungskopie eines Blockgeräts ohne Verwendung eines Gerätezuordners zu erstellen. Der Snapshot ist vorübergehend und wird nach Abschluss des Sicherungsvorgangs zerstört. Die geänderte Blockverfolgung ermöglicht inkrementelle und differenzielle Sicherungskopien.
3.2 btrfs hat Unterstützung für das Lesen und Schreiben von 4K-Unterseiten hinzugefügt
* Patch: https://lwn.net/Articles/834872/
Der Patch dient hauptsächlich dazu, einem System mit einer Seitengröße von 64 KB das Mounten eines btrfs mit einer Sektorgröße von 4 KB zu ermöglichen und in diesem Zustand normales Lesen und Schreiben zu unterstützen.
Die Seitengröße von 64 KB führt bei einigen kleinen Daten zu einer Verschwendung von internem Speicherplatz. Wenn die Granularität des Vorgangs geringer ist, kann die Speicherplatzverschwendung erheblich verringert werden. Daher ist es notwendig, den Betrieb von 4K-Unterseiten zu unterstützen. Nach dem Testen ist der Autor stabil genug und glaubt, dass reine Metadatenoperationen mit Unterseitengröße ausgeführt werden können, z. B. Reflink. Der Autor überprüfte die Unterseiten der gelesenen Daten unter Komprimierungs- und unkomprimierten Bedingungen, überprüfte das Lesen und Schreiben von Metadaten auf der Unterseite und überprüfte auch das Schreiben ganzer Seiten unter unkomprimierten Bedingungen.
Dieser Patch hat tatsächlich viele Dinge zu tun sowie viele Herausforderungen. Beispielsweise werden die auf die Unterseite geschriebenen Daten (Nicht-Metadaten) nicht implementiert. Beispielsweise unterstützt das Zurückschreiben der Unterseitendaten iomap.
Viertens Virtualisierung
4.1 KVM-geschützte Speichererweiterung
== Hintergrund und verwandte Themen ==
Es gibt viele Hardwarefunktionen (wie MKTME, SEV), die verhindern können, dass auf den Speicher der virtuellen Maschine durch nicht autorisierten Zugriff auf den Host zugegriffen wird. Dieses Patch-Set bietet eine reine Softwarefunktion, mit der einige der gleichen schreibgeschützten Host-Angriffe gemindert werden können.
== Was hat dieses Patch-Set gelindert? ==
-Der Host-Kernel greift "versehentlich" auf die Daten der virtuellen Maschine zu (berücksichtigen Sie die Spekulation)
-Hostkernel bewirkt den Zugriff auf Daten der virtuellen Maschine (write (fd & guest_data_ptr, len))
-Host-Benutzerbereich für den Zugriff auf Daten virtueller Maschinen (z. B. durch manipulierte QEMU)
-Erhöhen Sie die Berechtigungen der virtuellen Maschine durch den manipulierten QEMU-Gerätesimulator
== Was lindert dieses Patch-Set nicht? ==
-Der Kernel des Hosts ist vollständig manipuliert. Der Kernel ordnet die Seite erneut zu
-Hardware-basierte Angriffe
Die zweite Ausgabe des RFC-Patch-Sets befasst sich mit den meisten Rückmeldungen.
Aber immer noch keine gute Lösung gefunden, um den Neustart und KEXEC zu lösen. Bei diesen Vorgängen muss der Schutz des gesamten Speichers aufgehoben werden, was nicht mit unserem Ziel dieser Funktion vereinbar ist.
Bevor Sie die für den Neustart (oder KEXEC) erforderlichen Daten nicht schützen, ist die Bereinigung des größten Teils des Speichers zeitaufwändig und fehleranfällig. Vielleicht sollten wir erklären, dass diese Operationen nicht unterstützt werden?
== Sequenzübersicht ==
Verschlüsseln Sie die Daten der virtuellen Maschine mithilfe von Hardwarefunktionen und stellen Sie dann sicher, dass nur die richtige virtuelle Maschine sie entschlüsseln kann, wodurch die Daten der virtuellen Maschine geschützt werden. Der Nebeneffekt davon ist, dass die direkte Kernelzuordnung und die Benutzerbereichszuordnung (von QEMU usw. verwendet) unbrauchbar werden.
Dies enthält jedoch einige sehr nützliche Informationen: Für den normalen Betrieb virtueller Maschinen sind Kernel-Mapping und User Space Mapping manchmal nicht wirklich erforderlich.
In unserem Patch-Set verwenden wir keine Verschlüsselung, sondern entfernen einfach die Zuordnung des Speichers. Im Vergleich zum Zulassen des Zugriffs auf Chiffretext besteht einer der Vorteile darin, dass ein falscher Zugriff Ausnahmen verursacht und abgefangen wird, anstatt einfach Mülldaten wie verschlüsselte Daten zurückzugeben.
4.2 KVM: Dirty Ring-Schnittstelle
Der Patch wurde im Oktober zweimal aktualisiert, wobei beide v15 auf den neuesten KVM-Zweig zurückgesetzt wurden. Diese Arbeit ist eine Fortsetzung der KVM-Dirty-Ring-Schnittstellenarbeit von Lei Cao <[email protected]> und Paolo Bonzini.
Diese neue Dirty-Ring-Schnittstelle ist eine weitere Möglichkeit für virtuelle Maschinen, Dirty-Pages zurückzugewinnen. In vielerlei Hinsicht unterscheidet es sich von der vorhandenen Dirty-Logging-Schnittstelle, hauptsächlich:
Datenformat: Schmutzige Daten haben jetzt das Ringformat anstelle des Bitmap-Formats. Das zum Synchronisieren des fehlerhaften Datenprotokolls verwendete Bit hängt also nicht mehr von der Größe des Speichers der virtuellen Maschine ab, sondern von der Geschwindigkeit der fehlerhaften Daten. Darüber hinaus ist der neue Dirty-Ring exklusiv für jede vCPU, während die Dirty-Bitmap von allen vCPUs gemeinsam genutzt wird und die Dirty-Bitmap pro VM erfolgt.
Datenkopie: Bei der Synchronisierung von Dirty Pages müssen keine Daten mehr kopiert werden. Im Gegenteil, Dirty Ring wird durch Seitenfreigabe (über mmap auf vcpu_fd) zwischen User Space und Kernel Space geteilt.
Schnittstelle: Wenn wir die gesammelten Dirty Pages wieder in den Schutzmodus zurücksetzen möchten, verwendet der neue Dirty Ring die neue KVM_RESET_DIRTY_RINGS ioctl-Schnittstelle anstelle der ursprünglichen KVM_GET_DIRTY_LOG-, KVM_CLEAR_DIRTY_LOG-Schnittstelle. Um schmutzige Bits zu sammeln, müssen wir nur die Daten im schmutzigen Ring lesen und die ioctl-Schnittstelle nicht mehr aufrufen.
(ENDE)
更多精彩，尽在"Linux阅码场"，扫描下方二维码关注