| View previous topic :: View next topic |
| Author |
Message |
Erdie
Advocate
Joined: 20 May 2004
Posts: 2588
Location: Heidelberg - Germany
|
 Posted: Thu May 09, 2024 12:28 pm Post subject: CPU Mitigations - herausfinden welche relevant sind |
 |
|
Mit Kernel 6.6.30 wurde der Bereich Mitigations nochmal überarbeitet. Da irgendwo erwähnt wurde, dass es auch Browser Exploids gibt, sind wohl auch Single User System, so wie meiner, gefährdet und ich habe alles, was oldconfig empfohlen hat, enabled.
Da ich mir vorstellen kann, dass je nach Prozessor nicht alle Mitigations notwendig sind, versuche ich herauszufinden, welche für meinen AMD Ryzen 9 5900X gelten. Bisher habe ich das noch nicht sicher herausfinden können. Sind dazu jemanden gute Quellen bekannt? Mein Ziel ist es zu wissen welche konkrete Kernel Option unter dem Mitigations - Hauptpunkt überhaupt gewählt werden sollte.
Grüße
Erdie
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
 |
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5215
|
| Posted: Thu May 09, 2024 1:03 pm Post subject: |
|
|
Nicht relevante Mitigations sind auch nicht aktiv.
Daher ist es auch egal ob sie in der kernel konfiguration aktiv sind oder nicht.
die ausgabe von lscpu hat einen bereich "Vulnerabilities" dort werden alle vom kernel bekannten mitigations aufgelistet und ob das system davon betroffen ist oder nicht.
EDIT: der kernel selbst hat eine dokumentation über alle bekannten cpu bugs: (gefunden via "linux kernel list mitigations")
https://docs.kernel.org/admin-guide/hw-vuln/index.html
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2588
Location: Heidelberg - Germany
|
| Posted: Thu May 09, 2024 7:13 pm Post subject: |
|
|
Ich habe beide Versionen mit geekbench verglichen: Einmal mit und einmal ohne Mitigations. Der Unterschied im Ergebnis war marginal. Allerdings ist der Kernel mit aktiven Mitigations signifikant größer. Ich mußte beim Wechsel tatsächlich einen alten Kern löschen damit ich den aktuellen updaten kann. Auf meine Boot Partition paßten bisher 3 Versionen, jetzt nur noch 2. Ich hatte mich bisher davor gedrückt, das Partitionsschema zu ändern. Sie ist so klein, weil die Systeminstallation ungefähr 15 Jahre her ist und ich damals in einem Anfall geistiger Umnachtung diesen Fehler gemacht hatte.
Aber wenn die nicht relevanten Mitigations ohnehin inaktiv sind, ist das Problem ja nicht so dringend. Danke für den Hinweis.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2588
Location: Heidelberg - Germany
|
| Posted: Fri May 10, 2024 9:02 am Post subject: |
|
|
lscpu zeigt folgende vulnerabilites an:
| Code: |
Schwachstellen:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Vulnerable: Safe RET, no microcode
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP always-on; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected - vulnerable module loaded
Srbds: Not affected
Tsx async abort: Not affected
|
Die Mitigations im Kern sehen folgendermaßen aus:
| Code: |
[*] Remove the kernel mapping in user mode │ │
│ │ [*] Avoid speculative indirect branches in kernel │ │
│ │ [*] Enable return-thunks │ │
│ │ [*] Enable UNRET on kernel entry │ │
│ │ [*] Mitigate RSB underflow with call depth tracking │ │
│ │ [ ] Enable call thunks and call depth tracking debugging │ │
│ │ [*] Enable IBPB on kernel entry │ │
│ │ [*] Enable IBRS on kernel entry │ │
│ │ [*] Mitigate speculative RAS overflow on AMD │ │
│ │ [ ] Mitigate Straight-Line-Speculation │ │
│ │ [ ] Force GDS Mitigation │ │
│ │ [*] RFDS Mitigation │ │
│ │ [*] Mitigate Spectre-BHB (Branch History Injection) |
Ich finde es schwierig das aufeinaner zu mappen bzw.zu erkennen welche Option oben problemlos deaktiviert werden könnte.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
|
Christian99
Veteran
Joined: 28 May 2009
Posts: 1673
|
| Posted: Sat May 11, 2024 3:14 pm Post subject: |
|
|
| Erdie wrote: | Ich habe beide Versionen mit geekbench verglichen: Einmal mit und einmal ohne Mitigations. Der Unterschied im Ergebnis war marginal. Allerdings ist der Kernel mit aktiven Mitigations signifikant größer. Ich mußte beim Wechsel tatsächlich einen alten Kern löschen damit ich den aktuellen updaten kann. Auf meine Boot Partition paßten bisher 3 Versionen, jetzt nur noch 2. Ich hatte mich bisher davor gedrückt, das Partitionsschema zu ändern. Sie ist so klein, weil die Systeminstallation ungefähr 15 Jahre her ist und ich damals in einem Anfall geistiger Umnachtung diesen Fehler gemacht hatte.
Aber wenn die nicht relevanten Mitigations ohnehin inaktiv sind, ist das Problem ja nicht so dringend. Danke für den Hinweis. |
wenn die /boot partition so klein ist, musst du nicht das ganze partitions schema ändern, dann kannst du die boot partition einfach ignorieren/nicht nutzen.
1. /boot unmounten und die partition irgendwo anders mounten (z.b. /tmp/boot)
2. kernel und initrds von der alten partition nach Verzeichnis /boot kopieren
3. bootloader neu installieren (grub-install und grub-mkconfig für grub)
4. eintrag in der /etc/fstab für /boot entfernen |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2588
Location: Heidelberg - Germany
|
| Posted: Sat May 11, 2024 5:49 pm Post subject: |
|
|
Super danke, das werde ich mir merken! Anmerkung: Gilt das auch für legacy boot? Ich nutze noch DOS Partitionen.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5215
|
| Posted: Sun May 12, 2024 4:17 am Post subject: |
|
|
| Erdie wrote: | | Super danke, das werde ich mir merken! Anmerkung: Gilt das auch für legacy boot? Ich nutze noch DOS Partitionen. |
Ja da gilt das gleiche. Wobei Legacy boot deprecated ist. Falls du jemals ein HW update (inklusive Mainboard) machst, ist die Wahrscheinlichkeit groß, das legacy boot nicht mehr unterstützt wird.
Um die Umstellung etwas einfacher zu gestalten könntest du folgende Änderung vorher schon durchführen und weiterhin legacy boot nutzen:
Hier jetzt nur Stichpunkte und annahme das grub genutzt wird. Falls du Interesse hast kann ich das ganze dann weiter ausführen:
- Umstellung Partitionsschema von MBR aud GPT (Geht ohne datenverlust mit sgdisk aus sys-apps/gptfdisk)
- Mit einen partitionsprogram eine BIOS Boot Partition anlegen. Da reicht der freie platz (ca. <= 1-2MB), der durch die Umstellung entstanden ist (Denn in diese Partition wird das gleiche kopiert wie beim MBR Schema in den ersten sektoren des Datenträgers, welcher bei MBR frei ist)
- grub neu installieren.
- Die bisherige /boot partition könnte man frei halten um diese dann später in eine UEFI partition umzuwandeln (auf der dann nur der bootloader installiert wird, falls man nicht komplett auf efi boot ohne separaten bootloader umstellen möchte, aber dann müsste diese partition vergrößert werden)
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2588
Location: Heidelberg - Germany
|
| Posted: Sat May 18, 2024 12:52 pm Post subject: |
|
|
Könnte man nicht die bisherige /boot Partition als BIOS Boot Partition umfunktionieren und dann für das neue /boot Verzeichnis im Root lassen? Man brauche ja keine separate boot Partition mehr, zumindest habe ich auf dem Notebook keine separate Boot Partition.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5215
|
| Posted: Sat May 18, 2024 2:05 pm Post subject: |
|
|
| Erdie wrote: | | Könnte man nicht die bisherige /boot Partition als BIOS Boot Partition umfunktionieren und dann für das neue /boot Verzeichnis im Root lassen? Man brauche ja keine separate boot Partition mehr, zumindest habe ich auf dem Notebook keine separate Boot Partition. |
könnte man wäre eventuell nur etwas "Platzverschwendung" je nach dem wie groß die aktuelle /boot partition ist. Denn diese "BIOS Boot Partition" ist im kontext, wenn man Grub verwendet, nur der ersatz für den Speicherbereich welcher bei MBR vorhanden ist.
Bei MBR gibt es am anfang des Datenträgers, bis die erste Partition beginnt einen freien bereich (MBR gap genannt: https://en.wikipedia.org/wiki/BIOS_boot_partition).
In diesen Bereich installiert grub seinen initialen loader (bei grub1 hieß dieser stage1). Und dieser Bereich ist 32KiB groß.
Daher reicht es wenn die BIOS Boot Paritition 1-2 MB groß ist. 1MB ist das mindeste wegen der 1 MiB partition alignment policy
Wenn du aber darauf verzichten kannst ist das kein Problem.
Beachte dass die BIOS Boot Partition kein Dateisystem hat/benötigt.
Daher sollte es reichen den Partitionstyp der /boot partition auf "BIOS Boot" umzustellen, nachdem das Partitionsschema auf GPT umgestellt wurde.
Falls du dir unsicher bist wie der ablauf funktioniert, könntest du das ganze erst mal in einer VM durchspielen.
In der VM installierst du ein linux system mit MBR Partitionsschema + separater /boot partition.
Ich selbst hab diese Umstellung bisher nur bei debian systemen durchgeführt.
Mein Vorgehen war da wie folgt.
Hinweis: Bei diesen Systemen gab es keine separate /boot partition und die Partition für das root dateisystem hat den komplette Datenträger belegt.
- Live Linux System starten und dort via sgdisk das Partitionschema von MBR auf GPT konvertieren.
- Dann mit cgdisk oder gparted in den, durch die GPT Konvertierung frei gewordenen, ca. 1MB Bereich die Bios Boot Partition angelegt.
- Das debian install system gestartet und dort den "rescue/repair" modus gestartet und grub neu installieren lassen
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2588
Location: Heidelberg - Germany
|
| Posted: Sat May 18, 2024 6:15 pm Post subject: |
|
|
Danke! Das mit der Platzverschwendung relativiert sich in meinem Fall, wenn man bedenkt, dass meine boot Partition 30 MB groß ist 
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
|
|
Deutsches Forum (German)
