Ernste Sicherheitslücken in allen modernen CPUs (x86, ARM, POWER, SPARC) - Seite 10

Seite 10 von 21 - Forum: Prozessoren auf overclockers.at

URL: https://www.overclockers.at/prozessoren/ernste-sicherheitslcken-in-allen-modernen-cpus-x86-arm-power-sparc_250457/page_10 - zur Vollversion wechseln!


Römi schrieb am 08.01.2018 um 10:00

IMO nicht nur ältere CPU's.


Chrissicom schrieb am 08.01.2018 um 10:02

Korrekt. Bei AMD Ryzen gab/gibt es nach Update auch vereinzelt Probleme. Manche Apps gehen nicht mehr (richtig). Mein Problem mit AI Suite besteht nach Update auf die aktuelle Beta Version immer noch, obwohl die bei anderen wieder funktioniert. Es kommt zwar keine Fehlermeldung mehr und die Mini Bar geht auch wieder, das Hauptfenster öffnet aber nicht, es passiert einfach nix. In Excel habe ich auch nach wie vor Probleme.


creative2k schrieb am 08.01.2018 um 10:07


maXX schrieb am 08.01.2018 um 13:16

Zitat aus einem Post von Smut
Kann aber auch sein weil Windows10 mobile mit anfang 2018 end of life ist! da wirst so und so keine Updates mehr sehen.
Auf der anderen Seite ist Windows mobile so eine Nische, dass es ohnehin so gut wie keine Angriffe darauf gab - zahlt sich einfach nicht aus. Fokus liegt im mobile Sektor auf outdated android von denen es zu genüge gibt.

gerade nachgeschaut: habe win 8.1 sp2 drauf. ist laut updatefunktion aktuell.


Vinci schrieb am 08.01.2018 um 14:35

Lichtnahrung, Weltfriede, Hardware-Bugs mit Software "fixn"

Die Anzahl der sich aktuell im Umlauf befindenden B$-Artikel ist wirklich überwältigend. Und bevors auch hier nochmal jemand schreibt, der richtige Wortlaut ist Workaround. Einen vernünftigen Artikel zu dem ganzen Thema gibts übrigens meiner Ansicht nach hier: https://developer.arm.com/support/security-update

Die Dringlichkeit mit der das ganze behandelt werden sollte lässt sich übrigens ganz gut daraus ableiten, dass ARM die eigene Architektur grad um einen neuen Assembler-Befehl erweitert hat. Was ich bei ARM bezüglich der bounds-check Variante aus dem Paper (und den ersten Kernel-Workarounds) so rausles steigt der Aufwand eines banalen (sicheren) Loads für die AArch64 Architektur von 10 auf ~18 Befehle. Wie das für andere Architekturen aussieht kann ich leider nicht sagen, aber von "no performance impact" zu sprechen is lächerlich.


eitschpi schrieb am 08.01.2018 um 16:45

Gibts schon Updates von Herstellern? Bei Lenovo find ich nichts darüber.


COLOSSUS schrieb am 08.01.2018 um 16:47

Wirst du nicht brauchen bzw. nicht schneller als durch den OS-Vendor bekommen. CPU-Microcode wird auch von Windows und Linux geladen, wenn er denn da ist.


fresserettich schrieb am 08.01.2018 um 17:02

Zitat aus einem Post von eitschpi
Gibts schon Updates von Herstellern? Bei Lenovo find ich nichts darüber.
also bei meinem Thinkpad T410s auf Win10 Pro macht, dass Windows Update bis jetzt keine Probleme. Laut Lenovo Update gibt es sonst keine Updates für mein schon etwas älteres NB.

Wenn ich das ganze jetzt richtig verstanden habe ist zumdindest Intel der Bug schon länger bekannt. Würde eigentlich davon ausgehen, dasss sich dann Intel sobald der Bug verstanden ist sofort mit diversen Herstellern wie MS, etc. in Verbindung setzt um an Lösungen zu arbeiten. Von daher verstehe ich die Schnellschuss-Thematik nicht so ganz


eitschpi schrieb am 08.01.2018 um 17:03

Na im Linuxkernel ist das Update eh schon drin, dachte nur an BIOS-Updates oder so.


Smut schrieb am 08.01.2018 um 21:22

Zitat aus einem Post von COLOSSUS
Wirst du nicht brauchen bzw. nicht schneller als durch den OS-Vendor bekommen. CPU-Microcode wird auch von Windows und Linux geladen, wenn er denn da ist.
gibt es dazu schon eine gesicherte aussage? technisch könnten sie es, ist aber eine eher seltene praxis bei Microsoft.
auch in ihrem aktuellen advisory verweisen sie auf ein notwendiges bios update durch oem/vendor - surface devices ausgenommen.

edit:
MS advisory zum thema:

Zitat
Warning

Customers who only install the Windows January 2018 security updates will not receive the benefit of all known protections against the vulnerabilities. In addition to installing the January security updates, a processor microcode, or firmware, update is required. This should be available through your device manufacturer.


Note Surface customers will receive a microcode update via Windows update.


creative2k schrieb am 09.01.2018 um 07:46


Und warum haben sie es nicht gleich gefixt wenn es doch so schnell gehen soll?


COLOSSUS schrieb am 09.01.2018 um 08:06

Zitat aus einem Post von Smut
gibt es dazu schon eine gesicherte aussage? technisch könnten sie es, ist aber eine eher seltene praxis bei Microsoft.
auch in ihrem aktuellen advisory verweisen sie auf ein notwendiges bios update durch oem/vendor - surface devices ausgenommen.

edit:
MS advisory zum thema:



Offenbar schwer zu sagen bzw. abzuschaetzen - sicher ist, dass MSFT die Moeglichkeit hat, ucode-Updates auszurollen: https://support.microsoft.com/en-gb...ate-for-windows

Ich weisz auch, dass bei mir der Kernel das ucode-Image laedt - aus einer pre-initrd, die vom Paketmanager verwaltet wird. Ich sehe also keinen Grund, auf irgendeine Mitigation via Firmware seitens meines Boardherstellers warten zu muessen.


Smut schrieb am 09.01.2018 um 08:13

Was mir noch nicht ganz klar ist, ist für welche CPUs der Linux Kernel den Micro Code mitbringt.
Lt. meiner Recherche Tests ist kein Update für einen i7 (Nehalem) dabei und somit gegen eine Spectre Variante weiterhin anfällig (getestet mit centos7).
Getestet hab ich es mit folgendem Skript - ob dieses korrekt arbeitet, kann ich derzeit aber noch nicht beurteilen:
https://github.com/speed47/spectre-...aster/README.md


Garbage schrieb am 09.01.2018 um 08:14

Zitat aus einem Post von COLOSSUS
Ich weisz auch, dass bei mir der Kernel das ucode-Image laedt - aus einer pre-initrd, die vom Paketmanager verwaltet wird. Ich sehe also keinen Grund, auf irgendeine Mitigation via Firmware seitens meines Boardherstellers warten zu muessen.
Was in vielen Fällen ohnehin aussichtlos wäre, nachdem Produktpflege bei 90% der Produkte (Motherboards zumindest) quasi nicht mehr existiert, sobald die nächste Generation draußen ist. :o

Bei Notebooks siehts da schon besser aus, da haben auch mein uralt Dell E6420 (05/17) und auch mein 2012er X1 Carbon (11/2017) noch vor halbwegs kurzer Zeit BIOS Updates bekommen.


COLOSSUS schrieb am 09.01.2018 um 08:41

Zitat aus einem Post von Smut
Was mir noch nicht ganz klar ist, ist für welche CPUs der Linux Kernel den Micro Code mitbringt. [/url]

Der (Upstream-)Kernel bringt nie Microcode mit - evtl. packaged Red Hat das fuer EL so zusammen, aber in allen anderen Distros, die ich kenne, kommen die Dateien fuer das Microcode-Update aus einem Extra-Paket mit dieser Upstream-Quelle: https://downloadcenter.intel.com/do...ocode-Data-File

Was genau da drin ist, weisz wohl niemand auszerhalb Intel so genau (bzw. muesste man den microcode-Update-Treiberquellcode kennen, um das Format verstehen zu koennen) - der Kernel meldet aber im Debug-Ringbuffer, wenn er denn ein neues Image laedt:

Code:
$ dmesg | fgrep micro
[    0.000000] microcode: microcode updated early to revision 0x17, date = 2017-01-27
[    0.349230] microcode: sig=0x40671, pf=0x2, revision=0x17
[    0.349320] microcode: Microcode Update Driver: v2.2.

Insofern kann man zumindest einen Positivnachweis sehr einfach fuehren - Paket installieren, booten, nachschauen, ob was gemeldet wurde.

Die ucode-pre-initrd ist im Dateisystem im Endeffekt ein cpio-Archiv mit genau einer Datei darin, die "GenuineIntel.img" heiszt. Weder die libmagic (`file`), noch binwalk, noch ein Blick rein mit od oder strings geben einen Hinweis darauf, dass es sich um irgendeine Art von handelsueblichem Archivformat handelt, dessen Inhalt man einfach listen koennte,,




overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2024