[Folyamatosan frissítve #17] Minden, amit a #meltdown / #spectre processzorbugokkal kapcsolatban tudni érdemes

Címkék

Google

Ismét a Google biztonsági csapata jeleskedett, elérhető az igazi technikai leírás

Google: napjaink CPU sebezhetőségei: amit tudnod érdmes

Red Hat

Red Hat tájékoztatás a problémákkal kapcsolatban

Ubuntu

Microsoft

A Microsoft biztonsági útmutatót adott ki az ügyben

FONTOS! Microsoft operációs rendszerek és az antivírus szoftverek

Microsoft Edge és Internet Explorer böngészők

Teszteszköz a Microsofttól

Teszteszköz Alex Ionescu-tól:

Apple

VMware

FreeBSD és forkjai/variánsai

A FreeBSD projekt (is) tud a problémáról és dolgozik a megoldáson

Mozilla

Qubes OS

Egyéb / Általános

#Spectre probléma:

#Meltdown probléma:

Demók

Kapcsolódó cikkek

Kapcsolódó fun

Hozzászólások

Szóval már az ARM is vcallott, itt az ideje, hogy a Qualcomm is adjon ki közleményt.

A Qualcomm a legtobb chip designjaban nem veszi at egy az egyben az ARM holdingtol a magok terveit, hanem sajat, adott ARM verzioval kompatibilis utasitaskeszletu chipeket fejleszt (az Apple is igy tesz). A legelso 64 bites Qualcomm szeria viszont nem sajat fejlesztesu magokat, hanem kompletten az ARM holding magjait hasznalta fel es ez az ami bekerult a Nexus 5x telefonba.

---
Apple iMac 27"
áéíóöőúüű

Ami érdekes, hogy a Google meg is hosszabbította a Nexus 5x és Nexus 6P supportját, a security patch-eket illetően. Az eredeti EOL talán 2017 November volt, kitolta egészen 2018 Novemberig.

Szerintetek van-e ennek köze az ARM-et érintő vulnerability-hez?

https://support.google.com/nexus/answer/4457705?hl=en

In order magok nem erintettek. Out of order magok igen. Mind1, hogy qualcomm vagy mas arm gyarto cpuja. A tobbi arch is erintett ha hasznal out of ordert. AMD nyilatkozta azt, hogy nala nulla kozeli egy sikeres tamadas a processzorain Meltdown serulekenysegnel.
Spectre es Meltdown nem fenyegeti az in-order cpu-kat, azaz pont az olcsobb ARM procikat.
Spectre foltozasa nem jar brutalis teljesitmenycsokkenessel. Meltdown javitasa viszont igen, plane Intelen.

A sajtoban meg nem ertik tisztan mi vam:
http://tablet.hvg.hu/tudomany/20180104_intel_processzor_hiba_microsoft_…

Ez így nem pontos. Vegyesen ad ki a Qualcomm teljesen saját fejlesztésű arm magokat használó és Arm által tervezett cpu magokat használó chipeket. A 32-bites korszakból is van egy csomó Cortex-A5/A7 Qualcomm. Tavaly is kihozott a Qualcomm tisztán Cortex-A53 magokat használó chipet, például Snapdragon 630-at. Pedig már akkor is volt saját Kryo. Sőt még vegyes chipjük is van a Snapdragon 835, amiben Cortex-A73 és Kryo 280 is van.

Normális HUP-ot használok!

jól beindult a buli

--
Vortex Rikers NC114-85EKLS

Nagymértékben javítaná a csatolt cikkek/nyilatkozatok olvashatóságát, ha nem twitter által rövidített linkeket baszkodnád bele. Ugyanis vannak olyan helyek, ahol a tűzfalszabályzat tiltja a közösségi hálózatok és azok csatolt részeinek az elérhetőségét.
Tudom, tudom, akkor már szerkeszteni is kéne, nem csak copy-pastezni a tweeteket és az rengeteg munka...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

A panaszodat küldd el a cégvezetésednek. Kérd őket, hogy a mai felgyorsult világban ne zárjanak el az IT hírek, bejelentések leggyorsabb forrásától, a Twitter-től.

Amit kérsz, ilyen tempó mellett lehetetlen.

De segíts be elzárt barátaidnak! Fogj egy okostelefont, oldd fel a twitter linkeket, szedd egy csokorba és küldd be kommentként!

Itt jelezném, hogy a cikkekhez elkövetett offtopik visszajelzéseket mától ignorálom és nem reagálok rájuk. A visszajelzés megfelelő módja:

https://hup.hu/visszajelzes

--
trey @ gépház

Nem mellesleg ha az "uj hozzaszolasra" kattintassz, eddig pontosan oda dobott az oldal ahol az uj komment van.

A twitter magic utan viszont bejott a jol megszokott webes rakfene, az ugralas, szoval allandoan keresgelhetem, hogy vegulis hova ugrabugralt a cucc.

Szerk: kikapcsoltam a "Hup twitterje" vagy mi a fenet, ugy latszik az csak az oldalsavra vonatkozik.

Eddig mindig ugy hivatkoztam a HUP-ra, mint arra a funkcionalis oldalra, amit meg nem rantott be magaval a csilivilli JS baromsag. Azt hiszem felul kell vizsgalnom ezt, innentol kezdve ugyanolyan szar ez az oldal is UX szempontbol, mint az osszes tobbi :(

összevadasztam azoknak a Twitter cimét akiknek a blogját szoktam olvasni, és felíratkoztam rájuk. Új arcokat meg ezeknek a követói között találok. A nem releváns hülyeségeiket ignorálom / továbbgörgetem. Ha retweetelnek vmi offtopic szart, azokat csípőből tiltólistára teszem. Ezek után csak a szakmai kontent marad meg. Így egész fasza hírforrást csináltam magamnak.
--

Jó de ez arra vonatkozik hogy a Twitter címeket összeszedted. Nincs azzal semmi baj ha valaki Twitterezik félreértés ne essék. De ez egy hup.hu ami egy """""szakmai"""" oldal sok csillaggal. Ami abból áll manapság, hogy belinkeli a twitter*.com* -ot kb. Szerintem ennek az oldalnak nem twitter linekről kellene szólnia.. de lehet egyedül vagyok ezzel az állásponttal .. :/ Régen ez azért kicsit igényesebb volt. Mert lassan ott járunk hogy a hup.hu lehetne egy redirect trey twitter oldalára.. :/

Én ugyanezt csináltam egy RSS olvasóval, ahol ténylegesen követhetem azt, hogy mit olvastam, és mit nem, nem veszik el egy 10-20 napos cikk csak mert nem volt időm elolvasni amikor friss, stb. Értem én, hogy a twitter népszerű, és sok újdonsággal lehet ott találkozni, de a konkrét cikkek továbbra sem ott születnek, és ha már van egy eredeti forrás, amire sokkal hatékonyabb eszközökkel fel lehet iratkozni... nem tudom tényleg miért tartod jobbnak.

A gond az, hogy szívesen vennék fel titkárnőt, hogy lépést tudjak tartani a történésekkel és ne 1-2-3 napot csúszó, hanem - mint most - akár 5 perces hírekkel jelentkezzek, de sajnos a bérének kigazdálkodása problémát okozna.

Szóval értem, hogy sok minden jól lenne. Nekem is. De szívesen bővülünk. Bankszámlaszámot, bitcoin wallet címet hamarosan közzétesszük!

--
trey @ gépház

"A panaszodat küldd el a cégvezetésednek"
"Amit kérsz, ilyen tempó mellett lehetetlen."

Tegnap toltam egy blogbejegyzést, amiben lényegében egy tweet-et hivatkoztam. Nem volt több fél percnél hivatkozni a forrást, és idézni kép linkkel együtt. Nem megoldhatatlan.

De ha nem akarod csinálni, mármint nem akarsz munkát belefektetni, miért teszed? Ez ebben a formában rossz. Többen, sokan panaszkodnak rá. Láthatod, hogy nem arról van szó, hogy 1-2 ember picsog. Tényleges problémát okoz korlátozott környezetben, és a navigációt is elrontja.

Fogalom nélkül írsz. Szombaton délután reagálsz egy csütörtök hajnaltól délig folyamatosan követett, kiszűrt és frissített cikkre. Óráim mentek el azzal, hogy ezt összeállítottam. Kérlek ne beszéljetek nekem itt fogalom nélkül.

Offtopikot kértem, hogy fejezzétek itt be. Visszajelzés helye a visszajelzés. Továbbá, ez itt nem kívánságműsor.

--
trey @ gépház

Amikor a .NET-ed, meg a félresikerült processzortervezés mellett hősködsz, valahogy nem ez a véleményed. Sőt, elvárod, hogy valaki Intel mérnök, .NET fejlesztő, meg NP-teljes problémákon ügyködő matematikus legyen azért cserébe, hogy a véleménye érjen valamit. Magyarul, vagy akkor hazudsz vagy most.

Nem mondtam, hogy rendben van, sem azt, hogy nincs.

http://a.te.ervelesi.hibad.hu/hamis-okozat

Tudniillik, hajbazer XP user úr (aki a konkrét tettek mezején is ad a biztonságra és takarékoskodik az erőforrásokkal) ScriptBlock-ot használ, aminek köszönhetően meg se jelennek azok az elemek, amik miatt Saxus Mérnök Úr (aki 21. századi technológiai kényelmeskedése közepette operációs rendszerének frissen™ tartásától várja a biztonságot™) épp nyüszít a házigazdának.

Még mindig: http://a.te.ervelesi.hibad.hu/hamis-okozat

Én a kisujjamat se mozdítottam, hogy ne legyenek ott a Tweet-ek. Már első látogatásomkor se voltak ott.

Számomra tehát a Twitter dráma irreleváns. Arra hívtam fel csupán a figyelmed, hogy úgy akarsz beleokoskodni trey dolgába, ahogy fordított esetben téged is felháborít, ha valami hozzád közel állót kritizálnak. Tőlem elvárod, hogy beletörődjek a felelőtlenül megtervezett processzorokba, meg a .NET erőforráséhségébe, mindezt azért, mert szerinted nem értek hozzá, a Xeon-jaidon amúgy se bloat a .NET, sőt, NP-teljes problémát se lehet megoldani assembly-ben.

"Én a kisujjamat se mozdítottam"

Ja, csak letiltottad a scripteket. Hazugság #1.

"Számomra tehát a Twitter dráma irreleváns."

Mégis itt osztod az eszet. Hazugság #2.

"ha valami hozzád közel állót kritizálnak."

Nincs intel részvényem. Hazugság #3.

"Tőlem elvárod, hogy beletörődjek a felelőtlenül megtervezett processzorokba"

Magyarul fel sem fogod a probléma lényegét.

"meg a .NET erőforráséhségébe"

Ezeket is rendszerint csak érzésre mondod. Hazugság #4.

"mert szerinted nem értek hozzá"

Igen. Mert te aztán annyira szép szakmai érveket hoztál fel bármire is.

"NP-teljes problémát se lehet megoldani assembly-ben."

Igen, látszik, hogy mennyire kibaszott mód értesz hozzá, még azt sem tudod, hogy miféle az NP teljes probléma és, hogy mennyire kurvára mindegy, hogy assemblyben, C#-ban vagy JS-ben, vagy akár QuickBasic-ben állsz-e neki.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ja, csak letiltottad a scripteket. Hazugság #1.

Nem a Twitter-ed miatt. A Chromium installálása után rögtön.

Mégis itt osztod az eszet. Hazugság #2.

Nem osztom az eszet, elmondtam a véleményem, amit ugyanúgy megtehetek, ahogy te is.

Nincs intel részvényem. Hazugság #3.

Senki nem állította, hogy lennének. Ha viszont valaki kritizálja a gyakorlataikat, máris megkérdőjelezed a kritizáló hitelességét amiatt, mert nem processzormérnök és ő sem tudna jobb megoldást.

Ezeket is rendszerint csak érzésre mondod. Hazugság #4.

Nem láttam még tőled funkcióazonos .NET vs C++ programokat egymás mellé tevő méréseket. Tehát ha én érzésre mondom, akkor te is. Ergo, fölösleges firtatnod.

Igen, látszik, hogy mennyire kibaszott mód értesz hozzá, még azt sem tudod, hogy miféle az NP teljes probléma és, hogy mennyire kurvára mindegy, hogy assemblyben, C#-ban vagy JS-ben, vagy akár QuickBasic-ben állsz-e neki.

Épp azt mondtam, hogy nem mindegy, mert a C#, a JS sokkal több erőforrást fog elpazarolni az NP-teljes problémád megoldása közben. Míg egy natív kódra forduló megoldást tudsz inline assembly-ben is optimalizálni.

"A Chromium installálása után rögtön."

Tehát tettél ellene bármit is vagy sem?

"Ha viszont valaki kritizálja a gyakorlataikat, máris megkérdőjelezed a kritizáló hitelességét amiatt, mert nem processzormérnök és ő sem tudna jobb megoldást."

Ja, csak veled ellentétben tanultam némi digitális technikát, fpga-t, assemblyt, (sőt, hova tovább, C-t is!) és felfogom, hogy mikor milyen szinten mi történik.

"Nem láttam még tőled funkcióazonos .NET vs C++ programokat egymás mellé tevő méréseket."

Mert mi a faszért implementálnám le ugyanazt két nyelven? Mindent ott kell leimplementálni, ahol érdemes. Amúgy megjegyzem, C#-ban is van unsafe kód, gyakorlatilag ugyanaz, mintha C-ben írnád. Egyébként meg te jössz azzal folyton, hogy fú mekkora bloat, de még egy kurva mérést nem láttunk tőled. Igazából egy kurva kódsort nem láttunk még tőled.

"az NP-teljes problémád megoldása közben."

Továbbra se zavarjon, hogy az NP teljes probléma azért NP teljes, mert nem igazán van neki polinomiális idő alatt lefutó megoldása. Ergo, teljesen mindegy, hogy egy vagy két millió év alatt fog lefutni az algoritmusod. Már, ha egyáltalán le fog futni valaha is.

"Míg egy natív kódra forduló megoldást..."

Remélem tisztában vagy azzal, hogy a .NET kód is natív kódként fut?

"...tudsz inline assembly-ben is optimalizálni."

Bámulatos, hogy ilyen jellegű optimalizációkra van, aki .NET-ben is képes. Inline assembly nélkül.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Míg egy natív kódra forduló megoldást tudsz inline assembly-ben is optimalizálni."

Csináltál valaha ilyet?

Mert úgy beszélsz róla, mint a szent grálról, de úgy nagyjából 10-15 éve jobb kódot fordít a C/C++ fordító a megfelelő paraméterekkel optimalizálva, mint egy átlagosnál kicsit jobb Assembly programozó. Nem beszélve arról, hogy a CPU ismeretében (helló, out-of-order!) elég sok utasítást fel tud cserélni a C/C++ fordító és a .NET/Java virtuális gép, úgy, hogy gyorsabban tud dolgozni a CPU, mint az egyféleképpen megírt Assembly kód.

Ha nem csak címszavakat ismernél a programozásból, hanem egyszer leülnél és tényleg megtanulnád a gyakorlatban a tizedét annak, amit leírtál, akkor elbujdosnál szégyenedben, hogy hogy lehettél ekkora balfasz...

"Mert úgy beszélsz róla, mint a szent grálról, de úgy nagyjából 10-15 éve jobb kódot fordít a C/C++ fordító a megfelelő paraméterekkel optimalizálva"

Jah, rémlik is valami slideshow még jó régről, valami eltés vagy bme-s arc tolta, ha jól emlékszem, ami kb arról szólt, hogy milyen jó is az, mikor az okos programozó megpróbálja optimalizálni a c kódját, ráadásul valami ránézésre nem túl bonyolult esetben. Az hagyján, hogy nyilván az jött ki, hogy általában kibaszol magaddal, és csak rontasz a helyzeten, de azzal kezdődött az egész kb, hogy ~"vegyük észre, hogy a compiler által gyártott kód a probléma elméleti minimuma, (x olvasás, y mv), szóval innen szép nyerni, de azért nézzük"

> Míg egy natív kódra forduló megoldást tudsz inline assembly-ben is optimalizálni.

offtopik, de emlékeim szerint amikor megmutattam, hogy a .NET 1.1 óta lehet natív kódot csinálni a CLR-ből, akkor valahogy hamar abbamaradt a beszégletés

amúgy a legszebb az, hogy a .NET simán megeszi a natív C-ben írt dolgokat is, szóval ha tényleg azon megy a pörgés, hogy miért nem lehet inline natív kód, akkor innen üzenem, hogy de lehet

Jó, lehet személyeskedni, de attól még szar ez a twitteres izé ide behányva. Nem mondom, hogy vissza kellene térni oda, amikor már azért ment a hiszti, amikor valaki egy 50 kbyte-s képet merészelt berakni egy blogposztba, de ez nagyon a ló túloldala. És ahogy láthatod, hónapok óta téma ez.

Ellenben nem kell ahhoz 20 évig portált^Wblogot üzemeltetnem, hogy tudjam, hogy hogyan fos.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ok, akkor kérlek magyarázd meg, hogy hogyan fogok én helyetted hup cikkeket szerkeszteni úgy, hogy ne ez a szájbabaszott twitterhányás legyen ott, hanem rendesen szöveg, mint régen?

Sajnos én már csak ilyen értetlen vagyok, hogy nem látom, hogy hogy tudom megpatchelni azt, hogy lusta vagy egy CTRL+C,V párost nyomni a drupal szerkesztőfelületén meg egy linket alárakni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Én erre akartam utalni fent, amikor meg lett mondva, hogy nem értek hozzá, és különben is órákig tartott a cikket frissíteni, meg összerakni. Aztán még reagálni se tudtam rá, mert meg lett mondva, hogy ne toljam az offtopicot.

Egyébként nem értem ezt az egészet. Mindkét félnek érdeke volna közös nevezőre jutni (az olvasóknak és a szerkesztőknek) az oldal formátumát tekintve. Nem értem a konokságot trey részéről. Van közösség, aki még eszközöket is adna a kezébe ahhoz, hogy kényelmesen tudjon tweeteket importálni az oldalba. Korábban részemről is érkezett felajánlás más jellegű fejlesztések tekintetében. Igény az nem volt rá. Úgy látszik jó ahogy van.

Információm nekem sem. Felajánlások voltak akkortájban, amikor téma volt, hogy merre fejlődjön a HUP. Rengeteg javaslat volt, de semmi konkrétum, hogy ebből megvalósuljon akár valami. Pedig egy csomó apróságra lehetett volna egyszerű megoldást találni. Például máig nem értem, hogy a hupper miért külön kiegészítő, és miért nem az oldal része.

De amíg a mentalitás ilyen, addig sok jóra nem lehet számítani.

Konkrétan azon lovagolunk ennyi kommentben, hogy ahelyett, hogy trey berakja a twitter widget kódját a bejegyzésbe, a szövegét rakja be és a benne lévő linkeket. És ahelyett, hogy közösen végiggondolná a két fél (olvasó és szerkesztő) hogy miként lehetne ezt úgy, hogy a szerkesztőnek és az olvasónak is jó legyen, akár úgy, hogy segítünk, megy a picsogás hogy offtopic (ami jogos) meg hogy milyen nagy munka volt összedobni ezt a bejegyzést.

Csak úgy nehéz, hogy meg sincsenek beszélve az igények, és minden le van rendezve azzal, hogy jó ez így, ha nem tetszik menj máshova, meg ha az a baj hogy a munkahelyen tiltva van a twitter, akkor "A panaszodat küldd el a cégvezetésednek." ahelyett, hogy beszélgetés alakulna ki hogy lehetne a problémát úgy megoldani, hogy trey-nek se legyen több dolga vele, és a hír is olvasható legyen hupos bejegyzésként.

Lehetne amúgy annyi megoldás a problémára, de én még azt sem értem, hogy a copy paste, ami nem vehet el több időt a mostani megoldáshoz képest, mint 1-2 perc miért nem jó. Mert nem jó, és elhiszem hogy van valami a háttérben amiről nem tudok. De diskurzus nincs, csak ellenállás és nyafogás mindkét oldalról.

Abban biztos vagyok hogy nem most lesz. :D
Azért írtam mert, a Weblaborral a következő dolgok történtek:

  • Létrejötte óta sokkal többen tudnak angolul, ezáltal nem olyan fontosak a magyar cikkek
  • Technikailag elmaradott az oldal
  • Az oldal adminja nem hajlandó sem fejleszteni, sem segítséget elfogadni (már nem is foglalkozik vele).
  • Közösséget elpárolgott a rossz hangulat miatt és a tartalom hiánya miatt.

Régen minden reggel megvettem az egyik napilapot (és olvastam is). Aztán tulajdonosváltás után jelentősen megváltozott a stílusa. Azóta nem veszem meg (és nem olvasom) az adott újságot. Kerestem helyette más hírforrást. Ennyi.

Van néhány dolog, ami nem tetszik az HUP-on, de el tudom viselni őket. Ha majd ezt gondolom, hogy ez így már fos, akkor nem fogom olvasni a HUP-ot. Másként: Ha nem szereted a sz@r ízét, akkor nem rágd, hanem köpd ki. Ennyi.

Egyetértek. Nálam nincs tiltva a Twitter, csak nagyon utálom #idiotahashtag #utalommintaszart #nemvagyoktrendi #faxomsemlatatennyihastaget #olvashatatlantolukminden. A Facebookot is utálom, de a Twitter még annál is irritálóbb, szerencse, hogy inkább csak a jenkiknél menőbb.

„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

A csúnya igazság a cert.org-tól:

> Solution
> Replace CPU hardware
> The underlying vulnerability is primarily caused by CPU architecture design choices. Fully removing the vulnerability requires replacing vulnerable CPU hardware.

A felfokozott izgalom közepette azért én úgy vagyok vele, hogy megvárnám, hogy a patchelt rendszereim mennyire lesznek lassabbak, mielőtt kibaszom őket az ablakon. De dráma van, úgyhogy egyelőre hátradőlve figyelem a műsort.

Esetleg opcionálisan: felmondok és elmegyek lomizni, begyűjtöm a kibaszott gépeket -> profit

Kéne még popcorn ;)

--
trey @ gépház

A ritkafoldfemek egyaltalan nem ritkak. Nagyon sok helyen megtalalhatoak de kicsi anyagsuruseg mellett, azaz elszortan talalhatoak meg. Koncentraltan ritkak. Kinaban oriasi fold es kozetmennyiseget dolgoznak fel a ritkafoldfemek kitermelesekor. Ezzel jelentosen karositjak a termeszetet.

Az Azure január 10.-re tervezett egy reboot-ot az ott lévő gépünkre. Ma hajnalban jött egy levél, hogy előrehozzák az Intel bug miatt a tervezett reboot-ot. Reggel 7:30-kor a szerverünk újra bootolt és megkértek, hogy a legújabb kernelt installjam fel és biztos, ami biztos alapon, rebootoljam a VM-emet.

A 7/24-et te hoztad ide be, egyelőre ott tartunk, hogy volt egy, a szolgáltató által megadott karbantartási idősáv, amit utána elég buta módon módosítottak. Persze lehet lobogtatni a "ÁSZF-ban benne van"-t, nekem meg jogom van ezt a szolgáltatás rákfenéjének nevezni (helyette konkurens, rugalmasabb szolgáltatást nyújtani).

--
trey @ gépház

Oké, te mit tennél ugyanebben az esetben?

Tehát van egy ÁSZF-ed, benne van, hogy security esetben bármikor lehet restart; 99,9% SLA-t vállalsz, bőven benne vagy a vállaltakban; van egy meghirdetett restart időpontod és kiderül egy súlyos security hiba, ami miatt minden gépet újra kell indíts? Lenyomnád az összes ügyfél gépén, kivéve azokon, amelyeken volt meghirdetett restart egyéb okokból?

Normálisan kialakított virtualizált környezetben a hostokat lehet a virtuális gépek leállítása nélkül frissíteni (ügyfelet nem ériti). Nyilván tudod, hogy a virtuális gépeket lehet menet közben mozgatni. A virtuális gépet meg mindenki maga patcheli, amikor ő akarja. Nem rúgjuk ki alóla a saját szerverét, mert frissítünk.

--
trey @ gépház

A válasz az, hogy biztosan nem rúgnám ki az ügyfelek alól a rendszert néhány órán belül, ha előtte kiküldtem a levelet arról, hogy 10 nap múlva készüljenek erre.

Ha pedig megtettem mégis, akkor valakit kirúgnék, utána pedig sűrű elnézéskéréseket eszközölnék az ügyfél felé és biztosan nem a ÁSZF-t lobogtatnám arrogánsan.

De ez nem technikai kérdés, nem is üzemeltetői kompetencia.

--
trey @ gépház

A kulcsmondatrész a néhány órán belül. Össze-vissza kapkodásnak tűnik. A biztonsági szakértők (és így nyilvánvalóan a bűnözők) is hetek óta tisztában voltak azzal, hogy milyen javítások készülnek (ott voltak a Linux kernelben a patchek, ott voltak @aionescu tweet-jei), azok milyen jellegű hibát fognak javítani.

A sebezhetőség kiszivárgása mellett működő publikus exploit nem volt, szóval ez a nagy rohanás nem tűnik túl átgondoltnak.

És visszakanyarodva az elejére, továbbra is állítom, ez a publikus cloud rákfenéje. Egyrészt, hogy a publikus mivolta miatt "kellett" kapkodni a javítással, másrészt a szolgáltató önkényesen kirúgja alólad amikor akarja.

De, szerencsére a szolgáltató védve van, mert le van írva!

--
trey @ gépház

Szerinted miért veszélyesebb egy publikus cloud-ban a VM-ből való kitörés, a host memóriájának olvasása lehetőség, mint egy olyan privát cloud-ban, amiben csak a saját gépeid vannak és te kezeled az egészet?

Egyébként meg teljesen mindegy, semmi sem indokolta a gépek kirúgását az ügyfél alól sebtében:

https://support.microsoft.com/en-us/help/4073235/cloud-protections-spec…

"Impact to enterprise cloud services

Microsoft is not aware of any attacks on Microsoft cloud customers that leverage these vulnerabilities. Microsoft employs a variety of detection capabilities to quickly respond to any malicious activity in our enterprise cloud services. "

Vagy hazudnak.

--
trey @ gépház

Nyilván saját rendszer esetén sokkal kisebb a kockázat, de kellő motivációval (= ha van mit ellopni) belsős ember is próbálkozhat olyanhoz hozzáférni egy nem javított sebezhetőségen át, amihez egyébként nem fér hozzá. A nagy szerencse az, hogy a legtöbb ilyen hiba esetén nem triviális a kihasználása és nincs olyan értékes adat, amit el lehetne lopni, így nem éri meg a ráfordítást...

Ennek fényében és a fent idézett Microsoft kinyilatkoztatás fényében (nincs tudomásuk jelenleg aktív támadásról sem) még érthetetlenebb számomra az a nagy sietség, aminek folyományaként arra ébredt reggel történetünk szereplője, hogy újrabootolták alatta a virtualizációs hostokat.

--
trey @ gépház

"Szerinted miért veszélyesebb egy publikus cloud-ban a VM-ből való kitörés"

Szerintem nem veszélyesebb. Egy saját környezetben is biztonsági határnak van tervezve a virtuális gép, ezért nincs elemezve előzetesen annak a hatása, hogy ezt megsérthetik. Így annak a lehetősége, hogy átmászkál valaki a gépek közt vagy átveszi az irányítást a host fölött, számomra kritikus fenyegetettség.

Persze az egyes saját környezetek üzemeltetői különféle vérmérsékletűek, van, aki ezt nem veszi annyira kritikusnak.
Egy nyilvános felhő szolgáltatást nyújtó cégnek persze a leginkább biztonság-érzékeny ügyfelekre is figyelemmel kell lennie és ennek megfelelően védeni a rendszert.

A Microsoft esetében nyilván nem volt lényegtelen elem, hogy anyagi felelősséget vállal az SLA-ért, így egy komolyabb szolgáltatáskiesés sokba kerül neki.

Üdv,
Marci

"Így annak a lehetősége, hogy átmászkál valaki a gépek közt vagy átveszi az irányítást a host fölött, számomra kritikus fenyegetettség."

A nagy különbség az, hogy public cloud esetén ugye bárki átmászkálhat, míg private cloud esetén pedig általában csak én magam mászkálhatnék át magamhoz.

Kevesan vannak a Hozzád hasonlók, akik egyszemélyes privát felhőt üzemeltetnek.

A többfelhasználós privát felhőknél viszont, az én értékelésemben, a raktári rendszerből a HR rendszerbe való átmászkálás lehetősége vagy a host fölötti kontroll elvesztésének esélye _ugyanúgy_ kritikus besorolású mint ha nyilvános felhőben más cég rendszeréből mászkálhatnak át az általam üzemeltetettbe. Nem vagyunk egyformák.

"bárki átmászkálhat" -- ez így félrevezető. Csak az a bárki mászkálhat át, aki épp azonos hoston lakik a szolgáltatásommal. Nem ugyanaz.

Üdv,
Marci

Az otthoni szobaajtók nem képeznek tervezési biztonsági határt, rossz a hasonlatod.

Amúgy sok helyen jártam már, ahol volt a bejárati ajtónál erősebb biztonsági besorolású belső ajtó. Számítógépterem, értéktár, pénztár... a bejárati ajtó meg sima edzett üveg. Rossz a hasonlatod.

De nincs azzal semmi bajom, ha Neked nem kritikus fenyegetettségű a virtuális gépből való kitörés lehetősége.

Üdv,
Marci

Mert nálam egy biztonsági határon való hitelesítés és naplózás nélküli, usermode-ból indítható átmászkálás kritikusnak minősül. Ugyanúgy kritikusnak sorolnám be, ha a HR rendszer felhasználói hozzáférnének egymás bérjegyzékéhez, az arra való jogosítás nélkül (akármilyen környezetben, akármilyen hiba miatt).

Üdv,
Marci

Az a baj, hogy ezt teljesen általában teszel egy kinyilatkoztatást, miközben egy ritka speciális esetre gondolsz.

Minden esetben kritikus, ha a szomszéd cég bármelyik alkalmazottja képes arra, hogy mindenféle biztonsági korlátot áttörve átmászkáljon az irodámba (public cloud).

A cégek nagy részénél viszont nem kritikus, hogy ha egy fejlesztő át tud menni a HR osztályra kávézni anélkül, hogy azonosítaná magát (private cloud), mert egyébként sincs is biztonsági korlát. Ha lebukik, hogy közben a személyi kartonokat lapozgatja, akkor lebukik. Akkor lesz kritikus, ha a kockázat és a károkozás együtt olyan mértékű.

Hagyjuk a nagy szavakat. Nem kinyilatkoztattam, megosztottam a véleményemet.

Tipikusan nincs gond abból, ha a fejlesztő átmegy kávézni a HR-re, ezért ott nincs biztonsági határ.
Ha a személyi kartonokat tudja lapozgatni, akkor gond van a fizikai biztonsággal. Ugyanis az azokhoz való hozzáférés tipikusan biztonsági határral védett.

"Akkor lesz kritikus, ha a kockázat és a károkozás együtt olyan mértékű." Ne keverd a fenyegetettséget a kitettséggel, én végig fenyegetettségről beszéltem. A kitettség több faktorból áll össze. És egy kockázatelemzés végén lehet kisebb a kitettsége annak, hogy a nyilvános felhőben a szomszéd beleturkál a statikus, nyilvános weblapomat futtató VM-be, mint annak, ha a Kollégák hozzáférhetnek egymás bérjegyzékéhez.

Üdv,
Marci

Csak nem mindegy, hogy saját üzemeltetésű környezetben a kollégáimban és a személyesen ismert ügyfélkörömben kell megbíznom, míg egy publikus cloud esetén jön egy idegen, megad egy-két fake adatot, akár egy lopott, de nem letiltott hitelkártyaszámot (már ahol kell) és máris azonnal kap egy virtuális gépet.

--
trey @ gépház

...és kb. olyan eséllyel tud betörni egy adott ügyfél VM-ébe (egy VM kitöréses exploittal), mintha Budapesten találomra választana egy utca-házszám kombinációt az összes közül és pont a Fehérvári út 85/c lenne az.

Ráadásul nem elég Neked "megbízni" a felsoroltakban, hanem nekik is kell egymásban. Márpedig ha valaki ki tud használni egy VM-kitöréses sebezhetőséget, hogy bűncselekményt kövessen el vele (pl. ipari kémkedés a versenytárs ellen), bizony nagyobb eséllyel kerül egy hostra a SzintCloudban (Cloudiával mi lett?) mint egy Azure régión belül...
A másik oldalon viszont, ha egy rosszfiú egy találomra választott cég valamilyen fontos VM-jén landol, vajon hogyan tudja reálisan monetizálni, amihez hozzáfér?

Üdv,
Marci

Olyanról még nem hallottál, hogy célzott támadás mellett van amikor random sikerül benyomulni egy értékes helyre? Ilyenkor kimegy a feketekalap a piacra és megkérdezi mit adnak azért a szajréért. Ha valakinek meg célzottan pont Az kell még szerencséje is van.

Normális HUP-ot használok!

"...és kb. olyan eséllyel tud betörni egy adott ügyfél VM-ébe (egy VM kitöréses exploittal), mintha Budapesten találomra választana egy utca-házszám kombinációt az összes közül és pont a Fehérvári út 85/c lenne az."

Persze, mert szerinted csak célzott támadások vannak (nem).

"Ráadásul nem elég Neked "megbízni" a felsoroltakban, hanem nekik is kell egymásban. Márpedig ha valaki ki tud használni egy VM-kitöréses sebezhetőséget, hogy bűncselekményt kövessen el vele (pl. ipari kémkedés a versenytárs ellen), bizony nagyobb eséllyel kerül egy hostra a SzintCloudban"

Nem tudom honnan veszed ezt :) Egyébként a privát cloud-ban minden ügyfél ismert, minden ügyfél olyan "távolságban" van, hogy azt a magyar törvény keze azonnal eléri. Jött-mentek nem kapnak szolgáltatást csak úgy. Lásd. a fenti eset, amit felvázoltam a hamis adatokkal. Én úgy kaptam anno virt. gépet a HP public cloud-ján, hogy kattintottam 10-et.

Mielőtt kiforgatod, én nem állítottam, hogy a privát cloud sebezhetetlen. Szerintem a cloud az "más gépe". Ebben minden benne van. Azt állítottam, hogy szerintem (a szorosabb kontroll okán) biztonságosabb a public-nál.

"Cloudiával mi lett?"

Életemben nem hallottam róla. Mi az?

"mint egy Azure régión belül"

Szívesen látnék már egy nem marketing bullshit rajzot arról, hogy hogyan is épül fel az Azure virtuális host része. Sajnos nem nagyon találtam. Olyan szinten, hogy op. rendszer verzió stb.

Az egész egy nagy "bűvész fekete cilinderjánek" tűnik, amiben azt kutyulnak amit akarnak.

"A másik oldalon viszont, ha egy rosszfiú egy találomra választott cég valamilyen fontos VM-jén landol, vajon hogyan tudja reálisan monetizálni, amihez hozzáfér?"

Oh, jaj. Azt hiszed, hogy csak célzott támadások léteznek? Goto eleje.

--
trey @ gépház

"Nem, szerintem nem csak célzott támadások vannak."

Tehát elfogadod, hogy van olyan támadás, amit publikus cloud-on, ami nem célzott?

"Cloudia: http://www.szintezis.hu/hirek//felho-szolgaltatas-a-szintezistol.html"

Sajnos nem vagyok képben a cégcsoport minden egyes termékének (több száz is lehet) összes marketingnevével, de egyben biztos vagyok majdnem 100%-ban: a cégcsoportnak nincs publikus cloud-ja.

--
trey @ gépház

Hadd próbáljam összefoglalni, hogy hol tartunk, mert kezdem elhagyni a fonalat...
Tehát: azt kéne belátnom, hogy a privát felhő azért biztonságosabb a nyilvánosnál, mert kevésbé fordulnak elő benne a hozzáférést a normál provizionáláson keresztül, de csalárd módon megszerző rosszfiúk, akik nem célzott támadásokat készülnek elkövetni találomra más ügyfelek VM-jei ellen a saját VM-jükből egy VM-ből kitörést lehetővé tévő, foltozatlan sebezhetőség kihasználásával?

És onnan jutottunk ide, hogy azt állítottam, hogy az én személyes értékelésem szerint, ha egy tervezett biztonsági határról (2 tetszőlegesen választott VM közt tipikusan az szokott lenni) kiderül, hogy audit és feljogosítás nélkül átléphető, az egyaránt _kritikus_ szintű _fenyegetés_ privát, nyilvános és szolgáltatói felhőben -- sőt egy adott alkalmazáson belül is (bérjegyzékes példa). Természetesen a kitettség meghatározásához kell az is, hogy milyen értékű a fenyegetett dolog.

Üdv,
Marci

Talán túlzottan is leegyszerűsítették, annyira, hogy nem is arról szól, amiről én beszéltem.
"én magam mászkálhatnék át magamhoz."
Egyfelhasználós privát felhővel nem túl gyakran találkozom. Továbbá példaként sem jó, hiszen az egyfelhasználós privát felhő speciális esetében éppen nincs is biztonsági határ a VM-ek közt, hisz (gyaníthatóan) minden VM-nek megegyezik a hozzáférési jogosultságok mintája...

De nyugtass meg: jól sikerült összefoglalnom, hogy Szerinted miért biztonságosabb a privát felhő?

Üdv,
Marci

"Egyfelhasználós privát felhővel nem túl gyakran találkozom."

Pedig van.

"Továbbá példaként sem jó, hiszen az egyfelhasználós privát felhő speciális esetében éppen nincs is biztonsági határ a VM-ek közt, hisz (gyaníthatóan) minden VM-nek megegyezik a hozzáférési jogosultságok mintája..."

Pedig jó példának, mert jól mutatja, hogy mire akartam rámutatni. Csak te nem érted vagy nem akarod érteni, hogy mit akartunk mondani.

Szerintem fejezzük itt be. Te nem fogsz meggyőzni engem arról, hogy ha nincs különbség a privát és a publikus felhő közt ebben a kérdésben, akkor a Microsoft-nak miért kellett sebtében, a kihirdetett dátumot jóval előbbre hozva rebootolna a hostjait. Előbb, mint hogy a belső hálóhatokra szánt operációs rendszereit frissítette volna.

--
trey @ gépház

A bejelentett karbantartás alatt nem ketyeg az SLA, itt meg igen. Vállalták a biztonság miatt, szerintem így se jön össze a 45 perc a hónapban, de ha igen, majd adják a Service Credit-et.

Azt, hogy a hegyével asztallapra állított ceruza előbb-utóbb eldől, Te nevezheted akár az ilyen összeállítás rákfenéjének --
szerintem egyszerűen "tulajdonsága". Esetleg mások nehezebben értik meg, mire is gondoltál. :D

Üdv,
Marci

ez egy elég durva bug. Azon se csodálkoztam volna ha az egészet azonnal lekapcsolják.
Az összes kínai kibergeci már ezt programozza sztem. Kell egy csali app meg egy exploit progi és mindent el lehet most lopni.
Sztem most mindent be fognak támadni, teslát, iss-t, nasat, pentagont mindent.
Szem nem marad szárazon.

--
GPLv3-as hozzászólás.

Látom, rád is a szándékolt mértékben hatott a köré kavart hisztériakampány.

Azt áruld el nekem, ha valaki egy r=1 felhasználó gépén sikeresen elindít egy exploitot, akkor mi akadályozza meg abban, hogy felhasználói jogosultságokkal hozzáférjen a Chrome, Firefox, illetve a Windows-ban tárolt egyéb jelszavakhoz, mindenféle CPU mágia nélkül?

Ha valakik veszélyben vannak, azok a cloud szolgáltatók. Őket szokták is támadgatni. Viszont megint csak ott tartunk, hogy kell egy normál user account, amiről az említett sebezhetőségek local root exploitként indíthatóak.

Az egész egy túlméretezett hisztéria, amivel az átlagfelhasználót próbálják a leginkább riogatni, hogy megágyazzanak a soron következő CPU famíliáknak. Ha mindenkinek ott a félelem faktor tudat alatt, nagyobb hajlandósággal veszik meg az új gépet akár jajcsaknehogyfeltörjenek alapon.

Mondjuk úgy, hogy javascriptből használják ki: https://www.react-etc.net/entry/exploiting-speculative-execution-meltdo…

+ számos vírusírtó futtatja automatikusan, korlátozott privilégiumokkal a letöltött vagy levélben kapott fájlokat, hogy vírusra utaló viselkedéseket vizsgáljon.

Important information regarding the Windows security updates released on January 3, 2018 and anti-virus software

Customers will not receive these security updates and will not be protected from security vulnerabilities unless their anti-virus software vendor sets the following registry key:
Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD”

Why are some anti-virus solutions incompatible with the January 3, 2018 security updates?
During our testing process, we uncovered that some third-party applications have been making unsupported calls into Windows kernel memory that cause stop errors (also known as bluescreen errors) to occur.

10 éve sok minden lehetetlennek tűnt, ami ma már valóság. Lehet, hogy felül kéne vizsgálnia az állítását, de egyelőre csak nagy hallgatást látok a misc@ és tech@ listákon is.

Ha nem lehet ezeket a konkrét hibákat javítani szerinte, az is egy válasz. De valami hivatalos csak kéne, ha már az ő felhasználói firtatják.

Ilyen Nostradamus-i jóslatokat egyébként nem nehéz tenni. Az lett volna a nagy szám, ha egy olyan doksit tesz le az asztalra, mint amilyet a Google Project Zero tett.

--
trey @ gépház

ezek alapján drágulni fog a bitcoin ("hivatalosan" nincs nekem)... mert ügye 5-30%-al lassabb lesz a bányászása :-D

Azt hiszem, sok processzor elkapta ezt a „kórt”.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Újabb ékköve annak, hogy a hardver- és szoftvergyártó megapolipok kartellje hogyan igyekszik rávenni az elmúlt években telítődő PC-piacot a felesleges, új™ eszközök és szükségtelen innovációk™ megvásárlására, avagy a túltermelést elősegítendő túlfogyasztásra.

A felállított csapda nagyon egyszerű. Ha nem akarod, hogy veszélyben™ légy, frissíts! Ezután nem leszel veszélyben, de le fog lassulni a rendszered. Ha nem akarod, hogy lelassuljon a rendszered, majd veszel újat™, mert sokkal jobb venni egy újat™, mint veszélyben™ lenni.

Harsog a média a félelemkeltéstől, ahogy az ilyenkor lenni szokott, a lakájok 30% lassulást, jelszólopást, soha nem látott méretű vírustámadásokat, katasztrófákat, kiberháborúkat vizionálnak, csakhogy a veddmegdobdki beidegződésen való hiénáskodásra berendezkedett ipar mögött álló nagytőke és pénztőke befektetése megtérülhessék. Ha pedig valaki hülye a történetben, az biztos csakis hájbazer, mert a sikeres™ nagyvállalatok tévedhetetlenek.

Kérdem én, ha amúgyis feltörték a géped, nem mindegy, hogy milyen módon lopják el a böngészőben tárolt jelszavaid, vagy a merevlemez-titkosítási kulcsod? Nem érdemled meg a hacket, ha egységsugarúként viselkedtél és a hivatalosan támogatott™, frissített™ = biztonságos™ operációs rendszertől vártad el, hogy megvédjen? Komolyan ott tartunk megint, hogy a processzor és az operációs rendszer kötelességének tartjuk a biztonsági vagy a biztonságot támogató funkciók megvalósítását? Hol húzódik a szélsőséges idealizmus, a minden mindenre jó, illetve a marketing bullshit határa?

Amiről pedig a mainstream mérnök urak internacionáléja szokás szerint kussol:

  • Hol érik ilyenkor egy class action lehetősége az egyértelműen hardveres hiba (gyártási, tervezési hiba), illetve a 30%-os teljesítményvesztés kapcsán? Hol vannak a fogyasztóvédelmi hivatalok, melyek megszerveznének egy class action pert, vagy számonkérhetővé, büntethetővé tennék az ilyen nemtörődöm viselkedést (gyártást) a processzorgyártók részéről?
  • Miért nem hívja vissza az Intel az általa hibásnak ítélt processzorokat, ha már meggazdagodni volt képük belőle? Miért nem fizet kártérítést?
  • Ki fogja megtéríteni azt az anyagi és környezeti kárt, ami a #meltdown sebezhetőség kapcsán szeméttelepre kerülő, 100%-ig működőképes hardverek okoznak szerte a világon?
  • Miért ül egy évig a Google jeleskedő™ biztonsági csapata ezen a problémán és miért várja meg a bejelentéssel, amíg a véletlenül már nem sebezhető Skylake és Kaby Lake szériák kijönnek? Tán nem azért, hogy kész megoldásként lehessen említeni az újabb™, gyorsabb™, már bejáratott, az early adopterek által is elfogadott, még 30%-kal sem sebességcsökkent processzorok megvásárlását?
  • "Az Intel azt ígéri, aki nem pörgeti csúcsra a gépét, az kevésbé érzi majd a lassulást, melynek mértéke idővel csökkenni fog – de ezzel a jóslattal jelenleg nem minden szakértő ért egyet." - HVG 2018. január. 04. 08:03
    Ha volt egy éve a szakmának sunyiban dolgozni a problémán, miért nem azzal töltötték, hogy kioptimalizálják a javítást? Miért most ígérgetnek?

Mellékesen megjegyzem, hogy rendkívül undorítónak és tenyérbemászónak tartom, hogy az informatikai biztonság mára a nagyvállalatok profitját biztosító, cinkos talpnyaló szakma lett, melyet a médiában ügyeletes riogatók és hivatásos rettegők képviselnek.

Én, hájbazer, itt és most kijelentem, hogy semmilyen szín alatt nem fogom frissíteni a rendszeremet a 30%-os lassulásért cserébe. Amennyiben a számítógépemre önkényesen frissítést telepítenek, azt le fogom szedni róla. Bár Windows XP-n erre nem látok nagy esélyt. Nocsak, újabb előny a nem frissített rendszerek javára.

Hát hajbinak egyben igaza van. Ezután lehet az új procikat spectre és meltdown secure-nak reklámozni, és ahol ez számít, ott e miatt meg is fogják venni, de tartok tőle, hogy ez inkább az egész hw szakma óriási fiaskója lesz inkább, az öregek nyelvcsettintve hümmöghetnek, hogy ez az 'ámítógép csak úri huncutság beza, nem lehet komolyan venni..., de annak ellenére, hogy a szakma jól lábonlőtte magát, és foltozunk, legalább ennek a szükségessége talán most már napról napra egyértelműbb, és talán jobban igyekszünk, hogy eljöjjön eza nap: https://media.ccc.de/v/34c3-9105-coming_soon_machine-checked_mathematic…

> Újabb ékköve annak, hogy a hardver- és szoftvergyártó megapolipok kartellje hogyan igyekszik rávenni az elmúlt években telítődő PC-piacot a felesleges, új™ eszközök és szükségtelen innovációk™ megvásárlására, avagy a túltermelést elősegítendő túlfogyasztásra.

Tegnap nekem is volt egy hasonló gondolatom, bár én csak konteónak szántam, nem tudom mennyire állja meg a helyét...

Én nem hiszek az 5-10 évre előre megtervezett összeesküvésekben, ezek általában ki szoktak derülni, mert minden cégnél dolgozik néhány lelkiismeretes ember a vadkapitalista pénzhajhászást kiszolgáló, a tervezett elavulást éltető, megélhetési mérnök urak mellett, akinek előbb-utóbb eljár a szája.

Az már sokkal jobb kérdés, miért vártak ennyit a bejelentéssel. Tán nem azért, hogy out-of-the-box megoldásként lehessen felkínálni a piacra azóta már bejáratott Skylake és Kaby Lake termékcsaládot? Tán nem azért, hogy először elkapkodják a legújabb Galaxy Note 8-akat, iPhone-okat, aztán a biztonságra hivatkozva belassíthassák és kidobathassák? Kartellszerződések biztos, hogy vannak mögötte. Pláne, hogy egyik cég se pereli a másikat a csapnivaló processzorok miatt. Nyilván az új eszközök megvásároltatása birkáékkal több hasznot hoz majd, mint a procis mizéria okozta költségek.

Viszont a titkolózás és az out-of-the-box megoldás kivárása a felhasználók érdeke is, nem?

Épkézláb megoldásnak neveznék egy nem 30%-os lassulást eredményező fixet, amit érdekes módon csak a két új szériára sikerült kihozni (Skylake és Kaby Lake). Épkézláb megoldásnak neveznék egy teljes processzorvisszahívást, amit az Intel meg is érdemelne. A titkolózásról pedig annyit, hogy más a titkolózás, más a figyelemfelhívás és más a hisztériakeltés. Most hisztériakeltés megy. Ami minden komolyabb (local root exploit) Linux kernel bugnál mehetne, de nem megy, mert végül is csak a kétharmad Internetet ellátó infrastruktúra kerül veszélybe. Ja bocs, azt nem úgy "védik", hogy frissen tartják a rendszert, hanem valódi biztonsági intézkedésekre is futja, nem beszélve arról, hogy a nagyvállalatok a garanciaidő lejárta után kötelezően vásárolnak új hardvereket, tehát az utánpótlás biztosított. Azért megy hisztériakeltés, hogy birkáék tudatában ott legyen két buzzword: 30%, lassulás. Meg, hogy az új processzorfamíliiák nem érintettek. Egyszóval, minden esetben, amikor a gép mostantól lassulgat, eszükbe jut, hogy egy gyári hibás processzoron dolgoznak. Míg végül kidobják és vesznek újat helyette (jóval nagyobb lelkesedéssel, mintha nem lenne gyári hibás). Normális, fair keretek között ilyenkor az Intelnek kutya kötelessége lenne visszahívni minden processzort és kicserélni. Ők baszták el. Vállalják a felelősséget.

Egyrészt nem csak Intel procik érintettek, az elmúlt években a többi gyártó is benne volt a versenyben és szinte mindegyik implementálta az out-of-order execution fícsört. A Skylake és Kaby Lake miért nem érintett? Erről én nem olvastam még...

Ez a 30% lassuláson rugózás szerintem is gáz, ennél sokkal nagyobb a probléma és ez a szoftveres wourkaround csak az első hotfix a jelenleg ismert variánsok ellehetetlenítésére. Remélem napokon belül lesz jobb ötlete is valakinek.

Amúgy a proci nem gyári hibás, ez eredetileg tényleg feature, ami többet hozott sebességben mint amit most - remélhetőleg átmenetileg - elveszítünk.

Hát én is valami hasonlóra saccoltam, hogy így akarják eladni a szükségtelen teljesítménynövekedést, csak nem tudom, hogy mennyire állja meg a helyét. Tekintve a mai IT világban uralkodó böszme inkompetenciát, még az is lehet, hogy tényleg csak kollektíven elkúrták az egészet... :/

Sokkal inkább az lehet szerintem, hogy az elcseszésben semmi gonosz profithajhász szándék nem volt azt leszámítva, hogy a hardvervásárlók zsírján hízó befektetők ott áltak a tervezőmérnökök fölött, mint pszichológiai nyomás, hogy minél előbb, minél eladhatóbbra készen legyen a processzor. Mivel a minőség csak az eladhatóság árnyékában számít bármit is, így ezek a mérnökök eleget is tettek a feladatnak. Az már csak a felhasználók problémája, ha emiatt feltörik, belassítják őket, esetleg kidobatják a gépüket.

"It was reported that implementation of KPTI may lead to a reduction in CPU performance, with some reports claiming up to 30% losses in performance depending on usage, though some considered this to be an exaggeration. However, it was reported that Skylake and newer Intel processor generations were not as susceptible to performance losses under KPTI as older generations." - Meltdown (security vulnerability)

Gyakorlatilag nem, mert nem fog belassulni a javítástól és emiatt veszteség nem éri a felhasználót, meg nem kell helyette újat venni.

Új alaplap = FOGYASSZ! = FIZESS!
Új processzor = FOGYASSZ! = FIZESS!
Új memória = FOGYASSZ! = FIZESS!
Új videókártya = FOGYASSZ! = FIZESS!
Új operációs rendszer = FOGYASSZ! = FIZESS!

És a veddmegdobdki kör bezárul.

Mindezt persze úgy, hogy egyik oldalról tol bele a szakadékba a médiariadalom, másik oldalon meg szép új™, menő™, modern™ köntösben ott vár az új gép az üzletben. A kínai rabszolgák pedig nem győzik alaplappal, tápegységgel, videókártyával, gyerekmunkával, környezetszennyezéssel, légszennyezéssel.

Majd 6-7 év múlva a Microsoft és az Intel dobják a most megvett új gép támogatását. Akkor kezdődik előlről.

> Older CPU's without PCID will be impacted more by the isolation.
https://lkml.org/lkml/2018/1/2/703

ugyanebből a threadből, ha nem nézem be, egy olyan CPU-n amit „nem érint” a hiba szerinted ~6%-os lassulást mért a kedves levélíró.

de persze, a tények figyelmen kívül hagyásával lehet bátran osztani az észt.

Nem vagyok biztos benne, de szerintem itt a PCID-re gondolnak. Ha elérhető a PCID, akkor a használata ugyan csökkenti a teljesítmény esés mértékét, de csak részben. Meg a PCID-re támaszkodó kód implementációjának hatékonyságától is függ.
Pl:
https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@a…
i7-6820HQ CPU (skylake):
- readonly pgbench (tpch-like), 16 clients
pti=off: tps = 236629.778328
pti=on: tps = 220791.228297 (~0.93x)
pti=on, nopcid: tps = 198959.801459 (~0.84x)
- pgbench SELECT 1, 16 clients
pti=off: tps = 420490.162391
pti=on: tps = 350746.065039 (~0.83x)
pti=on, nopcid: tps = 324269.903152 (~0.77x)

Szóval a 16%-os lassulást 7%-ra, a 23%-osat 17%-osra csökkenti.

A PCID a Westmere óta velünk van, nem kell hozzá Skylake, meg Kaby Lake.

Továbbá a pdf cikk alapján a meltdown sokkal hatékonyabb TSX-szel. A Broadwell-nél már jött a TSX, de több errata kapcsán azokban a Broadwell processzorokban, amik támogatták, kénytelen volt az Intel microcode-ból letiltani. Talán csak néhány 4-utas, high-end Xeon-ban hagyták meg - nem néztem után pontosan, de így rémlik.
Előtte és utána is volt még probléma a TSX-szel.
Azóta viszont már benne van az új processzorokban és a meltdown hatékonyságát elég jól növelni tudja a TSX jelenléte.

Habár, ha az OS szintű workaround tényleg sikeresen akadályozza majd a meltdown-t, akkor még mindig ott a spectre, amire egyelőre nincs javítás a láthatáron.

Ha a most kijövő exploit csomag egyes részei még a System Z, meg a Power architectura-t is érintik, akkor marad még a Sparc, PA-RISC, S390, MIPS/R*? Vajon az Alpha, az m68k ebben a tekintetben rendben van? Vagy egy VAX? Irígylem, akinek van a padláson!

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Valaki írhatna konkrétumokat Linux kapcsán. Hányas kernelverzióban foltozták, van-e valami teszt, akár csak egy script, ami kimutatja, hogy érintett vagyok-e.

Plusz ezt nem gondolják komolyan, hogy ki fogok dobni teljesen jó procikat csak egy security bug kedvéért. Nem igaz, hogy nem lehet elfogadható sebességveszteség mellett szoftveresen foltozni. Szoftveres megoldáson nem vírusirtót értek, nem azért linuxozok, hogy fusson a háttérben egy plusz antivírus is.

Tényleg nem akarok hajbazernek tűnni, és nyomni a ne dobjuk ki, meg bloatnövekedésellenesmocskoskapitalsta dumát, de akkor tényleg be is fosok, ha emiatt kell gépeket cserélnem. Ráadásul ahogy látom, még az ARM is érintett, tehát a telefonokat is ki kéne dobni.

„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

Nocsak, Mérnök Úr. Tán nem fáj a 30%? Mikor engem múltkor még arról győzködtél, hogy megéri 15-20 másodpercet várni egy LibreOffice betöltésre, meg a lagzó, lassulgatós felületét használni? Igazam van vagy igazam van, hogy csak akkor kezdel valós problémának érezni egy, hardver- és szoftvermultiéknak köszönhető teljesítményvesztést, amikor esélyes, hogy már a saját bőrödön is érzed?

Attól még nem tűnsz hájbazernek, ha elkezdesz józanul gondolkodni. Onnantól leszel az, hogy megkérdőjelezed a fejlődés az erőltetett növekedés, a túltermelés, illetve a vállalatok extraprofitjának létjogosultságát. Ezt pedig nem tetted.

Tekintettel arra, hogy full kényelmesen elvagy a bloated framework-ökben fejlesztett grafikus Linuxodon is, szerintem meg se fogod érezni azt a 30%-ot. Egy apt-get dist-upgrade után is lassulsz ennyit.

Nem arról győzködtelek. A Linux grafikus felülete nem lassulgat, meg nem lagzik, ilyen max. 10%-os prociterhelés, amit kifogásoltál múltkor, az nem az a kategória (sőt, utóbb rájöttem, hogy azért olyan „magas”, mert a modern procik idle-ben leveszik az órajelet 1 GHz környékére, vagy az alá az energiatakarékosság miatt, és lassabb procinál így az adott terhelés több %-nak látszik), ráadásul csak akkor jön elő, ha vadul scrollozol megállás nélkül, meg intenzíven rángatod az ablakot, ami nem rendeltetésszerű felhasználás, hanem egy extrém körülmény, normál használatnál jelképes a terhelés. Sőt, igazából hardveres videógyorsításnál még lehet is gyorsabb egy modern grafikus felület, mint a kedvenc XP-t elavult szoftveres GDI-s megoldása. Arról nem is szólva, hogy reszponzívabb is, mivel a Linux kernel jobban gazdálkodik az erőforrásokkal, mint az XP elavult, régi architektúrás kernele.

Azt továbbra sem tudom miért mérnök urazol, írtam már, hogy se mérnök, se informatikus nem vagyok.

Abban meg mindig is különbözni fogunk, hogy én mindig támogatott és patyolatfriss rendszert használok még régebbi, gyengébb gépeken is, meg tartom a lépést a technológiákkal, és nem ragadok be elavult rendszerbe, meg nem vagyok a fejlődés ellen.

Itt viszont azért adtam hangot a felháborodásomnak, mert itt ennél a bugnál egész méregdrága, új, bivalyerős procikat és eszközöket is ki kéne dobni, ami ráadásul nem csak plusz anyagi kiadás, de ha hirtelen mindenki most akar majd emiatt új procit, eszközöket venni, akkor nem csak nagy áremelkedéshez, hanem masszív hiányhoz is vezethet, ami meg káoszhoz. Ez a kérdés messze túlmegy a szokásos XP-s, P3-as mondókádon. Vagy ha kidobni nem is kell, de az a 30% teljesítményveszteség, amit belengetnek, az nagyon durva átlag felhasználói szinten is.

Ami még külön gáz, hogy most linuxon a kernel stabil ágában, azaz a 4.14-ben nem tudni mikor lesz folt rá, mert a 4.15 véglegesben majd csak hosszú hetek múlva fog kijönni, így vagy mindenki felteszi az RC-ket, vagy védtelen marad hosszabb ideig. Mindegy, mindjárt AUR scripttel mászik fel Arch alatt a gites 4.15 RC6 kernel, pedig nem szeretem az AUR-t.

„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

A Windows XP GDI-je sokkal gyorsabb egy régi hardveren, mint a Linux hardvergyorsított™ felülete. Elhiszem, hogy nálad nem így van, cserébe hidd el, hogy nálam így van. Attól még, hogy a grafikus driveren és a hardvergyorsításodon lovagolsz, nem fog hamarabb betölteni egyik, alapszükségleteket kielégítő bloatware sem. Beszélek itt a LibreOffice-ról, a Firefox-ról, a Double Commander-ről. Te azt állítottad korábban, hogy számodra ezek a lassúságok nem okoznak kényelmetlenséget és nekem se kéne, hogy okozzanak. Az sem, ha 15 másodperc egy LibreOffice indulás. Ha tényleg így van, akkor ne sírj a 30% miatt, ugyanis egy LibreOffice egy AMD Turion 64-en nekem 800%-kal lassabban tölt be (SSD-ről!), mint egy Windows XP-re feltett Office 2003 és a működése legalább 100%-kal lassabb. A kettő alapfunkciókban ugyanazt nyújtja (ne gyere járulékos feature-ökkel és az OpenDocument formátumokkal!).

Én sem vagyok a fejlődés ellen. Amit kifogásolok az a fejlődésnek hazudott erőltetett növekedés. Hogy egyik oldalon elveszünk (erőforráspocsékoló szoftverek), másik oldalon hozzáadunk (erősebb hardver). Ez látszatinnováció, szemfényvesztés. Gyakorlati fejlődést nem eredményez. Az SSD-t például minden szempontból fejlődésnek tartom a HDD-khez képest, pláne, hogy relatíve magas életciklusokat is produkálnak már és valahol 5-10 év garanciával is lehet őket kapni. 10x gyorsabb, mint egy winchester, random írás/olvasásban pedig még annál is többször. Tehát, ha berakom a gépembe, akkor sokkalta jobb teljesítményt ad, mintsem azt, amit korábban a winchester adott, csak már egyre kevésbé bírja szusszal szoftverfejlesztőék egyre frissebb™ bloatware-ének I/O terhelését.

Itt viszont azért adtam hangot a felháborodásomnak, mert itt ennél a bugnál egész méregdrága, új, bivalyerős procikat és eszközöket is ki kéne dobni, ami ráadásul nem csak plusz anyagi kiadás, de ha hirtelen mindenki most akar majd emiatt új procit, eszközöket venni, akkor nem csak nagy áremelkedéshez, hanem masszív hiányhoz is vezethet, ami meg káoszhoz.

Íme a következő önellentmondásod. Korábban mindig arra biztattál, hogy még a régi gépeket is nyugodtan Linuxosítsam, mintsem azon görcsöljek, hogy milyen lassúak. Ha egy régi, lassú gépet is fel lehet Linuxosítani Raynes módszerrel, mi baj a bivalyerős gépekkel, amik "csak" 30%-ot lassulnak? Egyébként, azt senki nem mondta, hogy ki kéne dobni, csupán picit belassítják a bivalyerős™ gépet, hogy előbb-utóbb maguktól vegyék meg birkáék az újakat. Tehát, picit felgyorsítják azt a folyamatot, ami oda vezetett, hogy 10 évvel ezelőtt egy 1999-es P3-at is lehetett kényelmesen használni netezésre Operával, ma pedig már egy 10 évvel későbbi 2009-es processzor is lagzik és lassulgat.

Vagy ha kidobni nem is kell, de az a 30% teljesítményveszteség, amit belengetnek, az nagyon durva átlag felhasználói szinten is.

Tudod, van az a mese a békáról meg a forró vízről. Most azért vagy felháborodva, mert hirtelen vetődött fel a kidobás réme. Ha viszont 5 év múlva lassul 30%-ot (csak szépen fokozatosan), és ezzel ösztönözve ugyanúgy kidobatnák veled, az már természetes lenne, mert az már fejlődés™. Valójában így jön rá az ember, micsoda kész átverés az egész haladjunk a korral idealizmus és biznisz. Minden hardver csak egy kicsivel gyorsabb, minden szoftver csak egy kicsivel bloat-abb. Mert ha hirtelen lenne nagyon lassú valami, akkor még az early adopter-ek is visszadobnák, de ha már náluk kint van, ők már példát mutathatnak az early majority-nek és a late majority-nek, meg a laggard-okat is mocskolhatják, ha véletlenül nem akarnak "fejlődni", belehúzva ezzel minél több fogyasztót a túlfogyasztást eredményező pszichológiai csapdákba.

Ez az utolsó válaszom neked itt. Folytathatjuk, de akkor nyiss neki egy külön témát bloat-e a Linux címmel. Ez itt egy sokkal komolyabb, több embert érintő téma, amit nem kéne Winpisti, éljen az XP, használjunk P3-at, antibloatware kreténségekkel összefosni, mert be fognak rágni és igazuk lesz. A külön topikban vissza tudnánk térni a Radeon X1250-es linuxos driver-re is, hogy teszteld egy kicsit megfelelő driver alatt azt a turionos csodát, mielőtt elkezdünk százalékokról meg másodpercekről vitatkozni.

Az informatikában mindennek ára van. Nincs abszolút jó és rossz megoldás, minden előnyökkel, hátrányokkal jön, azokat kell úgy kiegyensúlyozni, hogy a te felhasználásaidhoz minél megfelelőbb legyen. Te, az XP-vel ezt az egyensúlyt még régi gépen sem fogod megtalálni, mert túl nagy árat fizetsz, hogy nem rendesen támogatott (itt nem feltétlen MS patcheket értek csak, hanem böngészőtámogatottságot, stb.-t is), elavult rendszert használsz. Árat az én is fizetek, hogy pl. ez-az kicsit lassabban indul, de összességében sokkal kisebbet, mert nem csak támogatott szoftvert használok, de olyanokat, amik előrébb vannak feature-ben, sőt, néha sebességben is akár (nem indulási időt értek ez alatt feltétlenül), ezért írtam, hogy sok ponton visszanyerem azt a kis töltési időt (kapásból a bootidőm 4 mp., ami XP alatt egyenesen lehetetlen lenne SSD-vel is). Vagy új lehetőségeket nyit előttem, mert tudok olyan dolgokat futtatni, ami nálad XP alatt már esetleg nem futnak egyáltalán.

Továbbá kevered a dolgokat. A LibreOffice, GIMP, tényleg bloat, de kibírja az ember azt a kicsi töltési időt egyszer, csak cold startnál van, és ez nem jelenti azt, hogy a felület lagolna vagy akadozna. És itt most tényleg csak egy kevés töltési időről van szó, nálam konzumer, olcsó, SATA2, SATA3 SSD-vel ősrégi, használt, olcsó üzleti laptopokon 2-3 mp. között van a nevezett szoftverek cold startja. Ennyitől senkinek az élete nem dől dugába, hogy ne tudná kivárni. A Double Commandernél az a hosszú töltési idő a Qt5-ös verzió bugja, mióta áttértem Openboxra és Gtk-ra, azóta jóval 1 mp alatt van a DC indulási ideje, lényegében azonnal indul, igaz megmaradt egy másik bugja, amivel továbbra sem vagyok kibékülve. A Firefox meg azonos gépen Linux alatt gyorsabban indul, mint Windowson, legalábbis nekem ez a tapasztalatom. Az a baj, hogy nem látsz túl az indulási időkön, és a task managerben látott CPU%-okon, az csak a nagyobb képnek egy egész kicsi mozaikja, főleg ilyen nagyságrendű eltéréseknél.

„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

Teszteltem X1250-es driver-rel és remélem, hogy nem próbálod nekem beadni, hogy netán egy szar videókártyadriver miatt tölti 15 másodpercet a LibreOffice a velejéig bloated komponenseit.

Ne haragudj, de nekem semmi hátrányom nem származott még abból, hogy a rendszerem nem támogatott. Az XP egy kiforrott, stabil rendszer, 13 év fejlesztési tapasztalata van mögötte. Nekem pedig sokkal fontosabb, hogy az alkalmazások ne lassulgassanak idővel (frissítéssel, GTK3 és Qt5 szélsőséges idealista bloatware bejövetelével), vagy hogy ne húzzák ki évente-kétévente alólam a talajt a tablet- és touchscreen-idealista, Linux világot is felülfertőző és elrákosító "fejlesztések", használhatatlanná téve a jól bejáratott módszereimet.

Az a baj, hogy egyik oldalon nyüszítesz a 30%-odért, a másik oldalon meg elhiteted velem, hogy a sokkal durvább, fejlesztői lustaságnak és idealizmusnak köszönhető lassulás elfogadható. Magyarul, hogy a több kevesebb. Engem az érdekel, hogyha én benyomok egy Word-öt, az azonnal induljon, 10 év múlva is, ugyanezen a gépen és nem minden évben egy másodperccel később.

Fura, de nekem gyorsabban indul a W10, mint az XP ugyanazon a kőkorszaki* gépen. Érthetetlen. :(

* Athlon X2 3800+, 4G DDR2, valami IDE-s szar HDD, előző gépem, negyedévente egyszer használom, ha hazanézek szüleimhez.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

SSD-ről nem nagyon lesz különbség. Futásban, használhatóságban pedig óriási különbségek vannak, az XP javára. Bírom, hogy ha a neved meglátom és ilyen téma van terítéken, egyből boot idővel, meg TDP-kkel kezdesz el dobálózni. Aminek használati szempontból az égvilágon semmi értelme, de még a költséghatékonysághoz sincs sok köze, ha nem 0-24 működő szervergépről beszélünk.

„A Windows XP GDI-je sokkal gyorsabb egy régi hardveren”

A Windows 3.1 pedig még gyorsabb lehet. És kb. mindegyik ugyanannyira támogatott az átlagfelhasználó számára.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

A Windows 3.1 rajzolása jóval lassabb. Emlékszem, pár éve még 386-osra raktam Windows 95-öt. Az egész rendszer lassú volt úgy en bloc, de a rajzolása gyorsabb volt, mint a 3.1-nek. Persze a mainstream véleményből kicsírázó általánosítgatás mindenek felett áll. A Windows XP a POSReady 2009 flag engedélyezése után támogatottá válik. Emellett, kicsit másra való, mint egy 3.1. A GDI-t XP-n optimalizálták ki a legjobban. Ott a leggyorsabb. Pentium III-ason gyorsabb mint a 98.

Nekem az a kérdésem, hogy ilyen áron megéri-e a hosszú pipeline? Bevezettek 10-nél több lépcsős pipeline-t, ami felgyorsítja a processzort, aminek az a következménye, hogy szét kell választani a kernel és user page-eket

Mi gyorsabb?
- rövidebb a pipeline?
- vagy szétválasztani a kernel és user page-eket

Google szerint ARM is érintett, amit a latest 2018 januári peccsel már be foltoztak. Kár, hogy ez az Android eszközök 99%-ánál a frissítések hiánya miatt nem releváns.

--
robyboy

Erről jut eszembe...

Érdeklődnék egy olyan statisztika után (sajnos nem találtam), amiben az olvasható, hogy mennyi olyan iPhone van használatban, amire már nincs frissítés. Jó pár millió ilyen eszköz van.

Van egy olyan sanda gyanúm, hogy az Apple "jaj mennyien frissítettek már a latest OS-re" (mintha rondulna ez is nem?) statisztikákban csak a támogatott eszközök vannak benne.

Tudnál segíteni?

--
trey @ gépház

Most az fáj, hogy nem csak az Apple szar, hanem kb. minden?
Jó sokáig élhettünk abban a hitben, hogy everything is all right... kb. 10 évig.

Aztán még mik derülhetnek ki. Sajnos a fejlődés ára pont ez: kurva bonyolult technológiák, tele hibákkal. Eddig csak mosolyogtunk a sok Errata-n, most lehervadt a mosoly.

--
robyboy

Félreértesz, nem fáj semmi. Az érdekelne, hogy az Apple kozmetikázza-e a számokat vagy sem. Csak a kommented nyomán jutott eszembe.

Csak azért ontopik ez itt, mert hivatalosan (a dec. elejei adatok alapján) az Apple készülékek majdnem fele érintett. Ha pedig kozmetikázva van a statisztika (mert csak a támogatottakakat veszik), akkor jóval több.

--
trey @ gépház

Immár nem feltételezés:

"All Mac systems and iOS devices are affected, but there are no known exploits impacting customers at this time."

Az összes, iOS 11.2-nél régebbi rendszert futtató telefon érintett:

https://support.apple.com/en-us/HT208394

Meltdown-ra. A többire meg egyébként.

--
trey @ gépház

Ez nem a fejlődés, hanem az innovációnak hazudott erőltetett verseny és erőltetett növekedés eredménye. Nincs idő mindenre gondolni és normálisan kidolgozni egy processzort, mert nyakukon a határidő, és a profitéhes befektetők. Egyetlen szériát kéne csak normálisan megcsinálni. Csak egyet. Utána lehetne azt sokáig futtatni, kioptimalizálni rá mindent, már ha az Intelnek még saját C++ fordítóra is futja. Ha indulna egy globális class action az érintett gyártók ellen és én lennék a bíró, mindegyiket első körben arra kötelezném, hogy 5 évig nem hozhat ki új terméket és nem is reklámozhat semmit. Öt évig kuss és dolgozni egy normális szérián. Utána lehet villantani, aminek már nem csak marketing értéke van (iciri picirivel gyorsabb benne ez meg az), meg plusz magokkal tűzdelték tele.

Azoknak lenne feladata mondani, akik éveken keresztül forintra átszámolva havi több millióért dolgoztak ki tervezési hibás processzorcsaládokat, majd elárasztották a piacot vele.

Netán azt akartad mondani, hogy kussoljak a szent™ és sérthetetlen™ processzormultikkal kapcsolatban, ha nem tudok olyan jól muzsikálni, mint ők?

Érdekes módon akkor senki nem picsogott, mikor ezen "tervezési hibás" processzorok miatt gyorsabbak lettek a dolgok. Nem véletlen ment mindenki ebbe az irányba.

Megjegyzem, igen, az egyik esetben valóban elcseszte az intel, másik eset meg olyan, hogy az elmúlt 20 évben (kb. a PPro óta) senki nem gondolt arra, hogy ez így is kihasználható hiba. De ez pontosan olyan, hogy korábban senki nem gondolt arra, hogy egy repülőgépet akár bele is lehet vezetni a Pentagonba meg a WTC-be, míg valaki meg nem csinálta.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mivel nem gondolták végig, hogy mit csinálnak, csak a gyorsabb™, újabb™, innovatívabb™ termékek vásárlókra tukmálása érdekelte őket. Persze a robbanó Galaxy Note 7-re is volt piaci igény mindent elsöprő, a szükségességét benyalató marketingkampánybullshit. Láttuk mi lett a vége.

Gyorsabb processzorokra pedig nem lenne szükség, ha a lusta fejlesztők összeszednék magukat és normális kódokat írnának .NET, Qt, Java és bloated keretrendszerek helyett standard C/C++ alapú, assembly-ben optimalizált kódot.

Mondjuk manapság az optimalizációt inkább úgy jobb csinálni, hogy jobb algoritmust írsz, nem úgy, hogy átírod ASM-be, éppen azért, mert a mai CPU-k már nem egyszerűen azt csinálják, amit te mondasz nekik ASM-ben.
A Conspiracy demócsapat egyik programozója mondta tizenpár éve egy 4k-s intró megírása után, hogy a C fordító már kisebb és gyorsabb kódot adott, mint amit ő írt meg külön ASM-ben.

> Az assembly az optimalizációra vonatkozott.

Erőteljesen meglepődnék, ha te (vagy akár egy átlag matematikus, infós, én) optimalizáltabb assembly kódot hányna ki magából, mint egy gcc/jcv/clr egy ugyanilyen ember által írt c/c++/java/c# kódjából.

De persze ez nem érdekel téged, mert azt nem veszed észre, hogyha visszamennénk fejlesztés terén a ~80-as évekbe, akkor minden egyéb területen is visszamennénk odáig.

De persze ez nem érdekel téged, mert azt nem veszed észre, hogyha visszamennénk fejlesztés terén a ~80-as évekbe, akkor minden egyéb területen is visszamennénk odáig.

http://a.te.ervelesi.hibad.hu/hamis-kompozicio-vagy-felosztas

Azt mondtam, hogy alapvetően C és C++ alapokon képzelném el a matematikai problémák leprogramozását és a kritikus részeket assembly-ben implementálva. Semmi értelme nincs az egészet assembly-ben megírni, de néha van értelme inline assembly-vel optimalizálni.

> Kirúgom a .NET specialista megélhetési mérnök urat és felveszek a helyére egy matekzsenit, aki megírja assembly-ben.

nem én mondtam.

btw, meg azt is meg merem kockáztatni (de már kevésbé bátran), hogy az átlagmatematikus/átlaginformatikus által írt c/c++ kód is rosszabb performance-t hoz, mint ugyanezen emberek által írt java/c# kód.

A fenti mondatomat továbbra is tartom.

Uram isten.. Te komolyan azt gondolod, hogy ha megfelelő emberórát ölünk egy feladatba, akkor annak a végén egy tökéletes megoldás fog születni, ami garantáltan hibamentes, és a jövőben sem találhatnak benne olyan támadási vektort amit a kiötlés pillanatában nem is ismertek?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

„Gyorsabb processzorokra pedig nem lenne szükség, ha a lusta fejlesztők összeszednék magukat és normális kódokat írnának .NET, Qt, Java és bloated keretrendszerek helyett standard C/C++ alapú, assembly-ben optimalizált kódot.”

Ezt idézni fogom, annyira szép! Amúgy gyorsabb autókra se lenne szükség, ha senki se sietne sehova.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Mindennek van határa. Valahol meg kell húzni.

Amúgy gyorsabb autókra se lenne szükség, ha senki se sietne sehova.

Jó példa. Az autók már elérték azt a fizikai sebességkorlátot, mellyel biztonságban vezethetőek. Hasonlóképpen, ahogy a processzorgyártás is már elérte, ezért raknak már mindenbe több magot. Csak ott az a bökkenő, hogy attól még, hogy két autóval mész, nem leszel ott gyorsabban. Nem mellesleg, hogy fizikailag nem is tudsz egyszerre két autóval menni.

Csak hogy a számítógépen egyszerre nem egy processz fut, mint ahogy a család sem egy emberből áll. És egy család tud egyszerre két autóval menni.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

A hasonlat úgy állná meg a helyét, ha azt mondanánk, hogy az autók sokkal gyorsabbak, mint amekkora sebességet az autóutak ki tudnak szolgálni.

A probléma fő oka az, hogy nincs szinkronban a memória, busz sebessége a CPU adatfeldolgozási sebességéhez képest. Ezért folyamodtak mindenféle trükközéshez, amiről meg pont most derült ki, hogy nem valami jó megoldás.

--
robyboy

uh.. Feladat függő.

Családnak van XX dolga amit Y-ba el akar juttatni.

Család megy egy autóval, akkor elvisz első körben X dolgot Y-ba , majd visszamegy az otthon hagyott (mivel nem fért be az autóba) második X-ért, majd megint elmegy Y-ba...

30-30-30 perc / X... (mivel ugye Y-ból vissza is kéne jutni X eredeti helyére)

Nade, családnak van két ótója, és van ugyanazon XX dolga amit el kellene vinni Y-ba.. Akkor család elindul két ótóval, ha mind a két ótón van 1 darab X.. utazási idő Y-ig == 30 perc...

Előző esetben ez 90perc.. Mivel 1 autóval mennek szerencsétlenek azt még vissza is kell menni az otthonhagyott 1 darab Xért...

Nos ?

Hmmm, nem értek hozzá, de annó nem azért jött be az elágazásbecslés, hogy ne legyen időveszteség a cache dump - reloadból elágazásoknál? A cache meg azért kellett, mert a nagyon nagy volt a memória elérési ideje és a processzor műveleti sebessége közti különbség?
Nem lenne egyszerűbb visszavenni proccesszor órajelét és a cachet elfelejteni? Vagy rágyúrni a memóriatechnológiára és akkora cacheket integrálni, hogy elég legyen rendszermemóriának? Az egyik lassú megoldás a másik meg drága...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Az csak annak függvénye, hogy milyen technológiájú memóriát integrálnak. Ha a mostani cache technológiánál maradnak, az tutira megdobná az árat. De ide a rozsdás bökőt, hogy némi kreatív agyalással össze lehetne varrni más memória megoldást is.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Miből gondolod, hogy nem egyszerűbb lenyelni a teljesítményvesztést és egyszerűsíteni az architektúrát?
Értem én, hogy a belső cache jó dolog, mert jól lehet vele zsonglőrködni és a processzoron belüli tákolásokat, gányolásokat elfedni, de szívem szerint én jobban preferálom a faék egyszerűségű dolgokat. Különösen úgy, hogy közben a félvezetőgyártásban igen erős paradigma váltás volt. Régebben ment az egy lapkára minél több plusz funkcionalitás belezsúfolása, ma meg már lassan mikrokontrollereknél is die stacking és az in-chip bondinggal oldanak meg mindent.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Mert van ez a fránya fizika nevű dolog, ami szeret gátat szabni az ember vágyainak. Ld. P4 vs Core: P4-nél próbáltak egy egyszerűbb architektúrát, majd annak az órajelét emelni, aztán a fizika azt mondta, hogy nop. Core-nál azt mondták, hogy jó, akkor nem emelünk órajelet, mert nem lehet, cserébe megpróbálták okosabban futtatni a kódot. Mert ez működött. Most is működik, mert futnak a kódok, probléma az, hogy van egy securityt érintő side effectje.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

CoreCodec halott, LAVFilters-ben meg egy kanyi ASM kód nincs. Egyébként nem tudom miért akar bárki is P4-re optimalizálni, mikor ott a GPU a gépben, ami ugyanezt a feladatot sokkal hatékonyabban tudja megcsinálni. Pont ezért mozdult el a VGA piac is az unified shader model irányába nagyjából akkortájt.

De ez még mindig nem NP teljes probléma.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Attól még, hogy "halott", teljesítményben veri a Chrome-odat, a Firefox-odat és bármilyen .NET bloat-odat. Attól még, hogy "halott", használható és nem lenne "halott", ha szoftverfejlesztőék P4-re optimalizálnának.

De ez még mindig nem NP teljes probléma.

Egyetértünk.

http://a.te.ervelesi.hibad.hu/szemelyes-ketely

Attól még, hogy Shark Mérnök Úr nem érzi át Bloat Kolléga által felvetett, a világot és a környezeti egyensúlyt fenyegető problémákat, nem biztos, hogy chatbot. Ha pedig valami nem szórakoztató, akkor csapd fel a szélsőséges idealista bloatware Netflix-et, aztán szórakozz. Nem kötelező nekem válaszolgatni.

Az NP-teljes probléma megoldása pedig lehetséges assembly-ben, de nem fogom ideírni a forráskódját, hiába erőlködik Saxus Mérnök Úr. Azért nem fogom ideírni, mert nem az én dolgom megírni. Azoké a matek"zseniké", akikkel példálózott tegnap.

Kérlek, ne mérnökuraz le, ez sértés a mérnököknek :)

Az NP-teljes probléma megoldása pedig lehetséges assembly-ben, de nem fogom ideírni a forráskódját, hiába erőlködik Saxus Mérnök Úr. Azért nem fogom ideírni, mert nem az én dolgom megírni. Azoké a matek"zseniké", akikkel példálózott tegnap.

Hát, végül is csak több millió dollárt fizetnek pár megoldásért, és csak 50 éve kutatják, és nem is biztos, hogy van megoldás.

Ebben az esetben viszont abszolút, de teljességgel abszolút mindegy, hogy brainfuck-ban, HLA-ban, C-ben, Javában, vagy JavaScriptben írod meg a kódod kb. Viszont jobban megéri ASIC-ot építeni, mert a P4 erre biztos nem lesz elég pármilliós elemszámnál, emberi időben.

Arra próbáltam rámutatni, hogy a karrierjüket a piacon faék egyszerűségű, és olcsó processzorokkal alapozták meg. Az már más tészta, hogy a faék egyszerűségű processzoraikba beletették a nagyok csodás ötleteit abban a hiszemben, hogy ezzel biztosíthatják a versenyképességüket. Ennek a következménye, hogy az aktív portfóliójuknak "csak" a fele érintett.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Az ARM sztori onnan indult, hogy akartak készíteni egy alacsony fogyasztású, olcsó processzort (Acorn, Apple, VLSI összeborulás). Ezt úgy érték el, hogy az Acornnál fogták a 6502-e 8 bites processzort (ami már akkor egy részben javított és részben kiherélt Motorola 6800 volt), felbővítették 32 bitre, és kidobták az utasítás készlet kb. felét. Ezzel elérték, hogy a tranzisztorszám 30000 körül volt, ami durván 10000-el kevesebb mint a konkurens 68000 -ben. Ez lett az ARM2. Az alacsonyabb tranzisztorszám következtében, jobban tudtak felfelé menni sebességben és olcsóbb volt a proci az összes konkurenciánál. Itt szállt be az apple (úgy 89-90 magasságában) és született meg az ARM6 architektúra (35000 tranzisztor) ami később az Apple Newtont is hajtotta. Az Acorn a külön céget hozott létre a fejlesztőiből (ez lett az ARM Ltd.), és a trióból csak a VLSI-nek volt valós gyártáskapacitása, a leosztás úgy nézett ki, hogy az ARM szedhette licencdíjakat, a VLSI és az Apple megkapta a terveket ingyen. Ez mindenkinek jó volt, mivel akkor és ma is egy gyártó nagyjából a chip árának a harmadát fizeti a chiptervezőnek. És ez volt az ARM legnagyobb újítása, mivel fabless cég voltak, nem kellett kifizetniük a prototípusok és a chipgyártó részleg költségét, ezért nem kellett ezeknek az árát beépíteni a licenc díjakba. Rá is bukott az összes chipgyártó, mint csirke a takonyra, mert nekik meg nem kellett fenntartani a tervezőrészleget.
Gyakorlatilag azóta, a mai napig, annyit csinálnak, hogy a nagyok technikai fejlesztéseit lebutítva, félig implementálva építik be a saját termékeikbe.
És ez az oka, hogy a mai napig fostalicska processzorokat használunk minden hordozható eszközben. Nem azért mert annyira energia hatékony, szimplán csak azért mert olcsó.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

> Ezt úgy érték el, hogy az Acornnál fogták a 6502-e 8 bites processzort (ami már akkor egy részben javított és részben kiherélt Motorola 6800 volt), felbővítették 32 bitre, és kidobták az utasítás készlet kb. felét.

Ezt hol olvastad, hogy az ARM2 az egy fejlesztett 6502-es, aminek kihajigálták az utasításai egy részét? Teljesen más a regisztertérképe, egyáltalán a regiszterkezelés koncepciója; teljesen más az utasítások dekódolása, az opkódok bittérképe, az utasítások paraméterezése, a címzési módjai és ráadásul nagyjából ugyanannyi alaputasítás van benne (36 vs 49), csak azok is teljesen mások és máshogy működnek. (Illetve, ha a branch utasításokat külön nézzük, nem csak úgy, hogy van benne branch utasítás, akkor még több is van az ARM-ban: 70 vs 56.) És ez is úgy, hogy az utasítások feltételes módjait nem számoltuk bele.

A dec. 5. és dec. 12. közötti 5000 USDs ugráshoz és a dec.17 és dec.24 közötti 5000 USD köröli eséshez viszonyítva? Szerintem, elég vízszintesnek tűnik az egy hetes periódus középátlaga.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Vélhetően itt friss információk lesznek:

https://spectreattack.com/

--> Which systems are affected by Meltdown?
--> Which systems are affected by Spectre?

A másik jó kérdés, hogy melyikre mikor lesz valódi javítás a futó Linux kernelekben?

--> PC-s, szerveres környezetben
--> ha ARM-ot érinti, akkor a sok-sok telefonra/tabletre
... és a néhány éve vásároltakra?

Android:

https://support.google.com/faqs/answer/7622138#android

"On the Android platform, exploitation has been shown to be difficult and limited on the majority of Android devices.

The Android 2018-01-05 Security Patch Level (SPL) includes mitigations reducing access to high precision timers that limit attacks on all known variants on ARM processors. These changes were released to Android partners in December 2017."

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-y…

Android

"Devices with the latest security update are protected. Furthermore, we are unaware of any successful reproduction of this vulnerability that would allow unauthorized information disclosure on ARM-based Android devices."

Linux kernel:

https://lwn.net/Articles/742620/

4.14.11 Stable szériában már benne van a patch

Disztribútorok:

Red Hat:

https://access.redhat.com/security/vulnerabilities/speculativeexecution

Ubuntu:

https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown

"2018 Jan 03: issue becomes public a few days before the CRD"

Koordinált release dátum (CRD) január 10. volt asszem (9-e Patch Kedd), de az infót előbb kiadták. Gondolom a disztribútorok jan. 10-re készültek, ahogy a Microsoft és a többi is.

--
trey @ gépház

Jajj, de jó, hogy végre valaki konkrétumokat ír, nem bullshitet. Ezek szerint védve vagyok, mert a 4.14.11 már tegnap kint volt az Arch tárolóiban, és mivel rendszeresen frissítek, így nem sokáig voltam sebezhető elvileg. Így ki is lőttem a 4.15RC6 már jó órája tartó fordítását, az AUR script nem defconfiggal fordította, hanem az összes modullal, ami x86_64-en szóba jön.

Az viszont zavar, hogy néhány forrás szerint a Spectre1 sebezhetőségre Intel CPU esetén NINCS patch, mivel nem lehet foltozni, csak a Spectre2 és Meltdown-sebezhetőségeket.

„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

:D

Szerintem azt azért fordította sokáig, mert minden modul benne volt, nem defconfiggal nyomta.

De a kérdés jó, lassulást amúgy nem tapasztalok a rendszeren. CPU-terhelési adatokat még nem néztem alaposan, de semmi kiugrót nem látok így sebtiben processzeknél, érzetre semmivel nem lassabb a gép. Igaz alaposan majd csak hétvégén lesz időm tesztelni.

Az viszont még aggaszt, hogy sebezhetőséget felfedező szakemberek 30%-os teljesítménycsökkentést lengettek be, ehhez képest phoronixos tesztek egyes esetekben 50% fölötti visszaesést mutatnak Linuxnál.

Bár előrébb nem vagyunk vele, de szerintem nem az Intel sara. Erre senki nem gondolt, ezért is érintett szinte az összes modern CPU architektúra valamilyen mértékben. Ez valahol jó is, mert ha csak az Intel lenne érintett, akkor könnyen mondanák, hogy vegyél másik procit, de így, hogy az összes architektúrában megtalálható bizonyos szinten, így tényleg mindenkinek neki kell feküdnie, hogy legyen ésszerű megoldás erre a lehetetlen helyzetre.

„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

btw, rhel7.4 -re (és centos7.4-re is) délután érkeztek ezzel kapcs. fixelt csomagok: linux-firmware, kernel, microcodectl*. Egész gyorsak voltak a "srácok" RHEL-nél és CentOS-nél is. Az hogy ez most "mindenre _is_ jó-e" vagy se, azt passzolom.

https://lists.centos.org/pipermail/centos-announce/2018-January/thread…

Mi a helyzet a MediaTeK (MTK) processzorokkal?

Szerintem azok is érintettek, mivel ARM-esek.

„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

Ja, kb a mikrokontroller-szintű CPU-k nem értintettek.

Elképzelhető egyébként, hogy rövid pipeline-os in-order CPU-k is gyakorlatilag védettek, mert nem elég hosszú a mispredicted végrehajtás. Bár az utóbbi időkben tudtommal nem nagyon jött ki még in-order változatban sem olyan architektúra, ami 10-nél kevesebb pipeline fokozatot használna, 10 pedig már elég lehet a támadáshoz.
---
Régóta vágyok én, az androidok mezonkincsére már!

getppid(2) 4x lassabb a patch utan.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

... na megyek előveszem a garázsból a régi floppy lemezeket. Van még rajtuk 1-2 jó progi, azok talán még elfutnak wine alatt vagy dosboxban, internet nélkül a patchelt CPUn.

"Processor microcode is akin to processor firmware. The kernel is able to update the processor's firmware without the need to update it via a BIOS update. A microcode update is kept in volatile memory, thus the BIOS/UEFI or kernel updates the microcode during every boot.

Processors from Intel and AMD may need updates to their microcode to operate correctly. These updates fix bugs/errata that can cause anything from incorrect processing, to code and data corruption, and system lockups." - Debian - Microcode

Kérdem én, mire való ez a feature, ha nem arra, hogy az efféle hibákat a lehető legalacsonyabb szinten, a lehető legegyszerűbben megoldják?

Miért kell szoftveresen amatőrködni?

Mi lenne, ha szimplán kikapcsolhatóvá tennék a nem oda való kód futtatgatását egy mikrokód frissítéssel?

Miért nem jutott eszébe az Intelnek microcode frissítéssel javítani a hibákat? (Tán nem azért, hogy belassíthassa a CPU-it és újat vetethessen?)

Képzeld el, hogy van egy petróleum-lámpád, amin van egy bizgentyű, hogy mennyi petróleumot engedjen elégni. Kapsz egy útmutatót hozzá, hogy hogyan állítsd be, hogy mennyi petróleum fogyjon és mennyire legyen világos. A probléma az, hogy amiatt, hogy a lámpa petróleumot éget, kormol, emiatt van rá mód, hogy kifigyeljék, hogy este hol szoktál sokat elidőzni. Na, most akárhogy tekered a bizgentyűt az útmutató (=mikrokód) alapján, attól még nem lesz belőle villanylámpa, hogy megoldja a kormolódási problémád.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™