Intel Nieuwsdiscussietopic

[RedShift]

Er wordt veel gepraat over virtuele machines maar de bug zelf en de fix heeft impact op hoe context switching werkt, de impact is dus niet beperkt tot virtuele machines, en kan in "gewone" (niet gevirtualiseerde) workloads ook significante negatieve performance gevolgen hebben.

[ Voor 2% gewijzigd door RedShift op 02-01-2018 23:50 . Reden: Beetje meer synoniemen gebruiken ]

[Verwijderd]

Aiaiai, net het nieuws gehoord over de bug. Niet niks, tot 30% performanceverlies als je een patch gebruikt om het systeem weer veilig te krijgen. Gelukkig voor Intel wordt de nieuwste generatie het minst getroffen maar die troef die ze nog hadden t.o.v. AMD dat het meer betrouwbaar zou zijn omdat het platform ouder is, daar is nu weinig meer van over. Voor het geval het nog niet duidelijk was, deze bug geldt enkel voor Intel-CPU's, niet voor AMD-CPU's. Dit is overigens het tweede schandaal m.b.t. de veiligheid van Intel-CPU's, de laatste jaren had je al het probleem met de lekke Manamgement Engine die gehackt kan worden. Niet gemakkelijk, denken we, maar het is mogelijk.

Een paar relevante links over de nieuwste bug.
https://lwn.net/Articles/569635/
https://lkml.org/lkml/2017/12/27/2
https://lkml.org/lkml/2017/12/4/709
https://www.theregister.c...02/intel_cpu_design_flaw/
http://pythonsweetness.tu...e-of-the-linux-page-table

Een AMD-medewerker gaf deze hint voor de oorzaak:
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Een interessant stukje uitleg op Theregister:
"It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the contents of protected kernel memory.

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

Whenever a running program needs to do anything useful – such as write to a file or open a network connection – it has to temporarily hand control of the processor to the kernel to carry out the job. To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes' virtual memory address spaces, although it is invisible to these programs. When the kernel is needed, the program makes a system call, the processor switches to kernel mode and enters the kernel. When it is done, the CPU is told to switch back to user mode, and reenter the process. While in user mode, the kernel's code and data remains out of sight but present in the process's page tables.

Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.

These KPTI patches move the kernel into a completely separate address space, so it's not just invisible to a running process, it's not even there at all. Really, this shouldn't be needed, but clearly there is a flaw in Intel's silicon that allows kernel access protections to be bypassed in some way.

The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware. These context switches do not happen instantly, and they force the processor to dump cached data and reload information from memory. This increases the kernel's overhead, and slows down the computer.

Your Intel-powered machine will run slower as a result."


PS
Ik hoop dat mijn i5-750 niet hierbij betrokken is. 30% minder performance dan wat het al heeft, "Houston, we have a problem", met de huidige RAM-prijzen...

[ Voor 56% gewijzigd door Verwijderd op 03-01-2018 00:13 ]

[Cilph]

Jezus zeg Intel. Ik hoop dat Coffee Lake ongevoelig is of op zn minst maar een paar procenten, want anders zijn er rellen. Vanuit Google/Amazon/Microsoft zijn die er sowieso, die zijn echt niet blij dat men nu uit VMs zou kunnen breken of dat ze die 30% moeten slikken.

[Verwijderd]

Niet ongevoelig! Wel minder gevoelig. Over minima is niets gezegd, wel is aangegeven dat je in het ergste geval 30% tragere CPU's krijgt, zie in mijn laatste reactie onderaan (citaat) voor een beetje duiding. Wat ik ervan begrijp kunnen ze deze onveiligheid enkel oplossen door als het ware twee adressenlijsten (waar in de RAM en eventueel op een SSD of - help - een harde schijf je informatie opslaat die bij de uitvoering van een programma wordt gebruikt) te gebruiken, een voor de kernel en een voor de programma's, en de hele tijd tussen de twee te schakelen, op die manier breng je een barrière aan. Normaal gesproken zou je 1 adressenlijst hebben waarbij het kernel-deel van die lijst onzichtbaar is voor het programmadeel omdat de CPU zelf die barrière vormt, nu de CPU dat niet kan doen moet je twee aparte lijsten gebruiken, dat begrijp ik ervan. Het 'transport' van data tussen stukken hardware (RAM en CPU) is hetgeen wat met afstand de meeste tijd kost, veel meer dan het uitvoeren van instructies door de CPU. Dit moet nu veel meer gebeuren doordat de Cache (soort van RAM-geheugen maar heel erg dicht bij de CPU en heel erg klein) data moet dumpen en opnieuw data van de RAM naar de CPU moet.

Je mag in ieder geval kiezen tussen het lek laten met alle risico's vandien (prima, maar dan misschien niet je systeem gebruiken voor internetbankieren, het raadplegen van je e-mail, Steam etc.?), performance inleveren en een nieuwe CPU kopen. Ik stel voor dat je Ryzen overweegt als je voor de derde optie kiest. Het ziet er goed uit voor de volgende generaties, de node die AMD gaat gebruiken (afkomstig van IBM) is beloftevol.
Eens zien hoe de sfeer is op de AMD-pagina's van Reddit.

[ Voor 119% gewijzigd door Verwijderd op 03-01-2018 00:28 ]

[Racing_Reporter]

Kuch, er zijn gevallen gevonden met impact van 50%.

[Verwijderd]

Shit! Wat een jaar, eerst stoot AMD Intel van de troon als zuinigere CPU, nu blijkt Ryzen ook nog eens betrouwbaarder te zijn.
Wedden dat veel gewone gebruikers niet die patch gaan toepassen? Wellicht verplicht MS het voor W10, voor W7 en W8 daarentegen...
Nu moet iedereen zelf weten hoeveel risico hij aanvaardt maar ik raad aan om te patchen op basis van wat we nu weten.

Ik ben benieuwd wat de consequenties zijn voor de volgende generatie van Intel. Kan Intel dit nog rechttrekken voor de volgende generatie of gaat die nu een half jaar later komen omdat ze zoveel tijd nodig hebben om het aan te passen (ontwerp, productie, testen...)? Ik kan me niet voorstellen dat Intel deze bug in de volgende generatie laat zitten. Het kan natuurlijk ook dat Intel het al lang genoeg wist dat het hier al rekening mee had gehouden.

Hier trouwens de draad van Reddit op de AMD-pagina's, voor informatie en schadenfreude.
https://www.reddit.com/r/...nl8r0/intel_bug_incoming/
It is really bad. Intel-should-go-up-in-flames bad.

Especially since their CEO sold his stock.

---

What an EPYC opportunity!

I'm sorry, I know where the door is.

---

Should I start buying AMD shares?

---

Meer serieus, de topman van Intel verkocht onlangs opvallend veel aandelen. Nu is het op zich niet vreemd dat een CEO aandelen verkoopt maar de exacte omstandigheden (hij behield het minimum aantal aandelen wat hij contractueel moet behouden en er waren juist signalen, naar buiten toe, dat Intel financieel zou groeien en dat dus de aandelen meer waarde zouden krijgen) maken deze transactie meer verdacht (lees: aandelen verkopen voordat het slechte nieuws bekend wordt).
https://www.fool.com/inve...-sold-a-lot-of-stock.aspx
Van 29 november 2017.
Geen hard bewijs maar wel interessant om in je achterhoofd te houden.

[ Voor 75% gewijzigd door Verwijderd op 03-01-2018 01:34 ]

[Dennism]

Racing_Reporter schreef op woensdag 3 januari 2018 @ 00:45:
Kuch, er zijn gevallen gevonden met impact van 50%.

Real life applicaties, of syscall spammende binaries als test? Ik zag eerder namelijk ook zo'n worst case "benchmark" voorbij komen, maar die deed niets anders dan syscalls spammen. Dan is het niet direct onlogisch dat je 50% performance verlies hebt.

[DaniëlWW2]

Dennism schreef op dinsdag 2 januari 2018 @ 23:08:
[...]


Ja de geruchten gaan al een tijdje dat er "iets"in de lucht hangt, maar het lijkt toch wel vrij serieus te zijn. Al lijkt het wel dat het performance verlies in ieder geval enkel voor zeer specifieke taken en dan inderdaad vooral bij oudere generaties vrij fors te zijn. Ben ook wel benieuwd of de geruchten waar zijn dat je op ongepatchte systemen bijv. in VMs "mee kan kijken" in het geheugen van andere VM's. Want is natuurlijk wel een enorm probleem, zeker voor bepaalde grote cloudaanbieders. Maar goed, we zullen het wel gaan zien, deze week zouden er mogelijk officiële statements gaan komen.

Dat laatste lijkt dus het geval te zijn als je de lijn van die AMD medewerker volgt. Natuurlijk korreltje zout, maar hij zal veel meer op de hoogte zijn van de fijne details van Intel en AMD architectuur dan menig willekeurig persoon op het internet. Yes, I said it.

Maar cloud servers lijken in ieder geval getroffen, en daarbuiten is het afwachten. Ik vraag me nu eigenlijk af of Microsoft er niet al wat langer van wist, of vermoedens had. Ze waren wel erg openlijk aan het flirten met AMD, en zullen onderhand al serieuze kwantiteiten aan Epyc chips hebben afgenomen, en nog veel meer gaan afnemen voor Azure. Dat kan best wel eens vervroegd afschrijven gaan worden van oudere servers, als het echt helemaal mis is. Dat valt dan nog mee als ze nieuwe kunnen aanschaffen die geen problemen hebben.

Voor Google lijkt dit op een ramp uit te lopen. Google lijkt een soort exclusiviteitsdeal met Intel te hebben gesloten rond Skylake SP. Afgelopen zomer bleek dat Intel een deal had gesloten met een van de grote acht voor early adoption, en Google was toen aan het pochen dat ze al Skylake SP chips hadden. Dan weet het het wel.

Maar jij zat toch in deze sector? Zo ja, dan succes ermee de komende weken.

[Dennism]

DaniëlWW2 schreef op woensdag 3 januari 2018 @ 09:56:

Maar jij zat toch in deze sector? Zo ja, dan succes ermee de komende weken.

Ik zit wat dit betreft gelukkig niet bij een Azure of iets in die richting, maar virtualisatie, ja dat wel veel Dus ja, dat kan nog leuk gaan worden de komende tijd.

[Meekoh]

Dennism schreef op woensdag 3 januari 2018 @ 07:37:
[...]


Real life applicaties, of syscall spammende binaries als test? Ik zag eerder namelijk ook zo'n worst case "benchmark" voorbij komen, maar die deed niets anders dan syscalls spammen. Dan is het niet direct onlogisch dat je 50% performance verlies hebt.

Ja wel degelijk real life applicaties!
Bijv. binnen een Postgres sql database select 1 uitvoeren.
Kan tussen de 12% en 23% langzamer zijn dan zonder de patch. Of wat dacht je Hypervisors? Die doen syscalls all over the place, dat zullen de AWS/Azure/Google Clouds niet leuk vinden.
Het is niet voor niets dat de komende week de grote cloud providers een mass reboot van VM's gaan doen.
Kortom alles wat interactie heeft met de kernel zal trager worden, van het saven van een word bestandje tot het draaien van een VM.

[Dennism]

Meekoh schreef op woensdag 3 januari 2018 @ 10:19:
[...]

Ja wel degelijk real life applicaties!
Bijv. binnen een Postgres sql database select 1 uitvoeren.
Kan tussen de 12% en 23% langzamer zijn dan zonder de patch. Of wat dacht je Hypervisors? Die doen syscalls all over the place, dat zullen de AWS/Azure/Google Clouds niet leuk vinden.
Het is niet voor niets dat de komende week de grote cloud providers een mass reboot van VM's gaan doen.
Kortom alles wat interactie heeft met de kernel zal trager worden, van het saven van een word bestandje tot het draaien van een VM.

Dat was natuurlijk al bekend, het ging mij meer om de "50%" stelling, die cijfers heb ik namelijk alleen gezien bij tests die niets anders doen dan enkel syscalls spammen. Dat er in real world applicaties rekening gehouden moet worden met 5-30% afhankelijk van de workload en cpu generatie was al aangekondigd.

[Meekoh]

Overigens zouden we dit al prima kunnen benchmarken. De patch van Microsoft is schijnbaar in December al gepushed naar de Fast ring van Win10 gebruikers.

[Wildfire]

Nou, ik ben benieuwd wat dit in de praktijk voor m'n i7-7820X gaat betekenen. Als die 30% klopt kan ik net zo goed de boel verkopen en overstappen op een Ryzen 7 1800X. Nu is er nog een performanceverschil tussen die twee in het voordeel van de i7, maar als die patches er doorheen zijn en ik rond de 30% performancedaling krijg dan is de Ryzen opeens gelijk of zelfs iets beter...

Ai.

Maar goed... eerst maar eens real-life benchmarks afwachten om te kijken wat de impact daadwerkelijk gaat zijn.

[ Voor 12% gewijzigd door Wildfire op 03-01-2018 11:39 ]

[DaniëlWW2]

Ik denk dat het wel even belangrijk is om even op de vlakte te blijven. Nog een dag van alsmaar aangedikte verhalen zoals die nu circuleren, en dan betekent een Intel CPU bezitten neerkomt op je PC die gehacked is door een of andere criminele groep, of een overheid. Zo erg zal het (hopelijk) nu ook weer niet zijn.

[foppe-jan]

DaniëlWW2 schreef op woensdag 3 januari 2018 @ 11:50:
Ik denk dat het wel even belangrijk is om even op de vlakte te blijven. Nog een dag van alsmaar aangedikte verhalen zoals die nu circuleren, en dan betekent een Intel CPU bezitten neerkomt op je PC die gehacked is door een of andere criminele groep, of een overheid. Zo erg zal het (hopelijk) nu ook weer niet zijn.

ik zou het ook niet onderschatten. de onderzoekers die het vonden lieten zien hoe je via JS in de browser een PC kon hacken.

offtopic:
los van hoe erg het is, een mooi duwtje in de rug voor AMD, want dit maakt 2e-hands een stuk minder aantrekkelijk, naast dat ook de huidige gen Xeons er last van heeft, en Intel niet zomaar een refresh zal kunnen lanceren.

[DaniëlWW2]

foppe-jan schreef op woensdag 3 januari 2018 @ 12:18:
[...]

ik zou het ook niet onderschatten. de onderzoekers die het vonden lieten zien hoe je via JS in de browser een PC kon hacken.

offtopic:
los van hoe erg het is, een mooi duwtje in de rug voor AMD, want dit maakt 2e-hands een stuk minder aantrekkelijk, naast dat ook de huidige gen Xeons er last van heeft, en Intel niet zomaar een refresh zal kunnen lanceren.

Er is een verschil tussen onderschatten en nu totale paniek gaan zaaien. Dat het kennelijk al zover is dat de Windows kennel gedeeltelijk herschreven moet worden, zegt al genoeg over de impact en gevolgen. Toch blijf ik op de vlakte, puur omdat we het nog niet weten. Het meest relevants is nu de prestatie impact en welke Intel chips allemaal problemen hebben. Ik heb in ieder geval tot Ivy Brigde gezien. Sandy Brigde kan je waarschijnlijk dus ook meenemen. Dan is er nog Nehalem waar het een vraagteken is.

Maar nu op de vlakte blijven lijkt me een redelijk zinnige aanpak. We weten het simpelweg niet.

[RedShift]

DaniëlWW2 schreef op woensdag 3 januari 2018 @ 12:24:
[...]


Er is een verschil tussen onderschatten en nu totale paniek gaan zaaien. Dat het kennelijk al zover is dat de Windows kennel gedeeltelijk herschreven moet worden, zegt al genoeg over de impact en gevolgen. Toch blijf ik op de vlakte, puur omdat we het nog niet weten. Het meest relevants is nu de prestatie impact en welke Intel chips allemaal problemen hebben. Ik heb in ieder geval tot Ivy Brigde gezien. Sandy Brigde kan je waarschijnlijk dus ook meenemen. Dan is er nog Nehalem waar het een vraagteken is.

Maar nu op de vlakte blijven lijkt me een redelijk zinnige aanpak. We weten het simpelweg niet.

Alle Intel processoren vanaf de P6 (Pentium Pro/Pentium II) voeren speculative execution op dezelfde manier uit, en dat is waar de kwetsbaarheid zich bevindt. Het enigste wat verschilt is de performance impact die de fix zal hebben, en die performance impact zal pas volledig weg zijn als Intel het probleem hardwarematig gefixt heeft.

[DaniëlWW2]

RedShift schreef op woensdag 3 januari 2018 @ 12:29:
[...]

Alle Intel processoren vanaf de P6 (Pentium Pro/Pentium II) voeren speculative execution op dezelfde manier uit, en dat is waar de kwetsbaarheid zich bevindt. Het enigste wat verschilt is de performance impact die de fix zal hebben, en die performance impact zal pas volledig weg zijn als Intel het probleem hardwarematig gefixt heeft.

Oh dus potentieel elke Intel CPU van dit millennium heeft deze beveiligingsfout. Ja, dat is ietwat problematisch.

[-The_Mask-]

DaniëlWW2 schreef op woensdag 3 januari 2018 @ 12:36:
[...]


Oh dus potentieel elke Intel CPU van dit millennium heeft deze beveiligingsfout. Ja, dat is ietwat problematisch.

Maak daar maar "elk complex apparaat heeft beveiligingsfouten" van. Het is echt niet zo dat PC's gebaseerd op een AMD CPU dat niet heeft, terwijl alle andere elektronica het wel heeft.

[Verwijderd]

foppe-jan schreef op woensdag 3 januari 2018 @ 12:18:
[...]

ik zou het ook niet onderschatten. de onderzoekers die het vonden lieten zien hoe je via JS in de browser een PC kon hacken.

offtopic:
los van hoe erg het is, een mooi duwtje in de rug voor AMD, want dit maakt 2e-hands een stuk minder aantrekkelijk, naast dat ook de huidige gen Xeons er last van heeft, en Intel niet zomaar een refresh zal kunnen lanceren.

Een reden dat ik graag een whitelist voor Javascript gebruik. Dat en omdat websites vaak beter werken als je bepaalde JS blokkeert, zoals dat je alle tekst op 1 pagina krijgt in plaats van op 8 pagina's en dat je geen vervelende pushmessages krijgt met het verzoek je te registreren of een enquête in te vullen, al dan niet met het blokkeren van de tekst als je dat niet doet. Er zijn immers veel meer kwetsbaarheden bij JS dan enkel dit.

[ Voor 6% gewijzigd door Verwijderd op 03-01-2018 15:47 ]

[deregtx]

Dit is al sinds november bekend: https://twitter.com/aionescu/status/930412525111296000

Daarom heeft AMD zoveel nieuwe klanten ineens voor hun server chips.

[Tadream]

Pfff als dit echt zo erg is als er beweerd wordt, dan wordt dat nog wat voor onze VMware omgeving.
Dan komen er dus patches voor de vmware kernel en bovenop de Windows/Linux servers, we hebben ook maar ongeveer 99 virtuele servers (van SQL, domain controllers tot RDS servers) draaien dus valt wel mee (not).
De blades zijn inmiddels 4 jaar oud, zouden nog wel even mee kunnen maar als het 30-50% performance gaat opslokken dan denk ik dat we die vervangingsronde mogelijk sneller gaan doen en serieus naar AMD gaan kijken.
Maar goed, eerst maar even aankijken hoe het zich allemaal ontwikkeld.

[ Voor 4% gewijzigd door Tadream op 03-01-2018 18:04 ]

[CMD-Snake]

Verwijderd schreef op woensdag 3 januari 2018 @ 01:13:
Meer serieus, de topman van Intel verkocht onlangs opvallend veel aandelen.

Dat heeft die CEO vermoedelijk eerder gedaan omdat er in 2018 grote belasting veranderingen komen die hem raken. De Intel CEO woont in Californië. Door een ongunstige interactie tussen belastingen aan de staat en federale belastingen in 2018 is het gunstiger voor hem en andere mensen in een vergelijkbare positie, om zoveel mogelijk van dit soort transacties in fiscaal jaar 2017 te doen. Tot en met 2017 kon je in de belasting die je betaalde aan je staat afschrijven tegen de federale belastingen die je moest betalen. In 2018 kan dit niet meer.
In 2017 zijn aandelen verkopen scheelt onder de streep ongeveer 5% aan belasting betalen. Als je miljoenen aan inkomen hebt kan dat een verschil maken.

De CEO verdiende 11 miljoen dollar aan de verkoop van de aandelen. Dankzij de gunstige belastingwetgeving waar deze transactie onder valt bespaart hij 550.000 dollar aan belasting betalen. Gezien dat de CEO (net als andere Intel werknemers) aandelen tegen lagere prijzen dan de markt kan kopen is de winst vermoedelijk nog groter.

In Amerika is het erg normaal dat CEO's van grote bedrijven voornamelijk in aandelen betaald worden. Zo omzeilen ze een hoop regels en belastingen. De CEO's verkopen hun aandelen doorgaans ook regelmatig om zo toch aan inkomsten te komen in plaats van salaris. CEO's mogen onder Amerikaanse wetgeving ook niet zomaar hun aandelen verkopen. Dit had hij ver van te voren moeten regelen en goedkeuring voor krijgen. Een CEO kan niet in paniek zijn/haar aandelen dumpen. CEO's moeten daarvoor een berg aan papierwerk invullen, welke openbaar is. Als je de historie opzoekt van het verkoop gedrag van de CEO van Intel zal je zien dat hij dit regelmatig doet.

Dit is denk ik een logischere verklaring dan een alu hoedje.

Voor wat betreft de performance degradatie zal het mogelijk niet zo extreem worden. Uit de releasenotes van de 10 november versie van de Linux patch:

Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.

Bron

Tenzij je bergen aan syscalls en context switches hebt zal de soep niet zo heet gegeten worden.

[Dennism]

Tadream schreef op woensdag 3 januari 2018 @ 18:02:
Pfff als dit echt zo erg is als er beweerd wordt, dan wordt dat nog wat voor onze VMware omgeving.
Dan komen er dus patches voor de vmware kernel en bovenop de Windows/Linux servers, we hebben ook maar ongeveer 99 virtuele servers (van SQL, domain controllers tot RDS servers) draaien dus valt wel mee (not).

Ik mag toch hopen dat dit geen echt issue is, of update je de omgeving nu nooit VMware patches gaan gewoon via VUM of een Update release, Windows komt voor zover ik begrepen heb met de volgende patch tuesday mee en linux zal ook gewoon te updaten zijn met de gebruikelijke tools voor de distro die je draait (of zelf een kernel bakken als dat doet). Een kleine 100VM's en wat hosts is nu ook weer niet zo spannend

De blades zijn inmiddels 4 jaar oud, zouden nog wel even mee kunnen maar als het 30-50% performance gaat opslokken dan denk ik dat we die vervangingsronde mogelijk sneller gaan doen en serieus naar AMD gaan kijken.
Maar goed, eerst maar even aankijken hoe het zich allemaal ontwikkeld.

30-50% zou ik niet direct vanuit gaan over de gehele linie, ik heb 50% gezien in synthetische tests met binaries die enkel syscalls uitvoeren, dat lijkt dus +- het worst case scenario te worden, 5 tot 30% afhankelijk van workload en cpu model zijn nu real world nummers die je het meeste leest in de geruchten op Linux. Windows performance nummers zouden ook snel moeten kunnen komen, fast-ring zou de benodigde updates al hebben. Dat er nog geen riots zijn uitgebroken over ingestorte performance bij fast-ring gebruikers zie ik tot de daadwerkelijk performance nummers komen nog maar even als positief.

[CMD-Snake]

Dennism schreef op woensdag 3 januari 2018 @ 18:28:
linux zal ook gewoon te updaten zijn met de gebruikelijke tools voor de distro die je draait (of zelf een kernel bakken als dat doet).

De vraag is ook maar of AMD gaat ontsnappen aan deze patch, hun voorstel voor een patch in de Linux kernel om zichzelf te vrijwaren is (op dit moment) niet geaccepteerd. Tenzij dat gebeurt moet AMD gewoon meedoen met de rest. De vraag is ook hoe snel deze aanpassing als security update meekomt naar de verschillende Enterprise Linux distro's als Red Hat. RHEL 7 zit op de 3.10 Linux Kernel en RHEL 6.9 op 2.4. SUSE 12 heeft de 3.12 kernel.

Op Windows heeft AMD geen invloed, dus als Microsoft dit probleem generiek adresseert zal ook AMD er last van hebben.

[Dennism]

CMD-Snake schreef op woensdag 3 januari 2018 @ 18:34:
[...]


De vraag is ook maar of AMD gaat ontsnappen aan deze patch, hun voorstel voor een patch in de Linux kernel om zichzelf te vrijwaren is (op dit moment) niet geaccepteerd. Tenzij dat gebeurt moet AMD gewoon meedoen met de rest. De vraag is ook hoe snel deze aanpassing als security update meekomt naar de verschillende Enterprise Linux distro's als Red Hat. RHEL 7 zit op de 3.10 Linux Kernel en RHEL 6.9 op 2.4. SUSE 12 heeft de 3.12 kernel.

Op Windows heeft AMD geen invloed, dus als Microsoft dit probleem generiek adresseert zal ook AMD er last van hebben.

Er even van uitgaande dat dit de enorme impact gaat hebben waar volgens de geruchten voor gevreesd moet worden zullen die distro's wel mee moeten anders zijn ze gewoon weg niet veilig meer in enterprise omgevingen / (shared) cloud omgevingen. Daar zullen ze dan vast wel iets voor backporten of iets in die richting.

Als het toch een storm in een glas blijkt te zijn dan uiteraard mogelijk niet.Maar daar ga ik tot er definitief nieuws komt (ik las ergens dat vandaag 13:00 PST het embargo zou vervallen) niet van uit.

[Tadream]

Dennism schreef op woensdag 3 januari 2018 @ 18:28:
[...]
Ik mag toch hopen dat dit geen echt issue is, of update je de omgeving nu nooit VMware patches gaan gewoon via VUM of een Update release, Windows komt voor zover ik begrepen heb met de volgende patch tuesday mee en linux zal ook gewoon te updaten zijn met de gebruikelijke tools voor de distro die je draait (of zelf een kernel bakken als dat doet). Een kleine 100VM's en wat hosts is nu ook weer niet zo spannend

Nee ik bedoelde ook niet het updaten zelf, dat doen we uiteraard regelmatig. Maar meer alles bij elkaar opgeteld dat je wellicht toch wel die performance impact gaat voelen.
Wat dacht je van SQL enterprise licenties - stel je gaat een 30% achteruit (zo hard zal het wellicht niet gaan, maar als er 1000 man daardoor langer moeten wachten op rapportjes, berekeningen enz) en je hebt 2 of meer extra core licenties nodig, dat gaat aardig in de papieren lopen. Alleen maar even door een fix doorvoeren.
Het gaat me niet om het patchen op zich maar de impact daarna.

[Enchantress]

Gaan we nu zien dat bedrijven massaal naar AMD gaan?
Neem aan dat juist bedrijven hier niet echt gecharmeerd van zijn.

[Dennism]

Tadream schreef op woensdag 3 januari 2018 @ 18:42:
[...]


Nee ik bedoelde ook niet het updaten zelf, dat doen we uiteraard regelmatig. Maar meer alles bij elkaar opgeteld dat je wellicht toch wel die performance impact gaat voelen.
Wat dacht je van SQL enterprise licenties - stel je gaat een 30% achteruit (zo hard zal het wellicht niet gaan, maar als er 1000 man daardoor langer moeten wachten op rapportjes, berekeningen enz) en je hebt 2 of meer core licenties nodig, dat gaat aardig in de papieren lopen. Alleen maar even door een fix doorvoeren.
Het gaat me niet om het patchen op zich maar de impact daarna.

Daar heb je uiteraard gelijk in, afhankelijk van de daadwerkelijke performance impact kan dit zeker invloed gaan hebben op je infra en resource toewijzing en de daarbij behorende kosten.

[Dennism]

Enchantress schreef op woensdag 3 januari 2018 @ 18:43:
Gaan we nu zien dat bedrijven massaal naar AMD gaan?
Neem aan dat juist bedrijven hier niet echt gecharmeerd van zijn.

Dat zal imho vooral aan een aantal factoren liggen:

1. De daadwerkelijke impact.
2. De geboden oplossingen om die impact zoveel mogelijk te mitigeren.
3. De permanente oplossing vanuit Intel, als bijv. nieuwe generaties ook flink aan performance gaan verliezen hierdoor zal ook zeker weer impact hebben. Als Intel met een hardwarematige fix komt in nieuwe generaties die geen performance impact heeft, en mogelijk (geen idee of dit mogelijk is) het misschien kan fixen in een nieuwe revisie van de huidige chips dan zal die impact mogelijk minder zijn.

Maar ongunstig zal dit zeker voor AMD niet zijn, maar ik verwacht ook niet dat de komende weken alle klanten gaan bellen "ik wil nu alles vervangen voor AMD". Maar dit kan zeker op zijn minst twijfelaars over de streep trekken richting AMD.

[CMD-Snake]

Dennism schreef op woensdag 3 januari 2018 @ 18:41:
Er even van uitgaande dat dit de enorme impact gaat hebben waar volgens de geruchten voor gevreesd moet worden zullen die distro's wel mee moeten anders zijn ze gewoon weg niet veilig meer in enterprise omgevingen / (shared) cloud omgevingen. Daar zullen ze dan vast wel iets voor backporten of iets in die richting.

Ongetwijfeld gaan ze het patchen, maar het zal mogelijk wat langer duren. Er zal ook de nodige QA gedaan moeten worden voordat je de patch naar je Enterprise klanten kan sturen.

Dennism schreef op woensdag 3 januari 2018 @ 18:50:
1. De daadwerkelijke impact.
2. De geboden oplossingen om die impact zoveel mogelijk te mitigeren.
3. De permanente oplossing vanuit Intel, als bijv. nieuwe generaties ook flink aan performance gaan verliezen hierdoor zal ook zeker weer impact hebben. Als Intel met een hardwarematige fix komt in nieuwe generaties die geen performance impact heeft, en mogelijk (geen idee of dit mogelijk is) het misschien kan fixen in een nieuwe revisie van de huidige chips dan zal die impact mogelijk minder zijn.

Maar ongunstig zal dit zeker voor AMD niet zijn, maar ik verwacht ook niet dat de komende weken alle klanten gaan bellen "ik wil nu alles vervangen voor AMD". Maar dit kan zeker op zijn minst twijfelaars over de streep trekken richting AMD.

Laten we wel wezen, ik denk dat 99% van de Intel gebaseerde desktops niets gaan merken van de patch. Voor servers zijn de consequenties wel interessanter om te volgen.

De vraag is wel hoe deze patches die nu in de maak zijn in de toekomst omgaan met CPU's die niet deze kwestbaarheid hebben, de Linux oplossing is heel generiek in feite en pakt nu alle x86 CPU's aan als onveilig.

Toch is zomaar een switch naar AMD ook niet altijd een optie. Bij VMWare kan je geen VM die gemaakt is op een Intel gebaseerde host een vMotion laten doen naar een AMD gebaseerde host. De VM is dan morsdood. Sinds ESXi 5.5. heeft VMWare hier wel iets voor bedacht, maar de performance impact daarvan is gigantisch. Je moet dan namelijk vrijwel alle features van de CPU verbergen voor de VM. Een Intel VMWare cluster kan je dus niet goed migreren naar een AMD cluster, die klanten zullen dus eerder dan wachten tot Intel met een revisie komt waar deze kwetsbaarheid niet in zit.

[Dennism]

CMD-Snake schreef op woensdag 3 januari 2018 @ 19:07:

Toch is zomaar een switch naar AMD ook niet altijd een optie. Bij VMWare kan je geen VM die gemaakt is op een Intel gebaseerde host een vMotion laten doen naar een AMD gebaseerde host. De VM is dan morsdood. Sinds ESXi 5.5. heeft VMWare hier wel iets voor bedacht, maar de performance impact daarvan is gigantisch. Je moet dan namelijk vrijwel alle features van de CPU verbergen voor de VM. Een Intel VMWare cluster kan je dus niet goed migreren naar een AMD cluster, die klanten zullen dus eerder dan wachten tot Intel met een revisie komt waar deze kwetsbaarheid niet in zit.

Dat is niet geheel waar.
Live vMotion inderdaad niet, je kan geen VM's live verhuizen tussen vendoren. Je kan de machines echter prima uitzetten en dan migreren, als je je application level HA op orde hebt kan dat zelfs zonder (grote) impact op de omgeving. Ook kun je bijv. VMware of bijv. Veeam Replicatie gebruiken, repliceren, uitzetten, snelle 2de replicatie voor de laatste changes en dan booten op de nieuwe omgeving, op oudere ESXI versies moest je volgens mij nog ht CPUID resetten zodat deze bij de eerste poweron opnieuw gedetecteerd werd, echter hoeft dit volgens mij bij nieuwere versies niet meer en gaat dit automatisch bij de eerste boot.

[Verwijderd]

CMD-Snake schreef op woensdag 3 januari 2018 @ 18:05:
Dit is denk ik een logischere verklaring dan een alu hoedje.

Zowel in het artikel als in mijn reactie daarop was er geen sprake van alu-hoedje, wat dat ook moge betekenen voor jou. Er werd op gewezen dat het opvalt dat hij zoveel mogelijk aandelen verkocht terwijl werd verwacht dat de aandelenkoers sterk zou stijgen. Nogmaals, dit was in november, dus voordat deze kwestie voor het grote publiek speelde. Deze 'verdachtmaking' werd dus al geuit voordat deze kwestie speelde. Niemand stelt dat bewezen is dat hij schuldig is, we houden slechts in het achterhoofd dat het mogelijk is dat hij de aandelen verkocht omdat hij wist dat deze kwestie binnenkort bekend zou worden bij het grote publiek. Schrödinger's kat, je veronderstelt niet dat het leeft of dat het dood is, je houdt het in het midden. No offense, ik heb bij jou vaker de indruk dat jij denkt dat een ander altijd het een of het ander veronderstelt (ofwel denkt hij dat die kat dood is ofwel denkt hij dat die kat levend is) terwijl een ander het soms gewoon in het midden laat.

De CEO verdiende 11 miljoen dollar aan de verkoop van de aandelen. Dankzij de gunstige belastingwetgeving waar deze transactie onder valt bespaart hij 550.000 dollar aan belasting betalen.

De extra waarde door de koersstijging die werd verwacht was waarschijnlijk aanzienlijk meer dan dat. Hij had mogelijk redenen om geen koersstijging te verwachten, een van de mogelijke verklaringen daarvoor is dat hij wist dat er slecht nieuws bekend zou worden over Intel. Er zijn natuurlijk meer mogelijke verklaringen (de concurrentie van AMD en het niet goed vorderen van hun 10 nm. node bijvoorbeeld).

Jouw bron haalt niets aan wat we niet al wisten. Sterker nog, op basis van de uitleg die hier ook al meermaals is herhaald over waarom je een verminderde performance zal krijgen viel direct af te leiden wat in die bron wordt vermeld: dat de vermindering van de performance afhangt van de load, concreet van hoeveel data uit de RAM moet worden gehaald en in de cache wordt opgeslagen. Bij sommige taken is dat 30% of mogelijk zelfs 50% (zie Foppe zijn bron), voor het totale gebruik van de CPU bij de doorsnee persoon zal het inderdaad eerder ergens tussen de 1 en de 10% zijn. Voor bepaalde groepen gebruikers zal de performance sterker verminderen, mogelijk dat bijvoorbeeld bij cloud/virtuele machines de performance sterker vermindert. Ik ben ook benieuwd hoe het gaming uitpakt, het zou me niet verbazen als voor gaming de impact groter is dan bij veel andere taken aangezien er bij gaming zeer veel taken per seconde worden uitgevoerd en er veel met data wordt geschoven. Even rustig afwachten. Ondertussen krijgt Ryzen over een maandje minstens 10% erbij terwijl de prijs nog steeds aanzienlijk lager is. Al met al erg vervelend voor Intel.

[ Voor 54% gewijzigd door Verwijderd op 03-01-2018 19:57 ]

[Sp3ci3s8472]

CMD-Snake schreef op woensdag 3 januari 2018 @ 19:07:
[...]


Ongetwijfeld gaan ze het patchen, maar het zal mogelijk wat langer duren. Er zal ook de nodige QA gedaan moeten worden voordat je de patch naar je Enterprise klanten kan sturen.


[...]


Laten we wel wezen, ik denk dat 99% van de Intel gebaseerde desktops niets gaan merken van de patch. Voor servers zijn de consequenties wel interessanter om te volgen.

De vraag is wel hoe deze patches die nu in de maak zijn in de toekomst omgaan met CPU's die niet deze kwestbaarheid hebben, de Linux oplossing is heel generiek in feite en pakt nu alle x86 CPU's aan als onveilig.

Toch is zomaar een switch naar AMD ook niet altijd een optie. Bij VMWare kan je geen VM die gemaakt is op een Intel gebaseerde host een vMotion laten doen naar een AMD gebaseerde host. De VM is dan morsdood. Sinds ESXi 5.5. heeft VMWare hier wel iets voor bedacht, maar de performance impact daarvan is gigantisch. Je moet dan namelijk vrijwel alle features van de CPU verbergen voor de VM. Een Intel VMWare cluster kan je dus niet goed migreren naar een AMD cluster, die klanten zullen dus eerder dan wachten tot Intel met een revisie komt waar deze kwetsbaarheid niet in zit.

Dat komt dicht in de buurt van een vendor lock in. Dat zullen ze leuk vinden .

Edit:
Met de consumenten versie heb je hier minder last van, ik heb mijn VM prima kunnen poorten van Intel (i5-4670k) naar een AMD Ryzen 1700x. Je sessie ben je natuurlijk wel kwijt.
Hoe zit dat met de grotere clusters?

Als je 30% performance impact heb op je hele cloud... dat is wel wat anders... Google, MS en andere grote cloud providers zullen dit niet leuk vinden.

[ Voor 11% gewijzigd door Sp3ci3s8472 op 03-01-2018 19:39 ]

[Dennism]

Sp3ci3s8472 schreef op woensdag 3 januari 2018 @ 19:35:
[...]


Dat komt dicht in de buurt van een vendor lock in. Dat zullen ze leuk vinden .

Als het inderdaad zo zou zijn inderdaad wel, maar gelukkig kun je prima VM's verhuizen van Intel naar AMD of omgekeerd wanneer nodig zonder al te veel impact mits je maar correct planned. Als je nieuwe (bijv AMD) cluster bij de storage kan waar de huidige VM's op draaien op het oude cluster (bijv. Intel) is het een kwestie van een paar minuten downtime per VM (afsluiten, eventueel CPUID resetten wanneer nodig, overzetten naar nieuwe cluster en booten). Kunnen je nieuwe hosts niet bij de oude storage is het wat vervelender want dan moet je of een offline storage migratie doen (duurt lang) of een extra stap ondernemen met replicatie. Maar in geen van alle gevallen is het echt lastig, hoogstens wat meer tijdrovend of arbeidsintensief. Als je HA op Applicatie niveau goed op orde voor al je applicaties / databases en fileservers e.d. hebt kan het in principe zelfs zonder dat je gebruikers er wat van merken.

[ Voor 13% gewijzigd door Dennism op 03-01-2018 19:44 ]

[CMD-Snake]

Dennism schreef op woensdag 3 januari 2018 @ 19:22:
Live vMotion inderdaad niet, je kan geen VM's live verhuizen tussen vendoren. Je kan de machines echter prima uitzetten en dan migreren, als je je application level HA op orde hebt kan dat zelfs zonder (grote) impact op de omgeving. Ook kun je bijv. VMware of bijv. Veeam Replicatie gebruiken, repliceren, uitzetten, snelle 2de replicatie voor de laatste changes en dan booten op de nieuwe omgeving, op oudere ESXI versies moest je volgens mij nog ht CPUID resetten zodat deze bij de eerste poweron opnieuw gedetecteerd werd, echter hoeft dit volgens mij bij nieuwere versies niet meer en gaat dit automatisch bij de eerste boot.

Volgens mij loop je dan bij Windows wel tegen problemen met de HAL aan. Voor Intel en AMD processoren gebruikt Windows een andere HAL, dat is iets wat je niet naderhand kan veranderen in een installatie.

Het blijft vooral een theoretische discussie omdat bedrijven hun VMWare clusters zoveel mogelijk identiek proberen te houden en niet geen mengelmoesjes hebben.

Verwijderd schreef op woensdag 3 januari 2018 @ 19:23:
Deze 'verdachtmaking' werd dus al geuit voordat deze kwestie speelde. Niemand stelt dat bewezen is dat hij schuldig is, we houden slechts in het achterhoofd dat het mogelijk is dat hij de aandelen verkocht omdat hij wist dat deze kwestie binnenkort bekend zou worden bij het grote publiek.

Als je naar zijn historie kijkt doet hij dit vaker. Het zal denk ik eerder zijn om aan geld te komen of om zijn portfolio te diverseren. De nieuwe belastingregels zullen ook een handje helpen om zoveel mogelijk transacties in 2017 te laten plaatsvinden.

Schrödinger's kat, je veronderstelt niet dat het leeft of dat het dood is, je houdt het in het midden. No offense, ik heb bij jou vaker de indruk dat jij denkt dat een ander altijd het een of het ander veronderstelt (ofwel denkt hij dat die kat dood is ofwel denkt hij dat die kat levend is) terwijl een ander het soms gewoon in het midden laat.

Schrödingers kat was nooit bedoeld door Schrödinger als serieus idee, het gedachte experiment moest de absurditeit aantonen dat iets in alle staten zich bevond simpelweg omdat er niet naar gekeken werd. Dit gedachte experiment was onderdeel van zijn kritiek op de Kopenhagen interpretatie van kwantum mechanica. Niet echt een goede vergelijking dus.

Jouw bron haalt niets aan wat we niet al wisten. Sterker nog, op basis van de uitleg die hier ook al meermaals is herhaald over waarom je een verminderde performance zal krijgen viel direct af te leiden wat in die bron wordt vermeld: dat de vermindering van de performance afhangt van de load, concreet van hoeveel data uit de RAM moet worden gehaald en in de cache wordt opgeslagen. Bij sommige taken is dat 30% of mogelijk zelfs 50% (zie Foppe zijn bron), voor het totale gebruik van de CPU bij de doorsnee persoon zal het inderdaad eerder ergens tussen de 1 en de 10% zijn. Voor bepaalde groepen gebruikers zal de performance sterker verminderen, mogelijk dat bijvoorbeeld bij cloud/virtuele machines de performance sterker vermindert. Ik ben ook benieuwd hoe het gaming uitpakt, het zou me niet verbazen als voor gaming de impact groter is dan bij veel andere taken aangezien er bij gaming zeer veel taken per seconde worden uitgevoerd en er veel met data wordt geschoven. Even rustig afwachten. Ondertussen krijgt Ryzen over een maandje minstens 10% erbij terwijl de prijs nog steeds aanzienlijk lager is. Al met al erg vervelend voor Intel.

Je kan altijd dromen denk ik dan. De extreme gevallen heb ik al op Reddit gezien, maar men zoekt daar wel bewust op extreme scenario's. Syscalls spammen en vergelijkbare zaken. Uiteraard heb je zulke toepassingen, maar die zullen niet de meerderheid uitmaken.

Sp3ci3s8472 schreef op woensdag 3 januari 2018 @ 19:35:
Dat komt dicht in de buurt van een vendor lock in. Dat zullen ze leuk vinden .

Het is geen vendor lock in, het is eerder een beperking in de software. Niemand dwingt om Intel servers te gebruiken. Alleen het idee van een cluster is natuurlijk dat je VM's live kunnen migreren tussen hosts om zo performance en beschikbaarheid zoveel mogelijk te garanderen.

[Dennism]

CMD-Snake schreef op woensdag 3 januari 2018 @ 19:48:
[...]


Volgens mij loop je dan bij Windows wel tegen problemen met de HAL aan. Voor Intel en AMD processoren gebruikt Windows een andere HAL, dat is iets wat je niet naderhand kan veranderen in een installatie.

Het blijft vooral een theoretische discussie omdat bedrijven hun VMWare clusters zoveel mogelijk identiek proberen te houden en niet geen mengelmoesjes hebben.

Dat is voor zover ik weet al sinds 2008 (of 2008 R2) niet meer zo, ik zou zeggen probeer het maar eens, zul je zien dat het geheel geen issue is Ik heb toch echt een aantal Opteron > Intel cluster migraties zeer makkelijk op deze wijze uitgevoerd.

Daarnaast is het ook niet echt theoretisch. Genoeg full cluster migraties van opteron > Intel die op deze wijze gegaan zijn en van Intel > Epyc zullen die er ook zeker gaan komen. Dat bedrijven hun clusters zoveel mogelijk identiek willen houden klopt uiteraard, je zal dan ook in de regel niet tegenkomen dat er bijv. 1 Epyc host in een Intel omgeving bijgezet zal worden om alle genoemde redenen. Maar migraties waarbij bedrijven ineens van een Intel cluster met meerdere hosts naar een Epyc cluster met meerdere hosts gaan die ga je echt wel zien de komende jaren.

[CMD-Snake]

Dennism schreef op woensdag 3 januari 2018 @ 20:06:
Dat is voor zover ik weet al sinds 2008 (of 2008 R2) niet meer zo, ik zou zeggen probeer het maar eens, zul je zien dat het geheel geen issue is Ik heb toch echt een aantal Opteron > Intel cluster migraties zeer makkelijk op deze wijze uitgevoerd.

Ik heb geen AMD CPU's, dus ik kan het helaas niet zelf proberen.

[TheBorg]

En de grap is, als cloud dienst provider ben je misschien wel het goedkoopste uit als je oude CPU's gaat swappen voor nieuwe in plaats van 30% servers bijplaatsen. Extra omzet voor Intel.

[Enchantress]

''Intel Corporation (NASDAQ:INTC) shares are dipping nearly 6% after tech investors caught word of a glitch in the chip maker’s processors, the liability of which could cost Intel big time. A bear wagers no matter what new PCs are sold to customers to which server computers use Intel chips, the risk here gravely negates the reward. In reaction, Advanced Micro Devices, Inc. (NASDAQ:AMD) investors are seizing on today’s crack in the rival’s sentiment, sending surging 9%.

Bernstein analyst Stacy Rasgon believes the liability could be as rough as the Pentium FDIV bug from the early ’90s and calls this prospective liability “the biggest open-ended question we have at the moment.”

Therefore, the analyst reiterates an Underperform rating on INTC stock with a $34 price target, which implies a nearly 23% downside from current levels. (To watch Rasgon’s track record, click here)

“For Intel, we believe the negative (charges, potential ongoing liability, possible share loss etc) outweighs the potentially positive (if you want to call it that) of a possible accelerated replacement cycle,” explains Rasgon.

In fact, the analyst adds, “Even if new processors are desired, we struggle to believe that Intel won’t face some sort of financial liability. We note for example the Pentium FDIV bug back in 1994, where the company faced problems with the floating-point unit on some versions of their early Pentium chips; the company took a $475M charge (equivalent to the replacement cost of the flawed processors) and offered replacements as desired. We also recall the Cougar Point chipset issue in 2011 (with a ~$700M charge taken). The current problem feels much bigger ($475M would have replaced perhaps 5-10M processors back in 1994, and the Cougar Point issue affected ~8M units, while the affected PC installed base today is in the hundreds of millions of units).”

How can AMD stand to benefit from Intel’s stumble? Consider that “the flaw may increase the desire of the ecosystem to explore alternatives,” writes Rasgon, who likewise notes that this then provides “them a further opening as they launch new products that are not affected by the bug.”

For now, even as the analyst sees INTC’s loss as AMD’s gain, he remains sidelined on today’s chip maker winner, reiterating a Market Perform rating on AMD stock with an $8 price target, which implies a 33% downside from current levels.

Will performance impact Intel’s product line as a chain reaction to the glitch’s resolution and will this allow AMD to “further close the gap” in the server arena? Rasgon is keeping his eyes peeled.

Rosenblatt analyst Hans Mosesmann likewise echoes Rasgon’s bearish perspective on Intel’s bad CPU news, noting that as rumors are flying, it is clear this “hardware security bug […] could open the door for hacker attacks.”

Additionally, “ARM-based CPUs may have a similar bug while AMD […] Zen-based CPUs do not,” the analyst highlights, which is a clear advantage for AMD here.

On back of the Intel CPU bug disaster, the analyst reiterates a Sell rating on INTC stock without listing a price target and stays the bullish course on its chip competitor, maintaining a Buy rating on AMD stock with a price target of $22, which implies a nearly 84% upside from current levels. (To watch Mosesmann’s track record, click here)

“From what we understand so far, there is no easy software driver patch to the problem and requires an operating system kernel redesign for Linux (appears completed), Windows,” writes Mosesmann, a strike against Intel.

For context, the analyst says to bear in mind the same ’90s bug that Rasgon mentions; a bug that cost Intel almost a whopping $500 million to replace the defective CPUs at the time. “The current Intel problem, if true, would likely not require CPU replacement in our opinion. However the situation is fluid. Regardless, here are the issues Intel may have to contend with all of which are non-trivial.”

The challenges Mosesmann spots ahead boil down to four key issues confronting Intel:

“1. Potential indemnification to harm or costs customers may have incurred.

2. O/S fixes apparently come at the expense of significant performance degradation in Intel CPUs.

3. Customers on the fence regarding the use of AMD EPYC/Ryzen CPUs would see an easier transition to engage with AMD.

4. Reputation hit.”

Time will tell if today’s bug haunts Intel in the same way as the ’90s one that cost hundreds of millions of dollars; but for now, AMD bulls are rejoicing as Intel shareholders are left gritting their teeth with a sharp setback.''

https://www.smarteranalys...erver-gap-analysts-weigh/

[maratropa]

reactie intel lees ik op de fp

https://newsroom.intel.co...curity-research-findings/

Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.

Intel is committed to the industry best practice of responsible disclosure of potential security issues, which is why Intel and other vendors had planned to disclose this issue next week when more software and firmware updates will be available. However, Intel is making this statement today because of the current inaccurate media reports.

Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. Following good security practices that protect against malware in general will also help protect against possible exploitation until updates can be applied.

Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.

[ Voor 90% gewijzigd door maratropa op 03-01-2018 21:38 ]

[FouT]

Spreken ze zichzelf niet tegen in die press release?

Intel believes these exploits do not have the potential to corrupt, modify or delete data.

vs

Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. Following good security practices that protect against malware in general will also help protect against possible exploitation until updates can be applied.

[CMD-Snake]

FouT schreef op woensdag 3 januari 2018 @ 21:47:
Intel believes these exploits do not have the potential to corrupt, modify or delete data.

vs

Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. Following good security practices that protect against malware in general will also help protect against possible exploitation until updates can be applied.

Dit soort teksten zijn dan erg Amerikaans, ze geven nooit 100% zekerheid. Vermoedelijk dan om te voorkomen dat teksten tegen hun gebruikt worden.

[FouT]

CMD-Snake schreef op woensdag 3 januari 2018 @ 22:01:
[...]


Dit soort teksten zijn dan erg Amerikaans, ze geven nooit 100% zekerheid. Vermoedelijk dan om te voorkomen dat teksten tegen hun gebruikt worden.

Dat is natuurlijk ook weer zo, en een sterk spelletje share the blame door wat concurrenten te benoemen natuurlijk

[CMD-Snake]

FouT schreef op woensdag 3 januari 2018 @ 22:11:
Dat is natuurlijk ook weer zo, en een sterk spelletje share the blame door wat concurrenten te benoemen natuurlijk

Dat hoeft niet, er is nog weinig echt bekend gemaakt over hoe de bug werkt. Als enkel Intel getroffen is, waarom dan zoveel andere bedrijven noemen?

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Deze tekst ga je namelijk dan ook niet zomaar neerzetten. Dit maakt mij steeds benieuwder naar wat er nu daadwerkelijk mis is.

[RedShift]

Voor de duidelijkheid, de press release van Intel is damage control. AMD CPU's hebben deze bug wel degelijk niet, en het is ook nog niet bewezen dat andere processoren (ARM, ...) ook deze bug hebben. Het zit hem echt wel in het CPU ontwerp van Intel, waar men "fast and loose" heeft gespeeld met de data die opgevraagd mag worden tijdens de speculative execution fase.

[ Voor 0% gewijzigd door RedShift op 03-01-2018 22:33 . Reden: Spelling ]

[Verwijderd]

maratropa schreef op woensdag 3 januari 2018 @ 21:37:
Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Leugen en spinning. "many different vendors' processors", Intel maakt handig misbruik van het feit dat mogelijk ook ARM getroffen wordt en suggeert zo dat Zen er ook mee te maken heeft zonder het expliciet te zeggen. Technisch liegen ze niet maar ze wekken wel de verkeerde indruk. Verder is het raar dat Intel benadrukt dat meerdere besturingssystemen erbij betrokken zijn. D'uh, als het aan de CPU ligt dan heeft elke BS er last van.
+ dit

FouT schreef op woensdag 3 januari 2018 @ 21:47:
Spreken ze zichzelf niet tegen in die press release?

Intel believes these exploits do not have the potential to corrupt, modify or delete data.

vs

Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. Following good security practices that protect against malware in general will also help protect against possible exploitation until updates can be applied.

Inderdaad, juridische spelletjes. Niet toegeven dat het een kwetsbaarheid is omwille van de juridische consequenties. Tegelijkertijd waarschuwen voor...omwille van de juridische consequenties.

[ Voor 38% gewijzigd door Verwijderd op 03-01-2018 22:41 ]

[Verwijderd]

CMD-Snake schreef op woensdag 3 januari 2018 @ 22:32:
[...]


Dat hoeft niet, er is nog weinig echt bekend gemaakt over hoe de bug werkt.

AMD was vrij duidelijk. "speculative references". Iemand anders hier wees er al op, bij AMD weten ze heus wel hoe de hardware van Intel werkt en vice versa.


From Tom Lendacky <>
Subject [PATCH] x86/cpu, x86/pti: Do not enable PTI on AMD processors
Date Tue, 26 Dec 2017 23:43:54 -0600


share 0
share 2k

AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.

Signed-off-by: Tom Lendacky <[e-mail]>
---
arch/x86/kernel/cpu/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c47de4e..7d9e3b0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)

setup_force_cpu_cap(X86_FEATURE_ALWAYS);

- /* Assume for now that ALL x86 CPUs are insecure */
- setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+ if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

fpu__init_system(c);

[ Voor 4% gewijzigd door Verwijderd op 03-01-2018 22:44 ]

[CMD-Snake]

RedShift schreef op woensdag 3 januari 2018 @ 22:33:
Voor de duidelijkheid, de press release van Intel is damage control. AMD CPU's hebben deze bug wel degelijk niet, en het is ook nog niet bewezen dat andere processoren (ARM, ...) ook deze bug hebben. Het zit hem echt wel in het CPU ontwerp van Intel, waar men "fast and loose" heeft gespeeld met de data die opgevraagd mag worden tijdens de speculative execution fase.

Maar waar is het bewijs? Niemand heeft nog een goede beschrijving van wat er mis gaat of misbruikt kan worden. Alles wordt vaag gehouden omdat er nog een embargo is. Het blijft speculatie.

Dit soort persberichten worden heel zorgvuldig geformuleerd, daarom zou ik ook niet meteen denken dat ze dit zomaar schrijven. Als de bug vrijgegeven wordt komt meteen het bewijs dat je hard gelogen hebt.

Toch als de bug zo oud is als men beweert is dit tientallen jaren niet opgemerkt gebleven.

Verwijderd schreef op woensdag 3 januari 2018 @ 22:38:
Leugen en spinning. "many different vendors' processors", Intel maakt handig misbruik van het feit dat mogelijk ook ARM getroffen wordt en suggeert zo dat Zen er ook mee te maken heeft zonder het expliciet te zeggen. Technisch liegen ze niet maar ze wekken wel de verkeerde indruk.

Wat heeft ARM met AMD te maken? De enige link is de gedeelde geschiedenis van Intel en AMD dat AMD Intel CPU's in licentie kon maken. Dan zou het kunnen dat zo de fout ook meegenomen is in AMD ontwerpen. Of ze hebben het over Cyrix of VIA.

Ik lees hier ook niet meteen AMD in. Maar het is wel frappant hoeveel technologie bedrijven samenwerken. Waarom zou AMD Intel gaan helpen met een ontwerpfout in hun product? Dat is onzinnig vanuit een concurrentie perspectief.

Verwijderd schreef op woensdag 3 januari 2018 @ 22:43:
- /* Assume for now that ALL x86 CPUs are insecure */

Het is dan ook lastig te begrijpen waarom het Linux kernel team alle x86 CPU's meteen als onveilig markeert. Dan hadden ze ook zelf met de AMD code kunnen komen omdat ze enkel Intel modellen moeten hebben.

[ Voor 9% gewijzigd door CMD-Snake op 03-01-2018 22:46 ]

[Verwijderd]

CMD-Snake schreef op woensdag 3 januari 2018 @ 22:44:
[...]


Maar waar is het bewijs? Niemand heeft nog een goede beschrijving van wat er mis gaat of misbruikt kan worden. Alles wordt vaag gehouden omdat er nog een embargo is. Het blijft speculatie.

Dit soort persberichten worden heel zorgvuldig geformuleerd, daarom zou ik ook niet meteen denken dat ze dit zomaar schrijven. Als de bug vrijgegeven wordt komt meteen het bewijs dat je hard gelogen hebt.

Toch als de bug zo oud is als men beweert is dit tientallen jaren niet opgemerkt gebleven.


[...]


Wat heeft ARM met AMD te maken?

Niets in deze context.
Het leek me nogal duidelijk. Naar verluidt zou ook ARM mogelijk deze kwetsbaarheid hebben, Intel suggereert dat Ryzen ook die kwetsbaarheid heeft door te roepen dat ook andere CPU's getroffen worden. Technisch gezien spreekt Intel de waarheid als ARM ook deze kwetsbaarheid heeft maar Ryzen heeft er geen drol mee te maken. A vertellen om B te suggereren hopende dat mensen B denken terwijl je B niet bedoelt. Ofwel spinningspelletjes en lie by omission (wat gewoon liegen is).

[ Voor 5% gewijzigd door Verwijderd op 03-01-2018 22:48 ]

[RedShift]

CMD-Snake schreef op woensdag 3 januari 2018 @ 22:44:
[...]


Maar waar is het bewijs? Niemand heeft nog een goede beschrijving van wat er mis gaat of misbruikt kan worden. Alles wordt vaag gehouden omdat er nog een embargo is. Het blijft speculatie.

Dit soort persberichten worden heel zorgvuldig geformuleerd, daarom zou ik ook niet meteen denken dat ze dit zomaar schrijven. Als de bug vrijgegeven wordt komt meteen het bewijs dat je hard gelogen hebt.

Toch als de bug zo oud is als men beweert is dit tientallen jaren niet opgemerkt gebleven.


[...]

Het The Register artikel legt het glashelder uit en de code is er. En de patch die AMD gesubmit heeft, het commentaar daar bij geeft eigenlijk al enorm veel prijs:

The AMD microarchitecture does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

Ik had ergens anders ook nog de precieze uitleg gelezen van wat er gaande was, ik ben nu even de link kwijt. Maar het komt er op neer dat een bepaalde check die de processor normaal zou moeten uitvoeren of dat een bepaalde instructie wel toegang heeft tot het gevraagde geheugenadres, niet uitgevoerd wordt in de speculative execution fase.

[foppe-jan]

offtopic:
haha: https://twitter.com/BryanLunduke/status/948432831004360704

[ Voor 6% gewijzigd door foppe-jan op 03-01-2018 23:11 ]

[Dennism]

Verwijderd schreef op woensdag 3 januari 2018 @ 22:47:
[...]

Niets in deze context.
Het leek me nogal duidelijk. Naar verluidt zou ook ARM mogelijk deze kwetsbaarheid hebben, Intel suggereert dat Ryzen ook die kwetsbaarheid heeft door te roepen dat ook andere CPU's getroffen worden. Technisch gezien spreekt Intel de waarheid als ARM ook deze kwetsbaarheid heeft maar Ryzen heeft er geen drol mee te maken. A vertellen om B te suggereren hopende dat mensen B denken terwijl je B niet bedoelt. Ofwel spinningspelletjes en lie by omission (wat gewoon liegen is).

Ik zie Intel dat nergens suggereren, alles lijkt erop te wijzen dat o.a. AMD ARM64 is getroffen ( https://old.lwn.net/Articles/739462/ ) en mogelijk/waarschijnlijk meer op ARM64 based cpu's. Ik zie ook de link met Ryzen niet direct, maar AMD is natuurlijk niet alleen Ryzen ze hebben ook nog een ARM en custom range Het intel pers bericht lijkt wat dat betreft voor zover ik kan nagaan gewoon te kloppen.

Ik vind het eigenlijk dan ook eerder verwarrend dat (iemand van) AMD roept dat AMD niet getroffen zou zijn daar dat nu mogelijk wat te vroeg geroepen lijkt te zijn, daar had deze persoon mogelijk beter AMD Zen Architecture kunnen roepen.

[Sp3ci3s8472]

CMD-Snake schreef op woensdag 3 januari 2018 @ 22:44:
[...]


Maar waar is het bewijs? Niemand heeft nog een goede beschrijving van wat er mis gaat of misbruikt kan worden. Alles wordt vaag gehouden omdat er nog een embargo is. Het blijft speculatie.

Dit soort persberichten worden heel zorgvuldig geformuleerd, daarom zou ik ook niet meteen denken dat ze dit zomaar schrijven. Als de bug vrijgegeven wordt komt meteen het bewijs dat je hard gelogen hebt.

Toch als de bug zo oud is als men beweert is dit tientallen jaren niet opgemerkt gebleven.


[...]


Wat heeft ARM met AMD te maken? De enige link is de gedeelde geschiedenis van Intel en AMD dat AMD Intel CPU's in licentie kon maken. Dan zou het kunnen dat zo de fout ook meegenomen is in AMD ontwerpen. Of ze hebben het over Cyrix of VIA.

Ik lees hier ook niet meteen AMD in. Maar het is wel frappant hoeveel technologie bedrijven samenwerken. Waarom zou AMD Intel gaan helpen met een ontwerpfout in hun product? Dat is onzinnig vanuit een concurrentie perspectief.


[...]


Het is dan ook lastig te begrijpen waarom het Linux kernel team alle x86 CPU's meteen als onveilig markeert. Dan hadden ze ook zelf met de AMD code kunnen komen omdat ze enkel Intel modellen moeten hebben.

AMD heeft toch een ARM cpu ondie? Als extra beveiligingschip. Op die manier kan Intel dus die bewoording dus doen, beetje sneu maar toch.

[CMD-Snake]

https://www.phoronix.com/...x-Tip-Git-Disable-x86-PTI

Linus Torvalds heeft er niet voor gekozen om de suggestie van AMD te mergen. Wel wordt de patch bewaard, het blijft dus afwachten of we deze terug gaan zien in een toekomstige release. Er is wel weerstand vanuit andere medeontwikkelaars van de Linux kernel om 'zomaar' er vanuit te gaan dat een vendor standaard geen beveiligingsproblemen heeft.

Sp3ci3s8472 schreef op woensdag 3 januari 2018 @ 23:22:
AMD heeft toch een ARM cpu ondie? Als extra beveiligingschip. Op die manier kan Intel dus die bewoording dus doen, beetje sneu maar toch.

Maar nergens wordt AMD genoemd. Het is letterlijk wat je wil lezen nu. Ik denk niet dat ze naar PSP verwijzen. PSP is een oplossing die in licentie van ARM gemaakt wordt. Het is geen AMD eigen ontwerp.

Een probleem met PSP zou meer overeenkomen met de problemen rondom Intel ME.

[ Voor 16% gewijzigd door CMD-Snake op 03-01-2018 23:27 ]

[foppe-jan]

Dennism schreef op woensdag 3 januari 2018 @ 23:21:
[...]


Ik zie Intel dat nergens suggereren, alles lijkt erop te wijzen dat o.a. AMD ARM64 is getroffen ( https://old.lwn.net/Articles/739462/ ) en mogelijk/waarschijnlijk meer op ARM64 based cpu's. Ik zie ook de link met Ryzen niet direct, maar AMD is natuurlijk niet alleen Ryzen ze hebben ook nog een ARM en custom range Het intel pers bericht lijkt wat dat betreft voor zover ik kan nagaan gewoon te kloppen.

Ik vind het eigenlijk dan ook eerder verwarrend dat (iemand van) AMD roept dat AMD niet getroffen zou zijn daar dat nu mogelijk wat te vroeg geroepen lijkt te zijn, daar had deze persoon mogelijk beter AMD Zen Architecture kunnen roepen.

Nee, wat intel zegt is het volgende: er verloopt binnenkort een embargo op meerdere geidentificeerde vulnerabilities. Die (3) treffen meerdere/alle vendors. Wat ze niet zeggen: PTI -- met de grootste consequenties voor veiligheid en perf -- is alleen noodzakelijk voor Intel. Daarover blijven ze, zoals dat heet, bewust vaag. En zo bouw je een PR statement waarmee je verwarring zaait.

[CMD-Snake]

foppe-jan schreef op woensdag 3 januari 2018 @ 23:38:
Wat ze niet zeggen: PTI -- met de grootste consequenties voor veiligheid en perf -- is alleen noodzakelijk voor Intel.

Het security team van Google is het daar niet mee eens.

https://www.phoronix.com/...&px=Google-CPU-Disclosure

Google says their Project Zero team last year discovered serious flaws in speculative execution that could lead to reading system memory where it shouldn't be authorized. Google was also able to demonstrate an attack where one VM could access the physical memory of the host machine and in turn read memory of other VMs on the same host.

Google reports that this vulnerability not only affects Intel CPUs but also AMD and ARM... Contrary to AMD saying they are not affected by this issue.

De blogpost van Google's Project Zero Team:
https://googleprojectzero...ged-memory-with-side.html

We have discovered that CPU data cache timing can be abused to efficiently leak information out of mis-speculated execution, leading to (at worst) arbitrary virtual memory read vulnerabilities across local security boundaries in various contexts.

Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models, we have exploits that work against real software. We reported this issue to Intel, AMD and ARM on 2017-06-01 [1].

[foppe-jan]

Zucht.
https://meltdownattack.com/ :

Is there a workaround/fix?

There are patches against Meltdown for Linux ( KPTI (formerly KAISER)), Windows, and OS X. There is also work to harden software against future exploitation of Spectre, respectively to patch software after exploitation through Spectre .

Which systems are affected by Meltdown?

Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

Which systems are affected by Spectre?

Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.

Dus: nee. Intel liegt hier door te doen alsof de vraag over iets anders ging dan (k)PTI, omdat ze dan kunnen doen alsof iedereen er last van heeft, en het niet slechts Intel's producten zijn die commercieel minder interessant worden (want trager dan voorheen).

[ Voor 8% gewijzigd door foppe-jan op 03-01-2018 23:54 ]

[Dennism]

Edit: was al gepost

[ Voor 87% gewijzigd door Dennism op 04-01-2018 00:00 ]

[CMD-Snake]

foppe-jan schreef op woensdag 3 januari 2018 @ 23:51:
Intel liegt hier door te doen alsof de vraag over iets anders ging dan (k)PTI, omdat ze dan kunnen doen alsof iedereen er last van heeft, en het niet slechts Intel's producten zijn die commercieel minder interessant worden (want trager dan voorheen).

Google heeft op hun project zero pagina ook PoC's dat deze exploit ook werkt op o.a. AMD Opteron processoren.

A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]

Ook AMD Opteron CPU's kunnen misbruikt worden om stukken geheugen te lezen vanuit gewone user privileges, wat dus niet zou mogen.

De bug lijkt zich op alle platformen nu te beperken tot enkel lezen van zaken die normaal niet gelezen zouden mogen worden.

[Enchantress]

CMD-Snake schreef op donderdag 4 januari 2018 @ 00:00:
[...]


Google heeft op hun project zero pagina ook PoC's dat deze exploit ook werkt op o.a. AMD Opteron processoren.


[...]


Ook AMD Opteron CPU's kunnen misbruikt worden om stukken geheugen te lezen vanuit gewone user privileges, wat dus niet zou mogen.

De bug lijkt zich op alle platformen nu te beperken tot enkel lezen van zaken die normaal niet gelezen zouden mogen worden.

Voor zover maar 3 CPU’s van AMD waarvan nog niets zeker is.
kidde in 'nieuws: Intel ontkent berichten dat alleen zijn processors vatbaar ...

Ben benieuwd hoe Intel dit gaat aanpakken.

[Dennism]

foppe-jan schreef op woensdag 3 januari 2018 @ 23:51:


Dus: nee. Intel liegt hier door te doen alsof de vraag over iets anders ging dan (k)PTI, omdat ze dan kunnen doen alsof iedereen er last van heeft, en het niet slechts Intel's producten zijn die commercieel minder interessant worden (want trager dan voorheen).

Ik blijf het dan wel zeer vreemd vinden dat je op LWN gewoon kan zien dat KAISER nu omgedoopt naar (k)PTI ook voor ARM gepatched wordt in de kernel. Je zou toch zeggen dat als ze niet vatbaar zijn, ze ook niet zouden hoeven patchen...

Ik denk dat er nog teveel te speculeren valt en het mogelijk beter is even af te wachten tot alle tests afgerond voordat er conclusies getrokken gaan worden over welke vendoren er nu wel en niet vatbaar zijn naast Intel en in welke Product ranges. Voor zover ik nu kan zien lijkt het enkel zeker dat Intel vatbaar is, AMD Zen (en afgeleiden) niet en de rest lijkt nog volslagen onduidelijk op ARMv8 na dat ook vatbaar blijkt te zijn.

[CMD-Snake]

Dennism schreef op donderdag 4 januari 2018 @ 00:06:
Voor zover ik nu kan zien lijkt het enkel zeker dat Intel vatbaar is, AMD Zen (en afgeleiden) niet en de rest lijkt nog volslagen onduidelijk.

Amazon heeft nu ook een persbericht geplaatst over de zaak. Ook Amazon (net als Project Zero) bevestigd dat AMD processoren kwetsbaar zijn. Ze noemen geen specifieke types.

https://aws.amazon.com/se...y-bulletins/AWS-2018-013/

[V3g3ta]

CMD-Snake schreef op donderdag 4 januari 2018 @ 00:08:
[...]


Amazon heeft nu ook een persbericht geplaatst over de zaak. Ook Amazon (net als Project Zero) bevestigd dat AMD processoren kwetsbaar zijn. Ze noemen geen specifieke types.

https://aws.amazon.com/se...y-bulletins/AWS-2018-013/

Link werkt niet (meer).

[Dennism]

V3g3ta schreef op donderdag 4 januari 2018 @ 00:11:
[...]


Link werkt niet (meer).

Hier wel (ook na refresh)

Voor degenen die het niet kunnen openen:

Processor Speculative Execution Research Disclosure
2018/01/03 14:45 PST

AWS is aware of recently disclosed research regarding side-channel analysis of speculative execution on modern computer processors (CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754).

This is a vulnerability that has existed for more than 20 years in modern processor architectures like Intel, AMD, and ARM across servers, desktops, and mobile devices. All but a small single-digit percentage of instances across the Amazon EC2 fleet are already protected. The remaining ones will be completed in the next several hours, with associated instance maintenance notifications.

While the updates AWS performs protect underlying infrastructure, in order to be fully protected against these issues, customers must also patch their instance operating systems. Updates for Amazon Linux have been made available, and instructions for updating existing instances are provided further below along with any other AWS-related guidance relevant to this bulletin.

Updated EC2 Windows AMIs will be provided as Microsoft patches become available.

Please consult with the vendor of any alternative / third-party operating system, software, or AMI for updates and instructions as needed.

This bulletin will be updated as we have new information to share on the availability of improved AMIs, patches, and any other recommended actions for AWS customers.

Amazon Linux AMI (Bulletin ID: ALAS-2018-938)

An updated kernel for Amazon Linux is available within the Amazon Linux repositories. Instances launched with the default Amazon Linux configuration on or after 10:45 PM (GMT) January 3rd, 2018 will automatically include the updated package. Customers with existing Amazon Linux AMI instances should run the following command to ensure they receive the updated package:

yum update kernel

More information on this bulletin is available at the Amazon Linux AMI Security Center

[CMD-Snake]

V3g3ta schreef op donderdag 4 januari 2018 @ 00:11:
Link werkt niet (meer).

Vreemd, bij mij nog wel. Maar wie weet is dat caching. Hier is de tekst:


Processor Speculative Execution Research Disclosure
2018/01/03 14:45 PST

AWS is aware of recently disclosed research regarding side-channel analysis of speculative execution on modern computer processors (CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754).

This is a vulnerability that has existed for more than 20 years in modern processor architectures like Intel, AMD, and ARM across servers, desktops, and mobile devices. All but a small single-digit percentage of instances across the Amazon EC2 fleet are already protected. The remaining ones will be completed in the next several hours, with associated instance maintenance notifications.

While the updates AWS performs protect underlying infrastructure, in order to be fully protected against these issues, customers must also patch their instance operating systems. Updates for Amazon Linux have been made available, and instructions for updating existing instances are provided further below along with any other AWS-related guidance relevant to this bulletin.

Updated EC2 Windows AMIs will be provided as Microsoft patches become available.

Please consult with the vendor of any alternative / third-party operating system, software, or AMI for updates and instructions as needed.

This bulletin will be updated as we have new information to share on the availability of improved AMIs, patches, and any other recommended actions for AWS customers.

Amazon Linux AMI (Bulletin ID: ALAS-2018-938)

An updated kernel for Amazon Linux is available within the Amazon Linux repositories. Instances launched with the default Amazon Linux configuration on or after 10:45 PM (GMT) January 3rd, 2018 will automatically include the updated package. Customers with existing Amazon Linux AMI instances should run the following command to ensure they receive the updated package:

yum update kernel

More information on this bulletin is available at the Amazon Linux AMI Security Center

[V3g3ta]

Ja, werkt nu weer, maar er staat niks concreets in over welke processors er nu wel of niet getroffen zijn. Noem ze allemaal en je bent safe denkt Amazon.

[CMD-Snake]

V3g3ta schreef op donderdag 4 januari 2018 @ 00:14:
Noem ze allemaal en je bent safe denk Amazon.

Amazon zal niet zomaar met namen strooien. Project Zero van Google heeft op hun blog een PoC met AMD Opteron processoren staan. In elk geval is de vorige generatie van AMD kwetsbaar.

[Enchantress]

Het gaat over meltdown dus daar is AMD en ARM niet bij betrokken dus alleen een Intel probleem.

[ Voor 90% gewijzigd door Enchantress op 04-01-2018 00:25 ]

[Verwijderd]

Dennism schreef op woensdag 3 januari 2018 @ 23:21:
daar had deze persoon mogelijk beter AMD Zen Architecture kunnen roepen.

Dat ben ik met jou eens.

foppe-jan schreef op woensdag 3 januari 2018 @ 23:10:

offtopic:
haha: https://twitter.com/BryanLunduke/status/948432831004360704

Ja, dat zou me wat zijn.
Goede nerdhumor van deze AMD-medewerker.

[ Voor 54% gewijzigd door Verwijderd op 04-01-2018 00:25 ]

[Dennism]

Verwijderd schreef op donderdag 4 januari 2018 @ 00:20:
[...]

Dat ben ik met jou eens.

Wat ik begrijp vanaf de FP in ieder geval deze 3 Opterons (ARM gebaseerd)

Opteron 1120
Opteron 1150
Opteron 1170

[CMD-Snake]

Microsoft heeft ook reactie gegeven:
https://www.theverge.com/...cessor-bug-windows-10-fix

Windows 7 t/m 10 zullen een patch ontvangen. Windows 10 wordt vandaag zelfs nog gepatcht via Windows Update. Windows 7 en 8 zullen de patch volgende week ontvangen via Windows Update.

Ik neem aan dat hiermee dan ook de server patches beschikbaar komen voor de respectievelijke server varianten.

[Tadream]

CMD-Snake schreef op donderdag 4 januari 2018 @ 00:54:
Microsoft heeft ook reactie gegeven:
https://www.theverge.com/...cessor-bug-windows-10-fix

Windows 7 t/m 10 zullen een patch ontvangen. Windows 10 wordt vandaag zelfs nog gepatcht via Windows Update. Windows 7 en 8 zullen de patch volgende week ontvangen via Windows Update.

Ik neem aan dat hiermee dan ook de server patches beschikbaar komen voor de respectievelijke server varianten.

Ik lees ergens in de comments dat iemand 20-30% performance verlies met z'n SAN naar VM hosts heeft.
Hoe ga je dat verkopen aan je gebruikers...tja een overmacht, we kunnen het oplossen door nog meer te investeren.
Verder lees ik nog niets bij VMware, maar dat zal niet lang duren verwacht ik.

[SG]

Tadream schreef op donderdag 4 januari 2018 @ 01:32:
Ik lees ergens in de comments dat iemand 20-30% performance verlies met z'n SAN naar VM hosts heeft.
Hoe ga je dat verkopen aan je gebruikers...tja een overmacht, we kunnen het oplossen door nog meer te investeren.
Verder lees ik nog niets bij VMware, maar dat zal niet lang duren verwacht ik.

Nou simpel. Die oude oer optimalisatie bypassed veiligheid dus die performance was altijd al onveilig en dit is de veilge performance dus wat die vroeger deed is dan niet relevant.

[Dennism]

Tadream schreef op donderdag 4 januari 2018 @ 01:32:
[...]


Ik lees ergens in de comments dat iemand 20-30% performance verlies met z'n SAN naar VM hosts heeft.
Hoe ga je dat verkopen aan je gebruikers...tja een overmacht, we kunnen het oplossen door nog meer te investeren.
Verder lees ik nog niets bij VMware, maar dat zal niet lang duren verwacht ik.

Dat soort posts neem ik nog maar even met een korreltje zout zolang ze geen bronnen / links naar eigen benchmarks posten, ik kan bijv. bij SAN vendors nog niets vinden over patches voor SANs, bij VMware zie ik inderdaad ook nog niets, MS heeft Windows 10 gepatched, maar voor de Server varianten zie ik zo snel nog niets, behalve fast Ring, en ik verwacht niet dat iemand zijn Datacenter hosts op Windows 10 of Windows Server Fast-Ring heeft draaien. Neemt niet weg dat er zeker een performance impact zal zijn, maar ik zie liever verifieerbare getallen dan random posts met 20-30% zonder onderbouwing.

[foppe-jan]

Linus is niet onder de indruk van Intel's COA-release: https://www.spinics.net/lists/kernel/msg2688875.html

los daarvan: het schijnt dat nvidiakaarten (itt GCN 1.1+-kaarten) veel syscalls doen.

[CMD-Snake]

Tadream schreef op donderdag 4 januari 2018 @ 01:32:
Verder lees ik nog niets bij VMware, maar dat zal niet lang duren verwacht ik.

Ik heb nog nergens VMWare getallen kunnen vinden. VMWare gebruikt een eigen kernel voor ESXi, ze zullen ook een eigen implementatie van de patch moeten maken.

Ik vermoed dat producenten van Enterprise oplossingen hier ook even over moeten nadenken. Toch als je Windows en Linux VM's de patches hebben ontvangen kunnen die niet meer misbruikt worden om het geheugen van een ander uit te lezen via de host.

foppe-jan schreef op donderdag 4 januari 2018 @ 08:18:
los daarvan: het schijnt dat nvidiakaarten (itt GCN 1.1+-kaarten) veel syscalls doen.

Kan je eindelijk die Vega kaart rechtvaardigen.

[Dennism]

Wat ik dan ook wel weer vreemd vind:

Which cloud providers are affected by Meltdown?
Cloud providers which use Intel CPUs and Xen PV as virtualization without having patches applied. Furthermore, cloud providers without real hardware virtualization, relying on containers that share one kernel, such as Docker, LXC, or OpenVZ are affected.

Nu zal Hyper-V buiten Azure niet veel gebruikt worden, maar ook bijv VMware staat er niet tussen. Maar zouden dan echt alleen XEN vatbaar zijn? Ik kan het haast niet geloven....

[CMD-Snake]

Dennism schreef op donderdag 4 januari 2018 @ 08:47:
Nu zal Hyper-V buiten Azure niet veel gebruikt worden, maar ook bijv VMware staat er niet tussen. Maar zouden dan echt alleen XEN vatbaar zijn? Ik kan het haast niet geloven....

VMWare heeft een eigen kernel voor ESXi. De werking en inhoud van die kernel is onbekend, VMWare houdt dat geheim. Tenzij iemand een PoC maakt op VMWare kan je niet uitvinden of VMWare nu wel of niet kwetsbaar is.

Geen idee of VMWare happig is om details te geven, ze verraden dan ook wat er in hun kernel zit.

[foppe-jan]

CMD-Snake schreef op donderdag 4 januari 2018 @ 08:41:

Kan je eindelijk die Vega kaart rechtvaardigen.

Ik heb geen Intel CPU (behalve in een laptop), en voor Ryzen CPUs is dit dus nvt. Alleen Intel+Nvidia levert mogelijk problemen op.

[Dennism]

Voor Spectre hebben ze in ieder geval al wel deels patches (1 van de 2 CVE's bij esxi 5.5)

https://www.vmware.com/se...ories/VMSA-2018-0002.html

[ Voor 4% gewijzigd door Dennism op 04-01-2018 08:59 ]

[Meekoh]

Om nog even een mooi real world scenario toe te voegen.
AWS klanten die klagen over CPU performance na maintenance

[foppe-jan]

Meekoh schreef op donderdag 4 januari 2018 @ 11:47:
Om nog even een mooi real world scenario toe te voegen.
AWS klanten die klagen over CPU performance na maintenance

offtopic:
wat een behandeling ook weer. Heerlijk toch, dat legalistische bureaucratisch taalgebruik dat suggereert dat je alles maar moet slikken omdat er een zinnetje in de EULA staat dat dit 'kan gebeuren'.

[ Voor 20% gewijzigd door foppe-jan op 04-01-2018 12:19 ]

[DaniëlWW2]

Even samenvatten.

Er zijn drie aparte beveiligingsproblemen. Deze zijn Spectre 1, Spectre 2 en Meltdown.
-Spectre 1 is de Bounds Check Bypass variant. Hiervoor zijn Intel, AMD en ARM CPU's gevoelig. Dit lijkt alleen een zeer moeilijke, en niet erg praktische aanvalsmethode te zijn.
-Spectre 2 is de Branch Target Injection variant. Intel is hier gevoelig voor, AMD is potentieel gevoelig hiervoor, maar dit is nog niet duidelijk. Het lijkt erop dat Zen hier in ieder geval niet gevoelig voor is. ARM weet ik niet.
-Meltdown is Intel x86 only, en is zeer problematisch als beveiligingslek. Voor dagelijks gebruik heeft de fix geen impact. Voor specifieke I/O prestaties die worden gebruikt in servers is er een behoorlijke impact. Laat dit nu ook eens het terrein zijn waar Intel haar Skylake SP lijn vrij zwak staat tegenover AMD Epyc.

Voor Meltdown zijn er drie scenario's denkbaar.
1) Hyperscalers kopen meer Intel racks ter compensatie.
2) Hyperscalers stappen over naar AMD.
3) Hyperscalers klagen Intel aan, in combinatie met 1 of 2.

Ja, dat wordt in ieder geval nummer drie. Een bedrijf zoals Amazon leidt reputatieschade door Intel. Ter compensatie moeten ze de prijzen van hun diensten verlagen, of meer racks kopen voor dezelfde prestaties. Beiden kost ze marge. Ze gaan Intel dus aanklagen als ze niet uit zichzelf met compensatie komen. Intel doet niet aan compensatie, dus Intel gaat aangeklaagd worden. Dan blijft de vraag of het Intel of AMD kopen word voor de hyperscalers. Dat zal afhangen van de eisen. I/O intensief, juist waar de klappen van Meltdown vallen, daar zal Epyc verleidelijk gaan worden om tenminste oudere servers mee te vervangen.

Het enige goede nieuws voor Intel is dat ik betwijfel of AMD de productie van Epyc chips zomaar, enorm kan verhogen, mocht er een beetje een run ontstaan op overstappen naar Epyc.

---

Maar wat een puinzooitje is dit aan het worden zeg. Het zijn ook niet consumenten ofzo die Intel wel af kan houden met eindeloos tijdrekken in rechtzaken, waarna ze akkoord gaan met een kleine compensatie. Nee, dit zijn bedrijven zoals Google, MS of Amazon die je treft, en die gaan het er niet bij laten zitten. Dit kan zomaar de grootste rechtszaak worden, en de grootste vergoeding uit Intel haar geschiedenis...

[ Voor 10% gewijzigd door DaniëlWW2 op 04-01-2018 12:47 ]

[foppe-jan]

Gegeven dat ze hier al sinds voor de zomer van schijnen te weten, en ze wel -- en vervroegd -- met die nieuwe generatie zijn gekomen, lijkt de kans me niet afwezig.

[ Voor 6% gewijzigd door foppe-jan op 04-01-2018 13:01 ]

[maratropa]

is het de 2018-01 cumulative win10 update waar al het een en ander in zit qua lapmiddelen?

[CMD-Snake]

maratropa schreef op donderdag 4 januari 2018 @ 13:34:
is het de 2018-01 cumulative win10 update waar al het een en ander in zit qua lapmiddelen?

De bewuste update voor Meltdown wordt aangeboden afhankelijk van de compatibiliteit van je antivirus met de gevolgen van de patch. De AV fabrikant moet een bepaalde registerkey aanmaken voordat de update pas verschijnt.

Dit is logisch, AV pakketten kunnen potentieel ook flink geraakt worden in hun werk door de patch gezien dat de AV ook de kernel in de gaten moet houden in verband met malware.

[maratropa]

@CMD-Snake Dat is dan wel een voordeel van Windows Defender draaien

[CMD-Snake]

maratropa schreef op donderdag 4 januari 2018 @ 13:51:
@CMD-Snake Dat is dan wel een voordeel van Windows Defender draaien

Zelf draai ik Kaspersky endpoint protection. Gisteren vroeg die om een reboot voor een update, maar ik zie de bewuste register key nog niet staan.

De AV fabrikanten zullen ook de nodige tijd moeten nemen om te voorkomen dat ze straks zitten met machines die niet meer starten of crashen.

[satya]

De aanval kan via een browser plaatsvinden, maar firefox heeft al maatregelen genomen.
De andere vendros ook hoop ik.

https://blog.mozilla.org/...-new-class-timing-attack/

[foppe-jan]

https://www.businessinsid.../?international=true&r=US vindt het ook nieuws. Los daarvan, is het mi redelijk dubieus dat je bij Intel als directeur aandelenverkopen mag plannen nadat je intern al prima weet dat er een fantastische ER aankomt, want dat was in October natuurlijk al wel duidelijk.

[ Voor 47% gewijzigd door foppe-jan op 04-01-2018 15:27 ]

[Verwijderd]

CMD-Snake schreef op donderdag 4 januari 2018 @ 08:41:
Kan je eindelijk die Vega kaart rechtvaardigen.

De Vega56-kaart is prima te rechtvaardigen, als je die op het juist moment kocht. De huidige prijzen, dat is een ander verhaal maar een maandje geleden kon je voor €450-500 een AIB-versie van Vega56 kopen met een prima koeling en goede fans. De referentiekaart van Vega56 was ook prima te rechtvaardigen: een beetje ondervolten en je krijgt een goede performance terwijl het niet al te veel lawaai maakt.
Het is vermoeiend dat mensen - vooral die mensen die enkel de klok hebben horen luiden maar niet weten waar de klepel hangt m.b.t. Vega - Vega op 1 hoop blijven gooien terwijl Vega56 gewoon een prima performane/prijs biedt.
Vega64 is ook een prima kaart, maar niet voor gaming. Vega56 is een prima kaart voor gaming, maar je moet wel de kaart ondervolten en je mag ook rustig de kaart een beetje onderklokken aangezien de bottleneck van de kaart elders ligt.
Wil je het beste? 1080 ti
Wil je een kaart voor 1440p gaminig? Kiezen tussen de 1080 en de Vega56
Wil je een kaart voor 1080p gaming? 580 of 570
Dit bij normale prijzen wanneer de nepminers weer opgerot zijn van deze markt.

[ Voor 15% gewijzigd door Verwijderd op 04-01-2018 15:45 ]

[The Chosen One]

Als je, en, ook. Nee dan is het geen goede kaart meer...

[Verwijderd]

The Chosen One schreef op donderdag 4 januari 2018 @ 15:44:
Als je, en, ook. Nee dan is het geen goede kaart meer...

Die "als" geldt enkel voor de invloed die die nepminers hebben op de prijs. Dat ondervolten is helemaal niet nodig, ik gaf slechts aan dat het aan te bevelen is om dat te doen en zelfs wat klokfrequentie op te offeren aangezien die CU's met die klokfrequentie meestal overkill zijn t.o.v. een ander deel of andere delen van de hardware die de bottleneck vormen. Kwestie van het te optimaliseren: aanzienlijk lager vermogen dan de 1070, minder lawaai maar nauwelijks performanceverlies t.o.v. stock.

Maar goed, het gaat hier over Intel (en zijdelings komt Ryzen er dus ook aan te pas gezien de huidige shitstorm voor Intel ) dus laten we die discussie elders voortzetten. Ik wou slechts even het versrpreiden van verkeerde informatie (dat heel Vega zou zuigen) voorkomen onder de mensen die meelezen.

[ Voor 12% gewijzigd door Verwijderd op 04-01-2018 15:50 ]

[Verwijderd]

foppe-jan schreef op donderdag 4 januari 2018 @ 08:18:
Linus is niet onder de indruk van Intel's COA-release: https://www.spinics.net/lists/kernel/msg2688875.html

los daarvan: het schijnt dat nvidiakaarten (itt GCN 1.1+-kaarten) veel syscalls doen.

Damn, Linus is weer eens duidelijk.

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

[CMD-Snake]

Verwijderd schreef op donderdag 4 januari 2018 @ 15:42:
aangezien de bottleneck van de kaart elders ligt.

Die bottleneck is dat er al meer dan een jaar voordat Vega kwam betere kaarten voor betere prijzen waren? Die als ze uit de doos komen goed werken, stiller zijn, minder heet lopen en minder stroom verbruiken?

Een product moet goed zijn als het uit de doos komt. Moeten undervolten, underclocken, overclocken of een BIOS flash doen om tot een goed product te komen is niet acceptabel. Voor Tweakers is zoiets leuk hobbywerk, maar niet iedereen wil dit soort dingen doen.

[Verwijderd]

Wat extra info:

Info over de patches voor Windows OS (ook Windows Server):

https://support.microsoft...e-speculative-execution-s

Info over impact op Azure VM's:

https://azure.microsoft.c...s-from-cpu-vulnerability/

Is allemaal wel een puinhoopje hoor, de helft van onze Azure VM's zijn deze middag al plots heropgestart door Microsoft.

[Verwijderd]

foppe-jan schreef op donderdag 4 januari 2018 @ 15:05:
https://www.businessinsid.../?international=true&r=US vindt het ook nieuws. Los daarvan, is het mi redelijk dubieus dat je bij Intel als directeur aandelenverkopen mag plannen nadat je intern al prima weet dat er een fantastische ER aankomt, want dat was in October natuurlijk al wel duidelijk.

Blijkbaar lezen ook zij Reddit.
Wedden dat justitie een onderzoek naar Brian Krzanich heeft gestart of binnekort gaat starten?

[Verwijderd]

CMD-Snake schreef op donderdag 4 januari 2018 @ 16:19:
[...]


Die bottleneck is dat er al meer dan een jaar voordat Vega kwam betere kaarten voor betere prijzen waren?

offtopic:
Nee, gewoon een hardwarematige bottleneck, dezelfde als die Fury (ook een rekenmonster met een forse bottleneck voor gaming) had. Je ziet dat bijvoorbeeld heel erg duidelijk bij Dirt4 CMAA vs. Dirt4 MSAA, in het eerste geval: Vega64>Vega56>1080 Ti>1080>1070 (ja, echt waar), in het tweede geval is het 1080 Ti>1080>Vega64>1070>Vega56 , als je enkel naar de FPS kijkt die ongeveer net zo veel zegt als het gemiddelde inkomen in een land.
Het is bekend dat Vega-kaarten, net als Fury-kaarten, bijvoorbeeld MSAA op een hoge stand niet goed aankunnen. De technische oorzaak is ingewikkelder (welke delen je tekort komt op de kaart) maar praktisch gezien komt het op dit neer: waar Nvidia twee kaarten kan ontwikkelen voor 2 markten moet AMD omwille van een veel lager budget (<<2,5) 1 kaart ontwikkelen voor de beide markten. Vega is ontwikkeld voor de zakelijke toepassingen, niet voor gaming. Mogelijk biedt Navi een oplossing als het meer tweakbaar wordt dankzij een meer modulaire opbouw zoals Ryzen vs. andere CPU's waarbij de IF de delen verbindt. Dit zou het mogelijk kunnen maken dat je wat meer van het een op de gaming-variant stopt en wat meer van het ander op de zakelijke variant.

Waar het op neer komt is dit. Hoewel de Vega64 in bepaalde gevallen beter kan presteren bij dezelfde klokfrequentie is het verschil erg klein in verhouding tot het aantal extra CU's en zie je zelfs bij veel spellen geen verschil bij dezelfde klokfrequentie. Waarom? Omdat die extra CU's overkill zijn voor andere delen van de kaart die het niet kunnen bijhouden. Zoiets als wanneer je een GTX 1080 Ti koppelt aan een i5-750 of een HD GTX 750 Ti koppelt aan een 8700k. Die extra CU's zijn nuttig bij zakelijke toepassingen, ze zijn weinig nuttig bij gaming. Dat is dan ook de reden waarom je rustig de klokfrequentie van Vega56 en Vega64 kan verlagen, het verlies is erg klein in verhouding tot het lagere vermogen. Als jij even kijkt in de Vega ervaringen draad dan kan je concrete voorbeelden hiervan lezen, Daniël vermeldt er nog een op de laatste pagina. Tevens kan jij daarmee begrijpen waarom Vega voor APU's uitermate geschikt is, de performance is best wel goed zolang je het niet belachelijk hoog klokt en over de pak hem beet 56 CU's heen gaat.

tl;dr: Vega56 is een prima kaart voor gaming wanneer die voor de normale prijs verkrijgbaar is, dus wanneer die cryptominers weer oprotten van deze markt, Vega64 is een slechte kaart voor gaming omdat de extra CU's waar jij voor betaalt weinig nuttig gebruikt kan worden door andere delen van de GPU die het niet kunnen bijbenen.

Vega-kaarten werden te hoog geklokt omdat AMD weet dat er een hoop onnozele reviewers en klanten zijn die een obsessie hebben met de FPS en die het een dramaaaaa vinden als de FPS van de Vega56/RX580 onder die van de GTX 1070/1060 ligt. Dat neemt niet weg dat ik het met jou eens ben dat ze de kaart beter lager hadden geklokt. Doe echter niet alsof het zo moeilijk is voor een doorsnee gebruiker om dat zelf even aan te passen en alsof het gelijkwaardig is aan dat je Pac Man moet schrijven in een assembly-taal.

[ Voor 12% gewijzigd door Verwijderd op 04-01-2018 16:52 ]

[CMD-Snake]

Verwijderd schreef op donderdag 4 januari 2018 @ 16:24:
Is allemaal wel een puinhoopje hoor, de helft van onze Azure VM's zijn deze middag al plots heropgestart door Microsoft.

Het is wel allemaal gepland. Als je Azure VM's had stond het al op je overzicht pagina. Ook AWS gaat op korte termijn alle herstarten. Dat zat er dik in.