Kernel page-table isolation

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von KAISER)
Zur Navigation springen Zur Suche springen
Auftrennung von einem gemeinsamen Benutzer- und Kernelspeicher in zwei getrennte Seitentabellen. Der Benutzerspeicher enthält neben einer Kopie der Benutzerdaten nur noch einen minimalen Satz von Systemaufrufen in die getrennte Seitentabelle mit dem Kernel

Kernel page-table isolation (kurz KPTI, vormals KAISER)[1] ist ein Workaround für die Meltdown genannte Sicherheitslücke in den x86-Prozessoren von Intel. Dies wird durch eine Trennung zwischen Benutzerspeicher und Kernelspeicher erreicht.[2][3] KPTI wurde in den Linux-Kernel 4.15 integriert,[4] der für Anfang 2018 erwartet wird, und außerdem auf den Linux-Kernel 4.4.110, 4.9.75 und 4.14.11 zurückportiert.[5][6][7] Für Windows und macOS[8] gibt es ähnliche Updates. KPTI schützt nicht vor der Sicherheitslücke Spectre.[9]

Hintergrund zu KAISER

[Bearbeiten | Quelltext bearbeiten]

2014 wurde bei Linux Kernel Address Space Layout Randomization (KASLR) eingeführt,[10] der durch das Verstecken der Kerneladressen vor dem Benutzerspeicher die Ausnutzung anderer Schwachstellen im Kernel erschwert.[11] Trotz der Zugangsverhinderung zu diesen Speicherzuordnungen zum Kernel hat sich die Verwundbarkeit durch einige Seitenkanalattacken bei modernen Prozessoren herausgestellt. Dadurch lässt sich die Adresse des Speichers ausspähen, was eine Umgehung von KASLR bedeutet.[3][12][13][14]

KAISER steht für „Kernel Address Isolation to have Side-channels Efficiently Removed“ und wurde im Juni 2017 veröffentlicht, als Meltdown noch nicht bekannt war. KAISER verbessert KASLR noch weiter. Während KASLR lediglich die Kerneladressen versteckt, verhindert KAISER zusätzlich das Ausspähen von Speicherinhalten des Kernels, und deckt damit die Meltdown-Sicherheitslücke ab.[15]

Meltdown und KPTI

[Bearbeiten | Quelltext bearbeiten]

Im Januar 2018 wurde die Sicherheitslücke Meltdown veröffentlicht, die hauptsächlich Intel-x86-Prozessoren betrifft.[9] Forscher hatten im Sommer herausgefunden, dass auch der Speicherinhalt des Kernelspeichers ausgespäht werden kann, nicht nur die Speicherzuordnungen, wie ursprünglich gedacht. Daraufhin wurden die KAISER-Patches zur Behebung dieses Fehlers umgewidmet (und zu KPTI umbenannt).

AMD-x86-Prozessoren sind nicht von Meltdown betroffen und benötigen daher auch keinen Workaround.[9][16] Allerdings sind AMD-Prozessoren dennoch anfällig für die Umgehung von KASLR,[14] falls KPTI nicht aktiv ist.

KPTI basiert auf KAISER. Ohne aktive KPTI würde Linux bei jeder Ausführung von Code im Benutzerspeicher (Anwendungen) auch seinen gesamten Kernelspeicher in Seitentabellen verwalten, wenngleich zugriffsgeschützt. Der Vorteil hierbei ist die ständige Verfügbarkeit der Seitentabellen, falls eine Anwendung einen Kernel-Systemaufruf macht oder ein Interrupt ausgelöst wird. Hierdurch kann ein durch Kontextwechsel entstehender Overhead (Leerung des Übersetzungspuffers, Seitentabellen-Swapping usw.) meist vermieden werden.[2]

KPTI behebt die Möglichkeit der Ausspähung durch die vollständige Trennung der Seitentabellen des Benutzer- und Kernelbereichs. Auf Prozessoren, die PCID (process-context identifiers) unterstützen, kann ein Leeren des Übersetzungspuffers vermieden werden,[2] aber auch dann kommt es zu signifikanten Leistungseinbußen, insbesondere bei häufigen Systemaufrufen oder Interrupts.

Der Overhead wurde von den damaligen KAISER-Entwicklern mit 0,28 % bemessen;[3] ein Linux-Entwickler bemaß ihn mit etwa 5 % für die meisten Anwendungsfälle und bis zu 30 % in manchen Fällen, trotz der PCID-Optimierung;[2] für das Datenbankmanagementsystem PostgreSQL waren die Auswirkungen bei Nur-Lese-Tests auf einem Intel-Skylake-Prozessor 7–17 % (oder 16–23 % ohne PCID),[17] während ein voller Benchmark 13–19 % verlor (Coffee Lake vs. Broadwell-E).[18] Redis wurde um 6–7 % verlangsamt.[18]

Unter Betriebssystemen wie Linux kann durch einen Kernel-Parameter im Bootmanager festgelegt werden, ob KPTI aktiviert werden soll oder nicht. Bei manchen Kernel-Version ist dies auch während des Betriebs möglich.[19] Damit können die Auswirkungen durch die Leistungsreduktion im eigenen Anwendungsbereich und Hardware selbst bestimmt und bewertet und je nach Situation entschieden werden, ob KPTI angewendet werden soll oder nicht.

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. Jonathan Corbet: The current state of kernel page-table isolation. In: LWN.net. 20. Dezember 2017, abgerufen am 5. Februar 2021.
  2. a b c d Jonathan Corbet: KAISER: hiding the kernel from user space. In: LWN.net. 15. November 2017, abgerufen am 5. Februar 2021.
  3. a b c Daniel Gruss, Moritz Lipp, Michael Lipp, Richard Fellner, Clémentine Maurice, Stefan Mangard: KASLR is Dead: Long Live KASLR. Engineering Secure Software and Systems 2017. 24. Juni 2017 (englisch, gruss.cc [PDF]).
  4. Jonathan Corbet: Kernel page-table isolation merged. In: LWN.net. 20. Dezember 2017, abgerufen am 5. Februar 2021.
  5. Linux 4.4.110 Changelog. 5. Januar 2018;.
  6. Greg Kroah-Hartman: Linux 4.9.75 Changelog. In: kernel.org. 5. Januar 2018;.
  7. Greg Kroah-Hartman: Linux 4.14.11 Changelog. In: kernel.org.
  8. Apple has already partially implemented fix in macOS for 'KPTI' Intel CPU security flaw. In: AppleInsider. Abgerufen am 3. Januar 2018 (amerikanisches Englisch).
  9. a b c Devin Coldewey: Kernel panic! What are Meltdown and Spectre, the bugs affecting nearly every computer and device? In: TechCrunch. 4. Januar 2018, abgerufen am 5. Februar 2021 (englisch).
  10. Linux kernel 3.14, Section 1.7. Kernel address space randomization. In: kernelnewbies.org. 30. März 2014, abgerufen am 2. April 2014.
  11. Abhishek Bhattacharjee, Daniel Lustig: Architectural and Operating System Support for Virtual Memory. Morgan & Claypool Publishers, 2017, ISBN 978-1-62705-933-6, S. 56 (englisch, Google Books).
  12. Yeongjin Jang, Sangho Lee, Taesoo Kim: Breaking Kernel Address Space Layout Randomization with Intel TSX. ACM, New York, NY, USA 2016, ISBN 978-1-4503-4139-4, S. 380–392, doi:10.1145/2976749.2978321 (Online [PDF]).
  13. Daniel Gruss, Clémentine Maurice, Anders Fogh, Moritz Lipp, Stefan Mangard: Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR. ACM, New York, NY, USA 2016, ISBN 978-1-4503-4139-4, S. 368–379, doi:10.1145/2976749.2978356 (Online [PDF]).
  14. a b R. Hund, C. Willems, T. Holz: Practical Timing Side Channel Attacks against Kernel Space ASLR. Mai 2013, S. 191–205, doi:10.1109/sp.2013.23 (Online [PDF]).
  15. Meltdown.
  16. An Update on AMD Processor Security. In: AMD. 4. Januar 2018, abgerufen am 5. Februar 2021.
  17. Andres Freund: heads up: Fix for intel hardware bug will lead to performance regressions. In: PostgreSQL development mailing list (pgsql-hackers). 2. Januar 2018;.
  18. a b Michael Larabel: Initial Benchmarks Of The Performance Impact Resulting From Linux's x86 Security Changes. In: Phoronix. 2. Januar 2018;.
  19. Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753. Abgerufen am 13. Januar 2018.