Bekijk Volledige Versie : [Security alert!] Huge Flaw Found in Intel Processors; Patch Could Hit 5-30% CPU Perf
stefantriep
03/01/18, 13:41
Vanochtend is dit bericht binnengekomen op Tweakers. Heeft iemand dit toevallig al eens getest of ervaren? Weet niet of er mensen op een development omgeving met een RC draaien en merken dat de server minder prestaties levert.
Bron: https://tweakers.net/nieuws/133451/patch-voor-ernstige-intel-bug-verlaagt-softwareprestaties-aanzienlijk.html
Ben hier ook wel nieuwsgierig naar vooral naar Postgresql omgevingen.
Ben hier ook wel nieuwsgierig naar vooral naar Postgresql omgevingen.
Maar zou je daar willen/moeten mitigeren ?
Het lijkt erop dat dit een bug betreft waarbij unprivileged processen teveel kunnen zien (of misschien wijzigen) van privileged processen of de kernel.
Bij postgresql omgevingen denk ik niet meteen dat je daarop ook untrusted processen draait .
Voor hypervisors is het wel een groot issue , en blijkbaar zijn Amazon AWS en Azure deze week alles aan het updaten .
Volgens de berichten hangt de impact heel sterk af van het type load - veel syscalls = veel (30..50% ) impact , weinig syscalls weinig impact.
Ik durf niet meteen te zeggen of postgres iets is dat naar verhouding 'veel' syscalls doet.
Meting die ik vond :
https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.de
quoting :
===
readonly pgbench (tpch-like), 16 clients, i7-6820HQ CPU (skylake):
pti=off:
tps = 236629.778328
pti=on:
tps = 220791.228297 (~0.93x)
pti=on, nopcid:
tps = 198959.801459 (~0.84x)
To get closer to the worst case, I've also measured:
pgbench SELECT 1, 16 clients, i7-6820HQ CPU (skylake):
pti=off:
tps = 420490.162391
pti=on:
tps = 350746.065039 (~0.83x)
pti=on, nopcid:
tps = 324269.903152 (~0.77x)
Note that real-world scenarios probably will see somewhat smaller
impact, as this was measured over a loopback unix sockets which'll have
smaller overhead itself than proper TCP sockets + actual network.
===
Dit is wel heel erg groot nieuws dus verdiep jezelf zsm in wat er aan de hand is.
We're dealing with two serious threats. The first is isolated to #IntelChips (https://www.webhostingtalk.nl/usertag.php?do=list&action=hash&hash=IntelChips) , has been dubbed Meltdown, and affects virtually all Intel microprocessors. The patch, called KAISER, will slow performance speeds of processors by as much as 30 percent.
The second issue is a fundamental flaw in processor design approach, dubbed Spectre, which is more difficult to exploit, but affects virtually ALL PROCESSORS ON THE MARKET (Note here: Intel stock went down today but Spectre affects AMD and ARM too), and has NO FIX.
Spectre will require a complete re-architecture of the way processors are designed and the threats posed will be with us for an entire hardware lifecycle, likely the next decade.
Meltdown and Spectre affect most chipmakers including those from AMD, ARM, and Intel, and all the devices and operating systems running them (GOOG, AMZN, MSFT, APPL etc).
It is noteworthy that installing the update will hit your system speed negatively and could bring down CPUs performance by 5 percent to 30 percent, "depending on the task and processor model.
Google says its systems have been updated to defend against Meltdown https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html Microsoft issued an emergency update today. Amazon said it protected AWS customers running Amazon's tailored Linux version, and would roll out the MSFT patch for other customers 2day
https://www.nytimes.com/2018/01/03/business/computer-flaws.html
https://thehackernews.com/2018/01/intel-kernel-vulnerability.html
https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
https://meltdownattack.com/
Yourwebhoster
04/01/18, 08:23
Zie ook https://www.webhostingtalk.nl/hardware/195387-patch-ernstige-intel-bug-verlaagt-softwareprestaties-aanzienlijk.html#post1324329 :-)
Anyways, de berichtgeving is nogal krom. AMD zou niet affected zijn maar in werkelijkheid is dit wel het geval. http://www.amd.com/en/corporate/speculative-execution. Zie ook https://spectreattack.com.
Voor de Red Hat gebruikers onder ons: er is zo te horen lang aan gewerkt (sinds 1 juni vorig jaar was dit al bekend bij Intel bijvb) en het is de vraag hoe lang Red Hat gaat doen over het porten naar oudere kernel versies. https://access.redhat.com/security/vulnerabilities/speculativeexecution. Klik door naar de Resolve tab waar je de status van updates en packages kan vinden.
AMD is blijkbaar niet gevoelig voor meltdown, maar wel weer voor spectre. Er zijn software patches voor meltdown in de maak en hier en daar zelfs al gereleased, maar aldus de berichtgeving kan niet alles gepatched worden voor spectre en er wordt zelfs gezegd dat men daar nieuwe hardware voor moet ontwerpen, terwijl er andere uitspraken zijn over "software patches are coming". Het zal wel afhankelijk zijn van je CPU gok ik zo, maar er is nog veel onduidelijk op het moment.
Het is inderdaad een bug die al lang bekend was bij de hoofdspelers. De researchers zijn zo'n 10 maanden geleden aan de KAISER patch begonnen te werken ( https://github.com/IAIK/KAISER ) dus het komt inderdaad niet helemaal uit de lucht vallen.
Deze link helpt een beetje:
https://danielmiessler.com/blog/simple-explanation-difference-meltdown-spectre/
https://www.vmware.com/security/advisories/VMSA-2018-0002.html
Lijkt er trouwens op dat vmware al in november dit gepatched heeft.
De betreffende patch: https://kb.vmware.com/s/article/2151132 heeft dan ook een datum in november.
Maar nu zou ik graag de volgende vraag beantwoord zien. Op moment je host / hypervisor gepatched is, hoe hoog is de noodzaak van de vm dan nog ?
Ja. Ik vraag mij ook af wat de noodzaak van je vm is na patches van de hv. Wij hebben een klant met een groot aantal Postgresql omgevingen. Zijn niet publiekelijk benaderbaar maar wel sterk afhankelijk van performance. Daar gaan wij dit goed testen.
Centos 7 heeft vandaag de patch uitgebracht in ieder geval. Voor oudere versies is het nog afwachten
CharlieRoot
04/01/18, 22:45
Ja. Ik vraag mij ook af wat de noodzaak van je vm is na patches van de hv. Wij hebben een klant met een groot aantal Postgresql omgevingen. Zijn niet publiekelijk benaderbaar maar wel sterk afhankelijk van performance. Daar gaan wij dit goed testen.
Wat ik er van gelezen heb is het vooral van belang op machines die benaderbaar zijn. Als het geïsoleerd is lijkt het me een calculeerbaar risico.
Ik heb de Windows updates/patches al draaien. Merk geen enkel verlies in performance. Maar voor een drukke database server kan dit uiteraard heel anders zijn
CharlieRoot
04/01/18, 22:47
Windows patches zaten ook in wsus. Gek genoeg nog niets van debian of ubuntu gezien..
Wij hebben ook nog wat klanten met Centos 6.x systemen. Benieuwd hoe snel daar iets voor komt
Yourwebhoster
05/01/18, 09:43
Wij hebben ook nog wat klanten met Centos 6.x systemen. Benieuwd hoe snel daar iets voor komt
Die was al uit voor je bericht: http://mirror.yourwebhoster.eu/centos/6/updates/x86_64/Packages/?C=M;O=D (zie https://access.redhat.com/errata/RHSA-2018:0008).
Ik zie door de bomen het bos niet meer ..
Kernel 4.15 draaien is dan de oplossing of slechts een deel ?
Yourwebhoster
05/01/18, 10:45
Ik zie door de bomen het bos niet meer ..
Kernel 4.15 draaien is dan de oplossing of slechts een deel ?
Je kan natuurlijk je eigen kernel compilen, maar de meeste distro's lopen een aantal kernel versies achter (of in het geval van Red Hat: behoorlijk). Zelf backporten valt niet te doen, dus dan kan je of zelf compilen of wachten op de ontwikkelaars om een update uit te geven. Laatstgenoemde is verstandiger, vooral als je zelf niet bekend bent met het compilen van een kernel (en het kan ook weer problemen veroorzaken als je niet uit kijkt).
Red Hat (oa CentOS) heeft het al verwerkt in haar kernels. Voor versie 5 kan je met een Red Hat abonnement ook nog updates krijgen.
Overigens zit het ook in 4.14.10.
Mocht je helemaal niet meer weten wat je moet doen, check dan gewoon bij de vendor wat de status is. Op https://spectreattack.com kan je hiervoor een handige referentie lijst vinden.
In verband met de omvang van de fout hebben wij besloten om vannacht spoedonderhoud te doen nadat CentOS de updates van Red Hat heeft doorgevoerd (immers wil je ook niet versleutelde wachtwoorden in het geheugen uitleesbaar hebben). Onze eigen CentOS mirror is doorgaans sneller met het synchroniseren, maar er zijn ook mirrors die langzamer zijn en daardoor kan je dus bij een yum update alsnog achterlopen. Let dus goed op welke versie je draait na het updaten.
Let op dat Red Hat aangeeft dat kpatch niet werkt voor Red Hat 7.2 of hoger. Om die reden hebben wij gekozen om - zelfs met kernelcare - een volledige herstart uit te voeren. CloudLinux heeft hier meer informatie en geeft ook aan dat ze de kernel niet goed hebben kunnen testen (https://www.cloudlinux.com/cloudlinux-os-blog/entry/intel-cpu-bug-kernelcare-and-cloudlinux). Er zijn ook problemen met deze kernel bekend.
Edit: Verder dien je een microupdate voor je CPU uit te voeren of software opnieuw te compilen om het probleem met Spectre op te lossen. De exacte details hiervan zijn mij niet helemaal duidelijk, maar we gaan de komende dagen zien wat er gaat gebeuren. Intel claimed 90% van de processoren van maximaal 5 jaar oud te gaan updaten binnen een week (https://nl.hardware.info/nieuws/54747/intel-wil-90-processoren-van-afgelopen-vijf-jaar-binnen-week-patchen). Dat gaat een tweede "leuke" reboot worden.
Meer informatie: http://www.theregister.co.uk/2018/01/04/intel_amd_arm_cpu_vulnerability/
Mochten jullie meer informatie hebben, hoe jullie het aanpakken en wat jullie hier bij denken, join! Meer providers doen dit (http://www.webhostingtalk.com/showthread.php?t=1690161&p=9987097#post9987097).
wht.com thread voor een extra source (het is verdacht rustig daar): http://www.webhostingtalk.com/showthread.php?t=1690161
Edit: Topics samengevoegd.
Die was al uit voor je bericht: http://mirror.yourwebhoster.eu/centos/6/updates/x86_64/Packages/?C=M;O=D (zie https://access.redhat.com/errata/RHSA-2018:0008).
Thanks :) was ook net twee uurtjes er voor inderdaad.
Ik zie door de bomen het bos niet meer ..
Kernel 4.15 draaien is dan de oplossing of slechts een deel ?
Ik moet zeggen door het slap reageren van Intel, en hoop speculatie, vind ik deze 2 BUGS langzaam wel een cluster fuckup worden. Ik heb vragen, en rondom mij zijn er ook voldoende vragen. Iedereen denkt iets te weten, maar echt duidelijk vind ik het niet. Ergen bedruipt me het gevoel dat we er nog niet zijn, ondanks de patches die er gedaan zijn....
Dit in combinatie met de GDPR die er in mei aankomt is gewoon spek naar de bek voor security bedrijven..
Mikey,
Ik geloof dat je de juiste terminologie gebruikt.
Qua VMware en je eerdere vraag, volgens mij is dit de korte samenvatting.
De vSphere kernel is niet gevoelig voor Meltdown omdat alles op kernel nivo draait. Maar je VMs moeten wel gepatched worden.
Qua vSphere 6.0 en 6.5 zijn volgens mij de huidige patches afdoende voor Spectre versie 1 en 2. Men claimt dat Spectre 3 niet telt voor vSphere.
Voor vSphere 5.5 volgen nog patches en vSphere 5.1 wordt denkelijk niet gepatched.
En dan moet je ook nog de firmware patches te pakken zien te krijgen van je hardware vendor.
Relevante links:
https://kb.vmware.com/s/article/52245
en
https://blogs.vmware.com/security/2018/01/vmsa-2018-0002.html
side note: Voor linux wil je op de allerlaatste kernel zitten omdat de patch anders geen gebruik maakt van PCID welke helpt om niet teveel overhead te hebben, ook al heeft je CPU wel die feature.
Zie ook: https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU
end deze laatste link is ook relevant voor NIET VMware gebruikers.
Ik vermoed inderdaad dat er de komende maanden nog meer gepatched gaat moeten worden. Al is het alleen maar om de laatste firmware's te kunnen uploaden naar je CPU in het geval je hardware supplier niet met een nieuwe BIOS/firmware komt.
Yourwebhoster
09/01/18, 10:35
Ik vermoed inderdaad dat er de komende maanden nog meer gepatched gaat moeten worden. Al is het alleen maar om de laatste firmware's te kunnen uploaden naar je CPU in het geval je hardware supplier niet met een nieuwe BIOS/firmware komt.
Dat sowieso, volgens Intel zou het performance wise ook beter moeten worden. Ik ben ook zeer benieuwd wat Intel precies met de microupdates gaat patchen en wat voor impact dat gaat hebben.
Wat ik wel bijzonder slecht vind (en echt hoor, dat is forceren om nieuwe CPUs te kopen) is dat Intel tot 5 jaar oude CPUs gaat aanpakken. En waarom heeft het zo lang moeten duren? En waarom was niet iedereen hier tijdig van op de hoogte (FreeBSD, ik ben geen gebruiker hier van maar toch)? En hoe kan het dat Intel nog steeds geen updates heeft als 9 januari als de deadline was neergezet?
Het hele verhaal stinkt ook voldoende om te gaan speculeren dat bepaalde diensten het lek nodig hadden voor het spioneren...
Alentejo Hosting
09/01/18, 12:03
Intel heeft online een tool waarmee je kunt zien of je systeem (OS Windows of Linux) kwetsbaar is.
https://www.intel.com/content/www/us/en/support/articles/000025619/software.html
Intel heeft online een tool waarmee je kunt zien of je systeem (OS Windows of Linux) kwetsbaar is.
Da's een andere security issue (intel SA-00086) en heeft te maken met een issue in de intel Management Engine, niet meltdown/spectre.
Als je de bijbehorende link op die site over intel SA-00086 leest dan zie je dat er geen melding wordt gemaakt over CVE-2017-5753, CVE-2017-5754 of CVE-2017-5715
Frijswijk01
09/01/18, 15:32
Ik heb eigenlijk ook geen woorden voor deze mega fuckup. Wij wachten op dit moment nog op patches van OnApp maar ook daar is het nu alweer vanaf de 5e stil. En wat hierboven ook al is gezegd hoe kan het dat de patches van Intel nog niet klaar waren?
En dan komt daar bovenop nog het volgende; https://www.businessinsider.nl/intel-ceo-krzanich-sold-shares-after-company-was-informed-of-chip-flaw-2018-1/
Hoe schandalig is dit?
Intel was aware of the chip vulnerability when its CEO sold off $24 million in company stock
Yourwebhoster
09/01/18, 16:02
En dan komt daar bovenop nog het volgende; https://www.businessinsider.nl/intel-ceo-krzanich-sold-shares-after-company-was-informed-of-chip-flaw-2018-1/
Hoe schandalig is dit?
Hier gaan meerdere theorieën over rond (ga er van uit dat het is onderzocht). In de staat waar de CEO zit (Californië) gaat de belasting dusdanig omhoog dat het op belastinggebied slim zou zijn. Wel komt het erg ongelukkig uit en schijnt het dat hij het al voordat de stemming rond was toestemming aan het bedrijf had gevraagd...
Frijswijk01
09/01/18, 16:22
Hier gaan meerdere theorieën over rond (ga er van uit dat het is onderzocht). In de staat waar de CEO zit (Californië) gaat de belasting dusdanig omhoog dat het op belastinggebied slim zou zijn. Wel komt het erg ongelukkig uit en schijnt het dat hij het al voordat de stemming rond was toestemming aan het bedrijf had gevraagd...
Het lijkt mij nu meer een geluk bij een ongeluk want dit kan en mag gewoon niet. Hetzelfde als een kapitein die niet als laatste zijn zinkend schip verlaat. Onacceptabel.
Maar als dit echt is gegaan zoals deze man het uitlegt dan is dat natuurlijk geen probleem.
... en dat heeft ook niet lang op zich laten wachten.. de nieuwe patches voor vSphere 5.5, 6.0 en 6.5 zijn nu beschikbaar:
https://esxi-patches.v-front.de/ESXi-6.5.0.html
(je kan op die pagina switchen van versie en de KB artikelen voor de betreffende versie bekijken. Bijbehorende security bulletin was net nog niet beschikbaar, maar zal wel komen)
Wij wachten op dit moment nog op patches van OnApp maar ook daar is het nu alweer vanaf de 5e stil. En wat hierboven ook al is gezegd hoe kan het dat de patches van Intel nog niet klaar waren?
Ik snap niet waarom je op OnApp wacht. Je kan gewoon via yum update de kernel en toebehoren updaten. Daar ben je OnApp niet bij nodig.
Ik snap niet waarom je op OnApp wacht. Je kan gewoon via yum update de kernel en toebehoren updaten. Daar ben je OnApp niet bij nodig.
OnApp heeft ook een repo met custom kernel, misschien dat hij deze gebruikt of het heeft over de templates die OnApp aanbied.
OnApp heeft ook een repo met custom kernel, misschien dat hij deze gebruikt of het heeft over de templates die OnApp aanbied.
Alle partijen die ik met OnApp ken gebruiken geen custom repo's. Zo ver ik weet adviseren ze bij OnApp ook gewoon de standaard OS repo's te gebruiken. Zonder meer info blijft het gokken. De templates zou ik me sowieso niet druk over maken. Zelf hebben we de templates aangepast met een update tijdens het booten. Volgens mij kan je dat ook via recipies doen.
T. Verhaeg
09/01/18, 19:10
... en dat heeft ook niet lang op zich laten wachten.. de nieuwe patches voor vSphere 5.5, 6.0 en 6.5 zijn nu beschikbaar:
https://esxi-patches.v-front.de/ESXi-6.5.0.html
(je kan op die pagina switchen van versie en de KB artikelen voor de betreffende versie bekijken. Bijbehorende security bulletin was net nog niet beschikbaar, maar zal wel komen)
Bij deze..
https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html
... en dat heeft ook niet lang op zich laten wachten.. de nieuwe patches voor vSphere 5.5, 6.0 en 6.5 zijn nu beschikbaar:
https://esxi-patches.v-front.de/ESXi-6.5.0.html
(je kan op die pagina switchen van versie en de KB artikelen voor de betreffende versie bekijken. Bijbehorende security bulletin was net nog niet beschikbaar, maar zal wel komen)
Niet helemaal waar, denk dat het een bijgewerkte patch is. Wellicht al performance improvements. Volgens de eerste VMSA-2018-0002, was de patch er al in november 2017
Tja, dat was de initiele claim van VMware inderdaad in security advisory 2018-0002, al stond daar toen ook al bij in een update van het artikel dat er meer zou volgen.
Nu blijkt dat de patches van November toch niet afdoende zijn, er zijn meer patches nodig om helemaal beschermd te zijn, zie ook advisory 2018-0004.
Er zit nl. ook een nieuwe "base" vib in en dat betekent dat behalve dat je je host moet rebooten er toch iets meer is veranderd. In de bijbehorende KB staat "This ESXi patch provides part of the hypervisor-assisted guest remediation of CVE-2017-5715 for guest operating systems"
zie: https://kb.vmware.com/s/article/52198
Daarnaast heeft deze patch ook de betreffende firmware CPU microcodes als die nog niet via de hardware leverancier worden aangeboden.
Affijn het maakt allemaal niet echt uit, het is gewoon weer patch tijd.
Mocht het je interesseren, ik hou hier een live document bij met details die nuttig zijn voor het patchen van Meltdown en Spectre.
http://planetvm.net/blog/?p=3305
Hier is alles alweer een tijdje gepatched. Er lijkt weinig performance impact gelukkig. CloudLinux heeft nog wel wat problemen met hun kernels.
En shit is hitting the fans....
We have received reports from a few customers of higher system reboots after applying firmware updates. Specifically, these systems are running Intel Broadwell and Haswell CPUs for both client and data center. We are working quickly with these customers to understand, diagnose and address this reboot issue. If this requires a revised firmware update from Intel, we will distribute that update through the normal channels. We are also working directly with data center customers to directly discuss the issue.
bron (https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/)
en nog een om te glimlachen.... (https://lkml.org/lkml/2018/1/3/797)
systemdeveloper
12/01/18, 20:50
En daar gaat het marketingkapitaal van de slogan 'Intel Inside'...
12863
Zouden dit soort partijen niet een 'fuck up' potje hebben? Had volkswagen ook :)
Yourwebhoster
13/01/18, 10:35
Zouden dit soort partijen niet een 'fuck up' potje hebben? Had volkswagen ook :)
Wellicht moet de CEO de winst van zijn aandelen hier oa voor inleveren. Dit is een fuckup van een formaat die ze nooit hadden voorzien lijkt me. Anyways, tenzij je groot inkoopt zoals Amazon dan zal je helaas hier financieel niks van terug zien gok ik.
Het is vervelend, maar we komen dit elk kwartaal wel tegen inmiddels. Nu is het Intel en het is ook wel eens OpenSSL of iets dergelijks geweest. Wat ik zelf kwalijker vind is hoe lang het heeft geduurd voordat bijvoorbeeld Ubuntu met patches kwam.
Alentejo Hosting
15/01/18, 12:03
Check of je server (Linux) vatbaar is for Meltdown en/of Spectre:
https://github.com/speed47/spectre-meltdown-checker
Yourwebhoster
15/01/18, 17:37
Het is vervelend, maar we komen dit elk kwartaal wel tegen inmiddels. Nu is het Intel en het is ook wel eens OpenSSL of iets dergelijks geweest. Wat ik zelf kwalijker vind is hoe lang het heeft geduurd voordat bijvoorbeeld Ubuntu met patches kwam.
Hoewel het vervelend is, ben ik het oneens dat we dit elk kwartaal tegenkomen omdat de impact significant groter is dan wat we ooit hebben meegemaakt. Tuurlijk, OpenSSL heeft fouten. Apple heeft fouten. Microsoft heeft fouten. Maar in dit geval is de fout veel omvangrijker dan de OpenSSL fout. Hoewel encryptie op het web werkt met OpenSSL, is het kwalijk dat zowel op de client computer en de server de encryptie geen nut heeft (zelfs met JavaScript kan dit misbruikt worden). Bovendien moet elk apparaat gepatched (en in 99% van de gevallen herstart) worden, wat niet altijd kan. De impact van OpenSSL is dan toch stukken kleiner ;-). Dat betekend trouwens niet dat het als minder gevaarlijk gezien moet worden.
Hoewel het vervelend is, ben ik het oneens dat we dit elk kwartaal tegenkomen omdat de impact significant groter is dan wat we ooit hebben meegemaakt. Tuurlijk, OpenSSL heeft fouten. Apple heeft fouten. Microsoft heeft fouten. Maar in dit geval is de fout veel omvangrijker dan de OpenSSL fout. Hoewel encryptie op het web werkt met OpenSSL, is het kwalijk dat zowel op de client computer en de server de encryptie geen nut heeft (zelfs met JavaScript kan dit misbruikt worden). Bovendien moet elk apparaat gepatched (en in 99% van de gevallen herstart) worden, wat niet altijd kan. De impact van OpenSSL is dan toch stukken kleiner ;-). Dat betekend trouwens niet dat het als minder gevaarlijk gezien moet worden.
Helemaal waar; waar gewerkt wordt worden fouten gemaakt. Helaas soms groter en/of met meer impact dan andere keren. Dit is een kwalijk lek en de impact is groot, dat ben ik meer dan met je eens!
"Linus Torvalds declares Intel fix for Meltdown/Spectre 'COMPLETE AND UTTER GARBAGE'"
En hij heeft niet echt ongelijk.
https://techcrunch.com/2018/01/22/linus-torvalds-declares-intel-fix-for-meltdown-spectre-complete-and-utter-garbage/