Komisch heutzutage keine Hardwarebeschleunigung fuers decodieren zu benutzten.TomL hat geschrieben:03.01.2018 15:44:07*hmmm*... also wenn ich Pech habe, ruckeln meine Filme wieder, wie ich das mit der AMD-CPU hatte und was der Grund war für meine Entscheidung, keine AMD-CPUs mehr zu nutzen...
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!
Das heißt für mich, dass - mal geschätzt - zwei Drittel der Computer besitzenden Menschheit betroffen sein. wird.breakthewall hat geschrieben:03.01.2018 13:16:13Doch wer eine AMD-CPU hat, kann das immerhin via Kernelparameter abschalten, und hat somit keine Leistungseinbußen. Ungünstig daran ist nur, dass man damit auch eine Schutzfunktion abstellt, die besonders ASLR stärkt.
Warum beinträchtigt dieser Patch bzw. dessen Deaktivierung per Kernel-Argument ASLR?breakthewall hat geschrieben:03.01.2018 13:16:13Doch wer eine AMD-CPU hat, kann das immerhin via Kernelparameter abschalten, und hat somit keine Leistungseinbußen. Ungünstig daran ist nur, dass man damit auch eine Schutzfunktion abstellt, die besonders ASLR stärkt.
Intel hat vor rund 10 Jahren ganz tief in's Klo gegriffen und seinen CPUs ein "Feature" verpasst, das es Userspace-Prozessen erlaubt Speicher aus dem Kernelspace zu lesen (und zu schreiben?) - und zwar auf eine Weise, die sich NICHT durch Software fixen lässt.geier22 hat geschrieben:03.01.2018 20:23:46Ich verstehe nur Bahnhof
Da gibt es also einen "geheimen" Bug bei den Intel-Prozessoren der letzten Dekade
Dass wir erst heute davon erfahren heißt nicht, dass nicht schon früher jemand anderer über das Problem gestolpert ist und womöglich ungeniert seit Jahren seine Finger in deiner Tasche hat. Wer das sein könnte darfst du dir selbst ausmalen: Russland, China, die NSA, Marsmenschen, etc.geier22 hat geschrieben:03.01.2018 20:23:46Da wird irgend etwas bei der Speicherverwaltung durcheinander gebracht, was offensichtlich Angriffe ermöglicht
oder --- sehr wahrscheinlich ------ umfangreiche Angriffe begünstigt hat.
Wenn der schon im November bescheid wusste, war das nicht dumm. Ich könnte den Mann verstehen.geier22 hat geschrieben:03.01.2018 20:23:46Das führt dazu, dass der CEO von Intel alle Aktien bis auf das zu haltende Minimum verscheuert.
Die Patches sind nicht geheim (du kannst alles Relevante aus dem Kernel-Code entnehmen...), bzw. werden es nicht bleiben (...Dokumentation wird folgen). Man will sie nur NOCH nicht vollständig und für jeden leserlich veröffentlichen, um das Problem behandeln zu können, bevor irgendwelche Scriptkiddies mit Exploits um sich werfen.geier22 hat geschrieben:03.01.2018 20:23:46Da gibt es geheime Patches, die die Leistung der Prozessoren mehr oder weniger erheblich bremsen.
Der Patch lässt sich über einen Kernelparameter abschalten, womit sich ein gepatchter Kernel wieder wie ein ungepatchter verhält (potenziell unsicher, aber schnell wie gewohnt).geier22 hat geschrieben:03.01.2018 20:23:46Aber breakthewall weiss schon, das man das mit Kernel- Parametern wieder umgehen kann.
Ich gehe eher von 80-90% aus. Wie hoch ist AMDs Marktanteil gerade?geier22 hat geschrieben:03.01.2018 20:23:46Das heißt für mich, dass - mal geschätzt - zwei Drittel der Computer besitzenden Menschheit betroffen sein. wird.
Ich gehe mal davon aus, ich muss ASLR bzw. Speicherverwürfelung nicht gesondert erklären. Und unter Linux gibt es im Speziellen noch KASLR, was zusätzlich auf den Linux-Kernel angewendet wird. Das Problem dabei ist, dass ASLR grundsätzlich nur das Ausnutzen von Sicherheitslücken erschwert, dies jedoch nicht verhindern kann. Dementsprechend ist diese Sicherheitstechnik angreifbar, und konnte schon oft ausgehebelt werden.hikaru hat geschrieben:04.01.2018 00:28:31Warum beinträchtigt dieser Patch bzw. dessen Deaktivierung per Kernel-Argument ASLR?
TomL hat geschrieben: weil in meiner VM mit lscpu die gleiche CPU angezeigt wird.
'vboxmanage --help' ->hikaru hat geschrieben: Anders als z.B. Qemu emuliert VBox keine CPU, sondern reicht nur die Host-CPU (bzw. Teile davon) in die VM durch.*
[1]Wie bitte? 1995? Zu heftig. Gerade bei hoher I/O-Auslastung, machen sich die Leistungseinbußen teils sehr stark bemerkbar, was laut Berichten mitunter über 50% betrug.dufty2 hat geschrieben:04.01.2018 03:52:24Meltdown: Intel-only, bis zurück 1995, betrifft auch Windows und OS X
Abhilfe: Durch KPTI-Kernelupdate, Lücke ist einfach auszunutzen.
So, fehlen nur noch die debian-packages dazu
Das einzig Positive daran ist wohl, dass das via Software adressiert werden kann, und das ohne KPTI und enorme Leistungseinbußen. Allerdings wird das wohl recht aufwändig, wodurch viele Patches und Microcode-Updates nötig werden. Zusätzlich müssen neue noch nicht existierende Compiler-Optionen geschaffen werden, um dann die ganze Software neu zu kompilieren. Soweit die bisherigen Informationen. Auch wenn dazu geraten wurde, sich gleich neue Hardware anzuschaffen die nicht betroffen ist. Das Jahr fängt ja verdammt gut an.dufty2 hat geschrieben:04.01.2018 03:52:24Spectre: Intel, AMD, ARM, POWER, (weitere?)
Abhilfe: derzeit keine, aber die Lücke ist - zum Glück - schwierig auszunutzen
Dem Beitrag kann ich folgen. Ich verstehe aber nach wie vor nicht, wie du zu der Schlussfolgerung kommst, dass KPTI ASLR schwächt.breakthewall hat geschrieben:04.01.2018 01:40:49Ich gehe mal davon aus, ich muss ASLR bzw. Speicherverwürfelung nicht gesondert erklären. Und unter Linux gibt es im Speziellen noch KASLR, was zusätzlich auf den Linux-Kernel angewendet wird. Das Problem dabei ist, dass ASLR grundsätzlich nur das Ausnutzen von Sicherheitslücken erschwert, dies jedoch nicht verhindern kann. Dementsprechend ist diese Sicherheitstechnik angreifbar, und konnte schon oft ausgehebelt werden.
Und die neue Sicherheitstechnik namens KPTI (ehemals KAISER), sorgt dafür das die Speicherseiten des User -und Kernelspace, zukünftig voneinander isoliert bzw. getrennt werden. Das minimiert die Angriffsfläche und insbesondere sensible Kernel-Informationen zur Laufzeit, die zuvor vom Userspace aus sichtbar waren, und nun nicht länger existieren. Davon profitiert natürlich ASLR bzw. KASLR ungemein, und ist dank der Informationsarmut erheblich wirksamer als zuvor.
Also eher zwei Dekaden als eine!
Sicherheitslücken in Computerchips ... v.a. Intel betroffen
Genau, und dazu gibt es noch ein anderen bug.MarkusF hat geschrieben:04.01.2018 09:13:33der BUG ist bei Intel gewissermaßen 'in Hardware gegossen'
jeder neue Chip den ich mir gedenke zu kaufen, auch die in der Roadmap f. 2018 haben/hätten diesen Fehler
Intel muss, um das Problem an der Wurzel zu packen, seinen Fertigungsprozess verändern
bei bestehenden Intel-Chips, fast jedes gebräuchlichen Alters, muss per Kernelupdate abgeholfen werden, was noch unbekannte Leistungseinbußen und damit verbunden auch sinkende Energieeffizienz mit sich bringt
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!So habe ich es verstanden:schwedenmann hat geschrieben:04.01.2018 09:25:56jetzt wohl auch AMD + ARM betroffen, die Lücke ist wohl größer und umfassender als bisher zugegeben.
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!ok, macht Sinnn. Hat aber wohl nur den Initalpost geändert. Liebe Mods, tut euch keinen Zwang an das zu korrigeren...Als eine Maßnahme dazu würde ich vorschlagen, den Thread-Titel in sowas wie "Hardware-Sicherheitslücken: Meltdown und Spectre" umzubenennen, denn zumindest in Bezug auf Spectre ist der aktuelle Titel "Intel-Bug" irreführend.
Kann ich jetzt wieder glücklich sein?2. This BIOS fixes the following problem of the previous version:
- Improve NVME compatibility.
- Update micro code.
- Improve USB 2.0 device can not work properly after resume from S3 mode.
- Improve memory compatibility.
- Update Intel ME for security vulnerabilities
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!Soweit ich es verstehe, nein. Meltdown ist prinzipiell nicht durch ein BIOS- oder Microcode-Update zu fixen, deren Effekte ja nur beim Start des Systems zum Tragen kommen. Meltdown muss auf betroffener Hardware vom Betriebssystemkernel während der Laufzeit kontinuierlich behandelt werden.TuxPeter hat geschrieben:04.01.2018 11:36:20Board mit Intel G4560 "Kaby Lake"
[..]
Jetzt gab es gab ein Bios-Update mit Datum vom 04.12.17.
[..]
Kann ich jetzt wieder glücklich sein?
Ist dieser damit gemeint?Harakiri hat geschrieben: Die hat hat bereits eine Fehlerkorrektur für die Intelproblematik integriert.
https://cdn.kernel.org/pub/linux/kernel ... og-4.14.11
Betrifft es weitere der Patches?commit 72a2beddcd3240047552de69ce45a28029c7e56c
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Mon Dec 4 15:07:33 2017 +0100
x86/cpufeatures: Add X86_BUG_CPU_INSECURE
commit a89f040fa34ec9cd682aed98b8f04e3c47d998bd upstream.
Many x86 CPUs leak information to user space due to missing isolation of
user space and kernel space page tables. There are many well documented
ways to exploit that.
The upcoming software migitation of isolating the user and kernel space
page tables needs a misfeature flag so code can be made runtime
conditional.
Add the BUG bits which indicates that the CPU is affected and add a feature
bit which indicates that the software migitation is enabled.
Assume for now that _ALL_ x86 CPUs are affected by this. Exceptions can be
made later.
Nö, jener fügt bei der
Code: Alles auswählen
$ cat /proc/cpuinfo