Seite 1 von 2

Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 03.01.2018, 14:31
von rprengel
https://www.heise.de/security/meldung/M ... 31562.html

Hallo,
wer kann das Thema aus Vmware-Sicht qualifiziert kommentieren?

Gruss
Ralf

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 03.01.2018, 20:09
von Dayworker
Was willst du denn dazu hören?
Die Lücke gibt es wirklich und wurde unter Linux sogar in 2 ältere LTS-Kernel zurückportiert. In Windows-Insider gibt es ebenfalls bereits eine neue Test-Version. Es ist also nur eine Frage der Zeit, wann VMware auch neue Produktversionen veröffentlicht.

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 03.01.2018, 20:36
von rprengel
Mir geht es darum mit welchen Leistungsverlusten unter welchen Bedingungen zu rechnen ist.
In einigen Kommentaren geistern ja Werte von bis 30% durch die Zeilen. Das man aktuell eigentlich nur abwarten kann was kommt ist klar.
Ich bin nicht ausreichend tief in der Materie drin und bin daher auf Einschätzungen anderer angewiesen. Und andere hier wären für meine Meinungsbildung die erste Wahl.
Wie geschrieben letztlich erst nach den ersten Erfahrungen wenn der Patch da ist.
Gruss

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 04.01.2018, 08:48
von JustMe
Kam gerade hier vorbei:
https://lists.vmware.com/pipermail/security-announce/2018/000397.html

Zu den "Leistungsverlusten" (die ja dann doch wohl ziemlich anwendungs[zweck]abhaengig sein duerften...) steht aber nix dabei.

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 04.01.2018, 09:03
von rprengel
Danke,
mal schauen wie gross der Spass wird wenn Kundensysteme anfangen zu lahmen und bei uns dann die Meldungen dazu ankommen.

Gruss

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 04.01.2018, 23:33
von MarroniJohny
Kann man da schon abschätzen, ob man da nur den Hypervisor, oder auch die Gäste patchen muss? Ich mach mir allgemein ein bisschen Sorgen zu dem Thema bei meinem Lab. Ich bin grad an nem Wechsel von X79 zu C612. Weniger CPU Leistung als jetzt möchte ich eigentlich nicht, und mehr wär auch nicht erschwinglich.

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 04.01.2018, 23:39
von Dayworker
Es müssen sowohl Host als auch Gäste gepatcht werden. Das Problem betrifft am stärksten sämtliche Intel-CPUs mit allen 3 Problemen, aber auch AMD und ARM haben Probleme allerdings nur 2.
Was viel schlimmer ist, ist die Tatsache, daß uns dieser Fehler noch sehr lange begleiten wird. Weil Richtig-Lösen läßt er sich im Grunde nur über einen HW-Tausch. Hoffentlich läßt sich dagegen was mit einem Microcode-Update ausrichten.

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 05.01.2018, 06:36
von rprengel
Das wird auch ein Spaß für Hoster die mehrere Kunden auf einem System laufen lassen.
Datenschutz ist damit dauerhaft nicht mehr zu garantieren wenn man aus einem System raus kommen kann und keine verlässliche Lösung in Sicht ist.
Damit wäre das Geschäftsmodel dann eigentlich tot.
Gruss

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 05.01.2018, 13:02
von Dayworker
Mehr als abwarten, werden wir da nicht machen können.

Aber es war mir fast klar, daß Linus Torvalds dazu wieder einen seiner bekannt deutlichen Kommentare abgeben wird, nachdem er ja schon bei nVidia leicht in Rage gekommen war. Hier mal Link samt Wortlaut:
https://lkml.org/lkml/2018/1/3/797 hat geschrieben:

From Linus Torvalds <>
Date Wed, 3 Jan 2018 15:51:35 -0800
Subject Re: Avoid speculative indirect calls in kernel



On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <andi@firstfloor.org> wrote:
> This is a fix for Variant 2 in
> https://googleprojectzero.blogspot.com/ ... -side.html
>
> Any speculative indirect calls in the kernel can be tricked
> to execute any kernel code, which may allow side channel
> attacks that can leak arbitrary kernel data.

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

- Intel never intends to fix anything

OR

- these workarounds should have a way to disable them.

Which of the two is it?

Linus

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 05.01.2018, 23:54
von MarroniJohny
Hi

Wie sieht es aus mit virtualisierten Firewalls, VPN Gateways und sowas? Auf Linux Basis, z.B. auf dem ESXi?

Mal abgesehen von dem Hypervisor Patch? ->

  • Reicht es da auf dem Gast Linux einen neuen Kernel einspielen?
  • Oder sind da noch andere Sachen wie der Kernel von dem Problem abhängig?

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 06.01.2018, 00:07
von kastlr
Hallo zusammen,

hier das Statement von Intel zu diesem Problem.
Speculative Execution and Indirect Branch Prediction Side Channel Analysis Method

Gruß,
Ralf

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 06.01.2018, 00:37
von MarroniJohny
Hi

Ich habe gelesen, dass ein aktueller ESXi nicht betroffen ist. Kann mir das jemand bestätigen, genauer erläutern?

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 06.01.2018, 00:40
von irix
Im 4. Post ist doch das VMware Advisory verlinkt und ESXi ist gelistet.

Gruss
Joerg

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 08.01.2018, 01:01
von Dayworker
Wer bei https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/ mal runterblättert, stößt neben der PowerShell auch auf ein kleines DOS-Tool von https://github.com/ionescu007/SpecuCheck/releases/download/1.0.3/SpecuCheck.exe.

Hier meine Ergebnisse:

Code: Alles auswählen

Core2Duo-E6600
c:\Temp>SpecuCheck.exe
SpecuCheck v1.0.3   --   Copyright(c) 2018 Alex Ionescu
https://ionescu007.github.io/SpecuCheck/  --  @aionescu
-------------------------------------------------------

Mitigations for CVE-2017-5754 [rogue data cache load]
-------------------------------------------------------
[-] Kernel VA Shadowing Enabled:                     no
 +---> with User Pages Marked Global:                no
 +---> with PCID Support:                            no
 +---> with INVPCID Support:                         no

Mitigations for CVE-2017-5715 [branch target injection]
-------------------------------------------------------
[-] Branch Prediction Mitigations Enabled:           no
 +---> Disabled due to System Policy:                no
 +---> Disabled due to No Hardware Support:         yes
[-] CPU Supports Speculation Control MSR:            no
 +---> IBRS  Speculation Control MSR Enabled:        no
[-] CPU Supports Speculation Command MSR:            no
 +---> STIBP Speculation Command MSR Enabled:        no


Code: Alles auswählen

Xeon E3-1220v2 (Ivy Bridge)
C:\>SpecuCheck.exe
SpecuCheck v1.0.3   --   Copyright(c) 2018 Alex Ionescu
https://ionescu007.github.io/SpecuCheck/  --  @aionescu
-------------------------------------------------------

Mitigations for CVE-2017-5754 [rogue data cache load]
-------------------------------------------------------
[-] Kernel VA Shadowing Enabled:                 ===yes===
 +---> with User Pages Marked Global:            ===yes===
 +---> with PCID Support:                            no
 +---> with INVPCID Support:                         no

Mitigations for CVE-2017-5715 [branch target injection]
-------------------------------------------------------
[-] Branch Prediction Mitigations Enabled:           no
 +---> Disabled due to System Policy:                no
 +---> Disabled due to No Hardware Support:         yes
[-] CPU Supports Speculation Control MSR:            no
 +---> IBRS  Speculation Control MSR Enabled:        no
[-] CPU Supports Speculation Command MSR:            no
 +---> STIBP Speculation Command MSR Enabled:        no


Wie erwartet, ist der uralte Core2Duo immun und der ESXi-Host nicht. Das auf dem ESXi-Host nicht noch mehr mit YES gelistet wurde, dürfte an der Virtualisierung liegen.

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 10.01.2018, 07:26
von ~thc
Die Patches für 5.5 und höher sind veröffentlicht worden (201801001).

Wer sich schon mal gefragt hat, ob ESXi auch den CPU-Microcode patcht - ja, aber nur beim GA einer Version. Spätere Patche erneuern den Microcode nicht mehr - dieser Patch ist eine Ausnahme.

P.S. Für ältere Versionen sollte so etwas wie https://vibsdepot.v-front.de/wiki/index.php/Cpu5-microcode funktionieren.

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 10.01.2018, 17:39
von Dayworker
Bedeuten solche Microcode-Patches eigentlich, daß die VMs rebootet werden müssen?

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 11.01.2018, 00:22
von MarroniJohny
Hi

Ich dachte, die Microcodes müssen per BIOS Update eingespielt werden? Wenn vSphere das kann, ist das bei Windows auch möglich?

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 11.01.2018, 07:19
von ~thc
Prinzipiell kann jedes Stück Software auf dem Blech die CPU Microcodes patchen - BIOS, ESXI, Windows, Linux - und tut dies in der Regel auch.

ESXi ist ein Sonderfall, da die Microcode-Patches hier meist nur zum GA einer Version erneuert werden. Dann ist man mit einem aktuelleren BIOS besser dran.

Das ESXI-Microcode-Patching erfordert den ESXi-Neustart, da es sehr früh im ESXi-Bootprozess passiert.

P.S. VMWare hat gerade den Patch für die WS 12 nachgeschoben.

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 11.01.2018, 10:20
von Supi
Ich finde ja GOSTEV von Veeam hat das in seinem Forum Letter sehr gut beschrieben, mal anbei als Quote:

GOSTEV from Veeam hat geschrieben:By now, most of you have probably already heard of the biggest disaster in the history of IT – Meltdown and Spectre security vulnerabilities which affect all modern CPUs, from those in desktops and servers, to ones found in smartphones. Unfortunately, there's much confusion about the level of threat we're dealing with here, because some of the impacted vendors need reasons to explain the still-missing security patches. But even those who did release a patch, avoid mentioning that it only partially addresses the threat. And, there's no good explanation of these vulnerabilities on the right level (not for developers), something that just about anyone working in IT could understand to make their own conclusion. So, I decided to give it a shot and deliver just that.

First, some essential background. Both vulnerabilities leverage the "speculative execution" feature, which is central to the modern CPU architecture. Without this, processors would idle most of the time, just waiting to receive I/O results from various peripheral devices, which are all at least 10x slower than processors. For example, RAM – kind of the fastest thing out there in our mind – runs at comparable frequencies with CPU, but all overclocking enthusiasts know that RAM I/O involves multiple stages, each taking multiple CPU cycles. And hard disks are at least a hundred times slower than RAM. So, instead of waiting for the real result of some IF clause to be calculated, the processor assumes the most probable result, and continues the execution according to the assumed result. Then, many cycles later, when the actual result of said IF is known, if it was "guessed" right – then we're already way ahead in the program code execution path, and didn't just waste all those cycles waiting for the I/O operation to complete. However, if it appears that the assumption was incorrect - then, the execution state of that "parallel universe" is simply discarded, and program execution is restarted back from said IF clause (as if speculative execution did not exist). But, since those prediction algorithms are pretty smart and polished, more often than not the guesses are right, which adds significant boost to execution performance for some software. Speculative execution is a feature that processors had for two decades now, which is also why any CPU that is still able to run these days is affected.

Now, while the two vulnerabilities are distinctly different, they share one thing in common – and that is, they exploit the cornerstone of computer security, and specifically the process isolation. Basically, the security of all operating systems and software is completely dependent on the native ability of CPUs to ensure complete process isolation in terms of them being able to access each other's memory. How exactly is such isolation achieved? Instead of having direct physical RAM access, all processes operate in virtual address spaces, which are mapped to physical RAM in the way that they do not overlap. These memory allocations are performed and controlled in hardware, in the so-called Memory Management Unit (MMU) of CPU.

At this point, you already know enough to understand Meltdown. This vulnerability is basically a bug in MMU logic, and is caused by skipping address checks during the speculative execution (rumors are, there's the source code comment saying this was done "not to break optimizations"). So, how can this vulnerability be exploited? Pretty easily, in fact. First, the malicious code should trick a processor into the speculative execution path, and from there, perform an unrestricted read of another process' memory. Simple as that. Now, you may rightfully wonder, wouldn't the results obtained from such a speculative execution be discarded completely, as soon as CPU finds out it "took a wrong turn"? You're absolutely correct, they are in fact discarded... with one exception – they will remain in the CPU cache, which is a completely dumb thing that just caches everything CPU accesses. And, while no process can read the content of the CPU cache directly, there's a technique of how you can "read" one implicitly by doing legitimate RAM reads within your process, and measuring the response times (anything stored in the CPU cache will obviously be served much faster). You may have already heard that browser vendors are currently busy releasing patches that makes JavaScript timers more "coarse" - now you know why (but more on this later).

As far as the impact goes, Meltdown is limited to Intel and ARM processors only, with AMD CPUs unaffected. But for Intel, Meltdown is extremely nasty, because it is so easy to exploit – one of our enthusiasts compiled the exploit literally over a morning coffee, and confirmed it works on every single computer he had access to (in his case, most are Linux-based). And possibilities Meltdown opens are truly terrifying, for example how about obtaining admin password as it is being typed in another process running on the same OS? Or accessing your precious bitcoin wallet? Of course, you'll say that the exploit must first be delivered to the attacked computer and executed there – which is fair, but here's the catch: JavaScript from some web site running in your browser will do just fine too, so the delivery part is the easiest for now. By the way, keep in mind that those 3rd party ads displayed on legitimate web sites often include JavaScript too – so it's really a good idea to install ad blocker now, if you haven't already! And for those using Chrome, enabling Site Isolation feature is also a good idea.

OK, so let's switch to Spectre next. This vulnerability is known to affect all modern CPUs, albeit to a different extent. It is not based on a bug per say, but rather on a design peculiarity of the execution path prediction logic, which is implemented by so-called Branch Prediction Unit (BPU). Essentially, what BPU does is accumulating statistics to estimate the probability of IF clause results. For example, if certain IF clause that compares some variable to zero returned FALSE 100 times in a row, you can predict with high probability that the clause will return FALSE when called for the 101st time, and speculatively move along the corresponding code execution branch even without having to load the actual variable. Makes perfect sense, right? However, the problem here is that while collecting this statistics, BPU does NOT distinguish between different processes for added "learning" effectiveness – which makes sense too, because computer programs share much in common (common algorithms, constructs implementation best practices and so on). And this is exactly what the exploit is based on: this peculiarity allows the malicious code to basically "train" BPU by running a construct that is identical to one in the attacked process hundreds of times, effectively enabling it to control speculative execution of the attacked process once it hits its own respective construct, making one dump "good stuff" into the CPU cache. Pretty awesome find, right?

But here comes the major difference between Meltdown and Spectre, which significantly complicates Spectre-based exploits implementation. While Meltdown can "scan" CPU cache directly (since the sought-after value was put there from within the scope of process running the Meltdown exploit), in case of Spectre it is the victim process itself that puts this value into the CPU cache. Thus, only the victim process itself is able to perform that timing-based CPU cache "scan". Luckily for hackers, we live in the API-first world, where every decent app has API you can call to make it do the things you need, again measuring how long the execution of each API call took. Although getting the actual value requires deep analysis of the specific application, so this approach is only worth pursuing with the open-source apps. But the "beauty" of Spectre is that apparently, there are many ways to make the victim process leak its data to the CPU cache through speculative execution in the way that allows the attacking process to "pick it up". Google engineers found and documented a few, but unfortunately many more are expected to exist. Who will find them first?

Of course, all of that only sounds easy at a conceptual level - while implementations with the real-world apps are extremely complex, and when I say "extremely" I really mean that. For example, Google engineers created a Spectre exploit POC that, running inside a KVM guest, can read host kernel memory at a rate of over 1500 bytes/second. However, before the attack can be performed, the exploit requires initialization that takes 30 minutes! So clearly, there's a lot of math involved there. But if Google engineers could do that, hackers will be able too – because looking at how advanced some of the ransomware we saw last year was, one might wonder if it was written by folks who Google could not offer the salary or the position they wanted. It's also worth mentioning here that a JavaScript-based POC also exists already, making the browser a viable attack vector for Spectre.

Now, the most important part – what do we do about those vulnerabilities? Well, it would appear that Intel and Google disclosed the vulnerability to all major vendors in advance, so by now most have already released patches. By the way, we really owe a big "thank you" to all those dev and QC folks who were working hard on patches while we were celebrating – just imagine the amount of work and testing required here, when changes are made to the holy grail of the operating system. Anyway, after reading the above, I hope you agree that vulnerabilities do not get more critical than these two, so be sure to install those patches ASAP. And, aside of most obvious stuff like your operating systems and hypervisors, be sure not to overlook any storage, network and other appliances – as they all run on some OS that too needs to be patched against these vulnerabilities. And don't forget your smartphones! By the way, here's one good community tracker for all security bulletins (Microsoft is not listed there, but they did push the corresponding emergency update to Windows Update back on January 3rd).

Having said that, there are a couple of important things you should keep in mind about those patches. First, they do come with a performance impact. Again, some folks will want you to think that the impact is negligible, but it's only true for applications with low I/O activity. While many enterprise apps will definitely take a big hit – at least, big enough to account for. For example, installing the patch resulted in almost 20% performance drop in the PostgreSQL benchmark. And then, there is this major cloud service that saw CPU usage double after installing the patch on one of its servers. This impact is caused due to the patch adding significant overhead to so-called syscalls, which is what computer programs must use for any interactions with the outside world.

Last but not least, do know that while those patches fully address Meltdown, they only address a few currently known attacks vector that Spectre enables. Most security specialists agree that Spectre vulnerability opens a whole slew of "opportunities" for hackers, and that the solid fix can only be delivered in CPU hardware. Which in turn probably means at least two years until first such processor appears – and then a few more years until you replace the last impacted CPU. But until that happens, it sounds like we should all be looking forward to many fun years of jumping on yet another critical patch against some newly discovered Spectre-based attack. Happy New Year! Chinese horoscope says 2018 will be the year of the Earth Dog - but my horoscope tells me it will be the year of the Air Gapped Backup.


Links im Letter:
about obtaining admin password as it is being typed
https://www.youtube.com/watch?v=RbHbFkh6eeE

Chrome: enabling Site Isolation feature
https://support.google.com/faqs/answer/7622138#chrome

installing the patch resulted in almost 20% performance drop in the PostgreSQL benchmark
https://www.postgresql.org/message-id/2 ... narazel.de

...major cloud service that saw CPU usage double after installing the patch on one of its servers
https://www.epicgames.com/fortnite/foru ... ity-update

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 11.01.2018, 19:29
von MarroniJohny
~thc hat geschrieben:Prinzipiell kann jedes Stück Software auf dem Blech die CPU Microcodes patchen - BIOS, ESXI, Windows, Linux - und tut dies in der Regel auch.


Also davon augehend, dass ich Null Plan habe was CPU Microcodes tatsächlich sind: Ich dachte immer, das sind Daten, die offensichtlich in der CPU gespeichert sind. K.A. wie, ich ging bislang immer davon aus, dass die tatsächlich in einer Art ROM auf der CPU gespeichert sind. Und ich dachte dabei auch, dass die nur per BIOS Update geflasht werden können. Weil da gab es ja, z.B. Microcode Updates die den allcore Turbo bei non oc Boards unterbinden.

Danke!

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 18.01.2018, 08:56
von MarroniJohny
Hi

Anscheinend werden die Microcodes bei der Methode ja vom OS zur Verfügung gestellt (hier für Windows):

Bios Update wirds auch keins geben für die Broadwell E. Ein Board, dass 2 Jahre alt ist bekommt kein neues Bios. Ich habe den Microcode von Hand zu Fuß aufgespielt, so ähnlich wie unter Linux.

Ist userunfreundlich, aber die einzige Möglichkeit ein Microcode Update zu erhalten.

Also, ohne Microcodeupdate bekommt Ihr nur die halbe Lücke, halb dicht, das kann man sich sparen. Ohne neuen Microcode, der bei den z.B. Z370 per Biosupdate eingespielt wird, hat das ganze gebastel an Windows keinen Sinn. Und auch erst nach dem neuen Microcode werden sich die performance Probleme einstellen.

Hier mal für alle die ein Board aus 2016 und älter haben eine Anleitung was zu tun ist:

https://www.youtube.com/watch?v=nEYqw5tvZHs

Hier gibts die aktuellen Microcodes:

https://downloadcenter.intel.com/downlo ... a-File?v=t

Nicht von dem Wort Linux verwirren lassen!

Ohne den AMD Microcode läuft das Patchprogramm nicht:

http://cdn-fastly.deb.debian.org/debian ... microcode/

Hier die VMware:

https://labs.vmware.com/flings/vmware-c ... ate-driver

Grüße




https://www.hardwareluxx.de/community/f11/intel-kaempft-mit-schwerer-sicherheitsluecke-update-spectre-laut-google-komplett-abgesichert-1187385.html

Ist das für vSphere auch nötig, oder sind die CPU Microcodes schon in den Security Patches aus Post #4 enthalten?

https://lists.vmware.com/pipermail/secu ... 00397.html

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 18.01.2018, 09:08
von irix
MarroniJohny hat geschrieben:Hi

Anscheinend werden die Microcodes bei der Methode ja vom OS zur Verfügung gestellt (hier für Windows):


Jein. Sofern das OS dass kann waere dies moeglich aber...

<MeinAktuellerKenntnisstand>
- Microsoft hat frueher fuer Windows Server mal Microcode Patches ausgeliefert wird das fuer die aktuelle Luecke aktuell nicht tun und zeigt auf die Partner
- Microsoft hat noch nie fuer Windows CLient OS Microcode Patches ausgeliefert
- Microsoft wird als Anbieter des Surfaces was liefern (Aber ich weis nicht in welcher Form)

- Unter Linux waere es Moeglich....da wird jeder Distri aber was anderes machen bzw. man muss halt selber ran
- VMware liefert Microcode Patches normal mit dem Start einer neuer Vollversion
- VMware hat eine Ausnahme gemacht und die aktuellen Microcode Patches zur Verfuegung gestellt
- VMware hat wegen Fehlermeldungen (Neustart von Rechnern) das Paket wieder zurueck gezogen
- VMware hatte nicht gelistet fuer welche CPUs ueverhaupt was drin war. Die Sandybridges gingen z.B leer aus
</MeinAktuellerKenntnisstand>

Um Spectre Variant 2 zuschliessen sind diese Microcodes notwendig. Die werden bei jedem Neustart wieder eingespielt und drum waere es schlau wenn das BIOS dies tun wuerde.

Gruss
Joerg

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 18.01.2018, 09:38
von MarroniJohny
Hi

Ja, danke.

Ich habe leider einen Sandy vSphere Host, da gibts sicher keine BIOS Updates mehr. Und blöderweise habe ich mir jetzt noch ein C612 Mainboard gekauft. Mal sehen, ob es da dann noch ein BIOS Update gibt.

Sehe ich das richtig, dass die genannten vom OS zur Verfügung gestellten Microcodes die Selben sind, welche auch im BIOS Update enthalten wären? Ich bin grade mit dem Desktop am updaten, da habe ich für den 3930k die uCU 710, im Moment.

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 18.01.2018, 09:48
von irix
Sowohl die OS als auch HW Hersteller beziehen es von Intel.

Da ich hier Dell habe wird auch zum aktuellen Stand hier ein Update geben (Dell 12Gen.) Da fuer diese Server sowohl Sandy als auch Ivybridge verfuegbar waren gibts zwar Unsicherheit aber ich hoffe das beste. In deren Liste ist Anfang Februar genannt. Da scheinbar auf Intel gewartet wird kann es fuer alle anderen Hersteller da noch nichts geben und es heist abwarten. Ansonsten schreib deinen Hersteller halt an.

Gruss
Joerg

Re: Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche

Verfasst: 18.01.2018, 09:57
von MarroniJohny
Ich stell mir das halt so vor, dass ich vor den ESXi einen Linux Bootloader setze, der mir vor Start von vSphere den Microcode einspielt.

Für alle meine CPU's (3xSandy und einmal Ivy) sind bei Intel die neuen Microcodes verfügbar.

https://downloadcenter.intel.com/downlo ... a-File?v=t

Edit:

Habe da eben ein heise Artikel gefunden dazu:

https://www.heise.de/ct/ausgabe/2016-7- ... 33880.html