[Folyamatosan frissítve #4] Meltdown és Spectre - kihatások a teljesítményre patchelés után

 ( trey | 2018. január 8., hétfő - 10:56 )

syslog-ng fordítás

Epic Games

DragonFly BSD

BigData, Tensorflow ...

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

a java rémisztően néz ki

sub
--
"Sose a gép a hülye."

Ööö...az Epices hírnél miért egy archive.is-es link van belinkelve? Még él az eredeti poszt: https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update#post132642

biztos tudjak, hogy gyakran torolnek forumtemat?

Tippre a build szerverek és a fejlesztői gépek nem igazán lesznek felpatchelve...

A processzorok visszahívása ilyen esetekben szóba sem jöhet?
Elvégre szoftveres javítás után is csak teljesítmény csökkenés árán működik.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

De szóba jöhet, de nem fogják meglépni. Eleve, akkor most szerinted az Intel álljon neki, és gyártson le 10 milliárt gen2-s i3-t? Vagy ezt így most hogy?

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Igaz. Sok hülye felhasználó észre sem veszi, hogy nem azt kapott a pénzéért amit venni akart. Majd ha valaki nagyon reklamál vagy perel azt kártérítik.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Te sem vetted észre.

--
Tortilla; A tortilla a spanyol nyelvterületek tradicionális étele! Hagyd már; ABBA!; Droppboksz

Szerintem úgy értette, hogy azt nem veszik észre, hogy a patch után belassult a rendszer, nem úgy, hogy a Meltdown-t, vagy a Spectre-t nem vették észre.

Ìgy van, átlagfelhasználásnál mindegy. Ebböl is látszik, hogy mennyit érnek a mai hardverek ill. szoftverek.
Egyébként meg nincs viszonyítási alap sem. A sok összeszart windows telepítés trojan-nal, backdoor-ral, bitcoin miner-rel stb... alapból is lassú.

--
robyboy

Én egy szóval nem mondtam, hogy mindegy, mert szerintem egyáltalán nem mindegy. Én csak azt mondtam el, hogy szerintem dejo mire gondolhatott, hogy az átlagjóska nem veszi észre a dolgot.
Az igaz, hogy egy összeszart windows az alapból is lassú, de win-t rengetegen használnak az ipari, kereskedelmi, kreatív szektorokban is, ahol viszont baromira nem lesz mindegy és ők észre is fogják venni.

Nem mondtam, hogy mondtad :) úgy gondolom, hogy sokan észreveszik, sokan nem. Otthoni Windows 10-es Celeron 1007U-s asztali miniPC-n semmi változást nem tapasztalok peccselés után. Ez a gép átlagfelhasználás céljából van, arra elég is, még így is. Példám biztosan nem egyedi, de lehet nem is tipikus.

Most a média felfújja ezt az egészet, pár hónap múlva meg röhögni fogunk az egészen, egy Failure lesz a sok közül - amúgy már most is az, elég szépen gyarapodik a CVE könyvtár.

--
robyboy

Az átlagfelhasználó lehet, hogy nem fog ezzel foglalkozni, de akik komoly munkát végeznek a géppel, azok tuti fogják még szidni az intelt. Meglátjuk.

Nos, a megoldás a pénz visszafizetés. :)

Minimum. De a kártérítés még igazságosabb lenne.

És mire cserélnék ki?

Vagy arra gondolsz, hogy visszaküldjük a processzort, és helyette kapunk egy 30%-kal gyorsabbat, ami a patch után kb. akkora sebességű lesz, mint az eredeti a patch nélkül? Aztán ha az alaplap nem támogatja az új procit, akkor az így jártunk esete lesz?

Arra a javított verzióra amit egy-két hónapon belül legyártanak. :)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

szerintem egy év múlva jönnek, a raktárkésszeletet el kell adni :)))

ezentúl a dobozon lesz egy apró betűs rész:

Fast, Good or Cheap. Pick two.

Igazából a Cheap-et már nem nagyon lehet ráírni egy valamire való processzorra. :(
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

AMD marketingesei most javában (no pun intended) zakatolnak, hogy akkor most hogy is írjuk rá a dobozra, hogy meltdown,spectre mentes processzor, és hogy hogy rajzoljunk intel -spectre -meltdown vs amd factory state grafikont, ami mutatja, hogy az amd már nem is lassabb esetleg, ha vesszük ezt a javítást. Kicsit hasonló a kérdés, mint amikor kiderül, hogy hát olcsóbb, de többet fogyaszt, akkor megérte-e.

Arról volt szó, hogy a spectre az AMD-t is érinti, így ezzel a felirattal még egy kicsit várni kell.

A Spectre-ből csak az egyes érinti az AMD-t és az is csak Linuxon és ott is csak bekapcsolt BPF JIT esetén, ami non-default kernelbeállítás.
# sysctl -a | grep bpf
Legalábbis ezt mondták...

Nálam :
kernel.unprivileged_bpf_disabled = 0
net.core.bpf_jit_enable = 0

Akkor ez most jó ??

..._disabled = false? háhogy?

https://kernelnewbies.org/Linux_4.4#Unprivileged_eBPF_.2B-_persistent_eBPF_programs

true-ra állítva tiltod le, hogy non-root userek is használhassák.

és ő nem ezt akarja?
(amellett, hogy eleve letiltotta)

Passz, lehet, hogy defaultból 0.

A kernel.unprivileged_bpf_disabled arra való, hogy non-root userek is futtathassanak eBPF programot, a JIT-hez nincs köze, tehát jó.

Most valami újat kell kitalálni. Javítani akkor kellene, ha implementálási hiba lenne. Azonban itt protokoll hibáról van szó. Tehát előbb ki kell találni egy olyan protokollt/algoritmust, ami legalább elvi szinten nem hibás. Után lehet nekiállni a konkrét megvalósításnak.

Az egy dolog, hogy újra kell tervezni az architektúrát. Egy másik meg, hogy hány hibás lapka van legyártva, készleten, piacon, amiket ugyanúgy el fognak adni, mint eddig. Mert kb. mindenki leszarja (értsd: nem akar rajta bukni) és eladja a meglévö készleteket ugyanúgy, mint eddig.
Ez nevezhetjük az igazi átb@szásnak, mert már mindenki tud a dologról, ergo szándékosságról is beszélhetünk.

A CPU visszahívásnak ezekben az esetekben minden esetre müködnie kellene.

További aggályom az esettel kapcsolatban, hogy elhitetik a felhasználókkal, hogy ez a hiba orvosolható, csak telepíteni kell ezt+azt a peccset. Ez teljesen téves elképzelés, de nyilván az indulatok csitítására böven alkalmas.
Sajnos ez a hiba szoftveresen nem javítható, a Workaround-ot nem nevezném javításnak.

--
robyboy

Akkor az eladott CPU-k után részleges visszatérítés és az ezután ugyanezzel a hibával eladandó CPU-k esetében érzékelhető árcsökkentés!
De szerintem fordítva fogják megoldani és a hibával nem érintett következő generáció árát fogják jól feltolni.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Szerintem is. Ìgy kell a hátrányból elönyt kovácsolni.

--
robyboy

Szerintem ezt meg fogjak fejelni olyan "akcioval", hogy regi procidat beszamitjak es az uj arabol igy adnak 10-15% kedvezmenyt, amivel arban ott lesznek mint eredetileg, de igy elmondhatjak hogy ok jo fiuk, plusz jobban biztosithatjak, hogy intelt vasaroljanak a tomegek.

Nem tudnád bebizonyítani, mekkora kárt szenvedtél el.

--
Tortilla; A tortilla a spanyol nyelvterületek tradicionális étele! Hagyd már; ABBA!; Droppboksz

Pedig itt pont, hogy teljesen egzakt mérési módszerekkel kimutatható egy előtte-utána állapot, nem kell a levegébe beszélni egyrészről, másrészről meg már az egész világ tudja, hogy hibás a termék, és azt az Intel is "elismerte". Van egy funkció, amiért fizettél, ami nem működik, és ami garantálta volna a termék eredeti teljesítményét.

Ez nem ugyanaz, mint amikor veszel egy autót, ami amúgy menne 300-al is, de leszabályoz 250-nél biztonsági okokból.
Itt nem tudtad, hogy amit veszel, az milyen "rejtett "tartalékokkal"" rendelkezik. Ja, és még nincs vége. Ki tudja, még mik lesznek itt? Csak ki kell várni.
--
robyboy

Egyik szerverhostingossal beszélgettem, és ő például felvetette hogy ez a hiba azonos szerverelhelyezési díj mellett neki villanyszámlában fog bevételkiesést okozni.

Mire hivatkozva kérnéd a cserét?
Csökkent a magok száma, alacsonyabb lett a frekvencia?

A hivatalos CPU specifikációban sehol nem szerepel, hogy az általad használt build mennyi idő alatt fut le az adott processzoron..

Így van. Nem lehet mire hivatkozva cserét kérni. A procik működnek mai is, megvannak a magok, frekvencia, futtatják a szoftvereket. Az Intel anno eladáskor sehol nem ígérte, hogy hibátlan lesz a proci, és biztonság terén is 100%-ban lesz flott, emiatt most az asztalt sem lehet verni.

A procik visszahívása sem jön szóba, ha még lenne is olyan új proci gyártósoron, amely már nem tartalmazza a hibát, akkor sem tudnának hirtelen annyi procit gyártani, amennyi kéne a cseréhez, meg akkor minden korábbi generációból, foglalatból is kéne gyártsanak.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Pár évtized múlva processzorok lesznek az emberekben is, ld. cyborg-ok, különbözö célokból. Aztán majd sokan meghallnak egy számítási hiba, vagy biztonsági rés miatt. Perelni majd akkor sem lehet, mert aláíratnak mütét elött egy papírt, hogy vállalod a rizikót.

"kicsit" elöre szaladtam az idöben.

--
robyboy

Persze latom a smajlit, de az egy-ket honap kevesnek tunik.

A chip legyartasa fizikailak (az eljaras lassusaga miatt) honapo(ka)t vesz igenybe ez csak az az ido, amig a teljesen vegleges(nek gondolt) designt a gyarto megkapja es kigordul az elso chip. Ami szinte biztos, hogy nem lesz jo, tehat tovabbi iteraciokra lesz szukseg, ahol szaguldanak a hetek (meg ha csak maszkot kell valtoztatni akkor is eleg sok ido, de ha base layer akkor meg durvabb).

Ezelott meg meg is kell tervezni a chipet, ami nem nullarol indulva is ev+ altalaban, de nem ritka, hogy tobb ev, mire gyartasba tud kerulni (az emiltett prociknal joval egyszerubb dolgok eseten is).

Es ez csak a muszaki resze, valoszinuleg a donteshozok es marketingesek is vitatkoznak egy par honapot, meg felmerik a terepet mielott zold utat adnanak a projectnek.

Szoval ha az egesz most elkezdodne, akkor is evet vagy eveket kellene varni, mire a vasarlo a kezebe vehetne a termeket.

Szerintem az Intelnek azok a prociai amiket most dobnak piacra, lehet, hogy mar vagy ot eve odakerultek a managerek asztalara tervkent (otletkent).

/sza2

Viszahivni az oszes erintett CPU-t szerintem relativ "abszurd" elvaras.
Mivel az Intel es partnerei mar Junius/Julius-tol tudnak rola, de ennek ellenere tovabbra is ertekesitettek a most mar nyilvanvaloan sebezheto termekeket - kihasznalva az embrago nyujtotta vedelmet - azok cserejet (amint lesz javitott hardware) szeritem jogosan kerhetik a vasarlok.
Valoszinunek tartom, hogy meg is indulnak a perek ha az Intel es tarsai nem lepnek hamarosan.

Epic-et nem ertem, ha nagyobb a CPU hasznalat, akkor inditsannak tobbet. Miert fogjak erre a problemaikat?
Azert felho. Majd verjek le a felho szolgaltaton hogy a node-ok nem az adott teljesitmenyt hozzak. Majd a szolgaltato verje le az Intelen, problem solved.
Vagy menjennek dedikaltra es ne upgradeljennek. Gondolom naluk (legtobb ) szerveren egy service fut, igy igazan nem gond hogy mas futo process eler nem neki szant memoria teruletet.

getppid(2) 4x lassabb, effective minden ami systemcall intensive, halozat/disk hozza feres lassabb lesz,
nem valszinu, hogy memory mapped I/O jobb lenne. Ill. megszakatas kezelesre is hasonlo hatas varhato.

Egy contex switch koltsege 386-os idokre emlekzetotoen magas lett.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

386? Wtf? Forras?

Merd le magad ;-)

Nem olyan nehez egy syscallt loopba rakini, mond meg ha mast latsz.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Merem a faszomat, foleg hogy nincs az irodaban 386, nincs is mivel osszemernem.

Ettol fuggetlenul kicsit baromsagnak hangzik, ezert kertem egy forrast. Foleg, hogy az Atom se erintett emlekeim szerint (fixme)

Koszi, akkor az a resze nem igaz (abban a reszeben nem is voltam biztos, mint irtam).

De a "core i7 context switch syscall sebesseg == 386 context switch syscall sebesseg" allitast tovabbra is baromsagnak tartom amennyiben nem latok ra forrast.

beszorozva az órajel-különbséggel sem? (csak tipp)

Azzal szamoltam, tickre nem usecre.

386 os ota kb 4 gyorsabb lett egy syscall ha ora uteseket nezel.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Lehet benézem, de az én procim nincs benne ebben a listában Xeon X3363 2.8 GHz 4 magos.

https://ark.intel.com/products/33933/Intel-Xeon-Processor-X3360-12M-Cache-2_83-GHz-1333-MHz-FSB

remekül hangzik
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.2 | 4.4.37-janos

És hogy legyen jó hírem is: gép BIOS frissítés után a fordítás idő nálam normalizálódott. De ezzel együtt a frissítés bármennyire szükséges, akkor is orosz rulett. Az eddigi visszajelzések alapján legtöbb embert nem nagyon érinti, ugyanakkor ránézésre teljesen random szoftver - hardver kombinációknál durva lassulások vannak.

.

akkor nagyon gyorsan neki kell állnia mindenkinek, hogy jobb, gyorsabb kódokat állítanak elő, és végre 50 év után gondot fordítsanak az optimalizálásra is.

+1

Szerintem ebből nem lesz semmi. Mindenki új, nagyobb teljesítményű vasakat fog vásárolni, és kész. Sokkal egyszerűbb, mint előről kezdeni mindennek a fejlesztését mondjuk úgy optimalizáltan.

--
robyboy

2018 a szervergyartok nagy eve lesz. Ezzel a hibaval most berugtak a penzszivattyut de nagyon. Mar szamolom hany vasat kell vennunk a vmware clusterbe.

infraskent az csak jo. tobb penz == tobb jatekszer :)

(sub)
-------
It is our choices that define us.

én ezeket mértem:
- ez a hardver: laptop, i7-3632QM CPU, 16G RAM, Samsung 840 EVO
- ez a szoftver: Manjaro, gcc 7.2.1, amit buildeltem: syslog-ng-3.13.2
kernel 4.9.68-1-MANJARO #1 SMP PREEMPT
kernel 4.9.74-2-MANJARO #1 SMP PREEMPT (igen, benne van a /proc/config.gz-ben a CONFIG_PAGE_TABLE_ISOLATION=y)
- ahogy buildeltem: sima makepkg (a PKGBUILD file-ban sime make van, próbáltam make -j4 -gyel is)

- az eredmények:
4.9.68:

real 3m52.591s
user 3m32.840s
sys 0m18.067s

real 3m51.345s
user 3m32.587s
sys 0m17.597s

make -j4-gyel:

real 2m6.929s
user 3m34.367s
sys 0m16.463s

4.9.74-2:

real 3m56.452s
user 3m32.223s
sys 0m21.997s

real 4m11.778s
user 3m43.383s
sys 0m23.403s

make -j4 -gyel

real 2m11.700s
user 3m36.460s
sys 0m19.947s

szóval nem számottevő a különbség

Én a munkám során használatos numerikus módszereimet teszteltem, de nem csak kicsi, hanem semmi különbség nincs a számítási teljesítményben.

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

Nyilván, mert a tisztán számítási teljesítményt nem érinti... :)

Belegondoltam, az lenne igazán a "dupla zakó", ha kiderülne, hogy peccselés után gyorsabbak lettek a rendszerek :)

--
robyboy

Erre sajna zéró esély van, mert egy hardveres megoldást kiváltani egy szoftveressel mindig lassabb.
--
"Sose a gép a hülye."

Átalában igaz. De néha nem. Például fordítsd le gcc -O2 -vel assembly-re a

int modulo10(int num) {
   return num%10;
}

Bár ezt assembly oktatáson div-vel oktatták, amely visszaadja a maradékot is, ennek ellenére a GCC szoftveres trükkel tud dupla gyors megoldást (szorzás, shift, összeadás, kivonás).

Nekem a régebbi "RAID"-vezérlök jutottak az eszembe, amik lassabbak voltak, mint maga a CPU, ezért aztán nagyobb teljesítményt lehetett elérni a tisztán szoftveres RAID-ekkel.

Persze ez itt most már helyzet, de vicces lett volna átélni egy ilyet, azt hogyan magyarázta volna ki Àrpi :)

--
robyboy

A múlt héten arról írt a The Guardian, hogy az első három csoportos keresetet beadták az Intel ellen. Egyes hírek szerint azonban az Intel további csoportos keresetekre számíthat. Megjegyzem, nagyon helyesen és jól megérdemelten.

A lakájmédia és az informatikai biztonsággal foglalkozó orgánumok természetesen mélyen kussolnak, elkerülendő, hogy még nagyobb csorba essék hardvermultiék hírnevén. A szélsőségesen vadkapitalista ZDNet ráadásul odáig merészkedik, hogy a botrányra való tekintet nélkül lehoz egy Intelt fényező cikket, avagy elülteti a bogarat birkáék fülében, mire kell majd gyűjteni a zsetont, ha már a gyári hibás, agyonpeccselt processzorok nem elég gyorsak.

A fizetett bértollnokok tehát szorgalmasan teszik a dolgukat. Nehogy eszébe jusson sokaknak számon kérni az Intelen egy gyári hibás termék gyári hibáit. Nehogy ráeszmélhessen valaki, hogy a jelenleg a felelősség alól kibúvókat kereső, és a magát rögtönzött PR-köpönyegforgatással mosdató Intel profitéhsége, versenyelőny mindenek fölé helyezése, mérhetetlen felelőtlensége és nemtörődömsége vezetett ide. Nehogy eszébe jusson sokaknak számon kérni az Intelen, hogy annak ellenére dobták piacra az új, Coffee Lake processzorfamíliát, hogy már rég tudtak a galibáról. Nehogy eljusson valakinek a józan eszéig, hogy utóbbi nem volt más, mint a fogyasztók szándékos megtévesztése. Nehogy ne törődjön bele mindenki a teljesítménycsökkenésbe és ne engedelmes cloud-birka módjára bővítse gépparkját, a kieső teljesítményt pótolva.

A lakájmédia elért sikereibe pedig már itt a HUP-on is úton-útfélen belebotolhatunk. Többen új gépek vásárlásáról és az Intel számonkérésének hiábavalóságáról vagy lehetetlenségéről beszélnek. Sőt, valaki odáig merészkedik, hogy a számonkérés hivatkozási alapját is megkérdőjelezi. Így már értem, hogyan süllyedhettünk idáig, ha a fogyasztók képesek ennyire saját maguk és egymás ellenségei lenni.

Ez ugyanaz az eset, amikor egy orvos orvosi mühibát követ el, és emiatt meghal a páciens. Aztán utána fel sem mond, meg el sem ítélik, mert kimosdatják inkább a felelösségrevonás helyett.

Sajnos a világot nem tudjuk megváltoztatni, van böven elég pénze, piaci hatalma, befolyása az Intelnek, hogy kb. minden úgy történjen, ahogy ö szeretné.

Most tényleg: mit vegyen az ember, ha nem Intelt? Van IGAZI alternatíva? Az elmúlt évtizedekben szépen leölték a konkurrenciájukat.
AMD talán jó úton halad, de a Spectre pl. öket is érinti, egyik kutya, másik eb.

Talán nem másolni (lopkodni) kellene a technológiát, hanem jól kitalálni, és jól fejleszteni.

--
robyboy

[ 0.000000] Kernel/User page tables isolation: enabled

Ööö... izé... mértem Java projekt fordítást, normál esetben 2-4 perc egy komplett fordítás (Wildfly integrációs tesztekkel, i7-6700HQ) és pár másodpercen belül volt a különbség új kernellel is... vajon mit mértem rosszul? :)

Nem mit, min. Az Intelfényező üzemmódba való átkapcs előtt azért vedd figyelembe azt is, hogy nem mindenkinek futja i7-6700HQ-ra és egy nem bika gépen nagyságrendekkel nagyobbak a különbségek. Nagyon örülünk, hogy ilyen Frankó géppel ilyen Frankón megúsztad a javítással járó performance csökkenést. Ez viszont mindenkinek sovány vígasz, aki gyengébb hardvert használ (pl. 2. és 3. generáció). Amiken egyébként inkább van értelme mérni, mivel hardvermultiék azokat akarják elsősorban kidobatni, nem a félmilliós laptopod 6. generációs processzorát.

"Az Intelfényező üzemmódba való átkapcs előtt azért vedd figyelembe azt is, hogy nem mindenkinek futja i7-6700HQ-ra és egy nem bika gépen nagyságrendekkel nagyobbak a különbségek."

Ez egy mérés, minden mást te értesz bele. Várom a mérésed a nem bika gép kapcsán.

"a félmilliós laptopod 6. generációs processzorát"

Aham... 230 ezer forint volt. Bruttó.

Idézet:
Várom a mérésed a nem bika gép kapcsán.

Nem mérés ugyan, de rokonságban egy low-end, "lemerült ceruzaelemről 8 órát elfut mert kenyérpirító számítási kapacitásával bír" Atomon r=1 user desktop felhasználással nincs észrevehető különbség.

Úgyhogy a szemét vadkapitalista extraprofitos Intel biztos a középmezőnyt célozta, hogy átverje a usereket.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Èn is ezt tapasztaltam egy Asus VM40B-n, Windows 10 alatt, viszont:

1. A BIOS nincs és lehet nem is lesz frissítve
2. A Windows 10 patch csak a Meltdown-t foltozta be tudtommal
3. A Spectre foltozása fog nagyobb teljesítményveszteséggel járni

Tanulság: várjuk ki a végét

--
robyboy

you're holding it wrong

Subscribe.

A saját gépeinken egy hét múlva az elmúlt havi CPU grafikonokat, hogy van-e különbség (leginkább standard desktop usage), eddig szerencsére nem jöttek lincselni, hogy fúdelassúminden.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ehhez mit szóltok?

NetApp nyilatkozat:

"ONTAP: Unlike a general-purpose operating system, ONTAP does not provide mechanisms for non-administrative users to run third-party code. Due to this behavior, ONTAP is not affected by either the Spectre or Meltdown attacks. The same is true of all ONTAP variants including both ONTAP running on FAS/AFF hardware as well as virtualized ONTAP products such as ONTAP Select and ONTAP Cloud.
While ONTAP Select and ONTAP Cloud are not directly affected by these attacks, these attacks may be possible against the utilized hypervisor platform. NetApp recommends working with your hypervisor and cloud platform vendors to ensure that your NetApp product is running on a secure and patched platform."

--
robyboy