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

Bug

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

( hendrick v | 2018. 01. 04., cs – 09:04 )

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!

( kovi | 2018. 01. 04., cs – 09:25 )

jól beindult a buli

--
Vortex Rikers NC114-85EKLS

( Hiena v | 2018. 01. 04., cs – 10:15 )

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

( toMpEr | 2018. 01. 04., cs – 10:43 )

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.

( koqsz | 2018. 01. 04., cs – 12:00 )

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.

( toMpEr | 2018. 01. 04., cs – 12:13 )

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

( csabka v | 2018. 01. 04., cs – 13:18 )

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

( nevergone v | 2018. 01. 04., cs – 13:30 )

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…

( hajbazer v | 2018. 01. 04., cs – 13:58 )

Ú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."

( Raynes v | 2018. 01. 04., cs – 13:55 )

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

( uid_16313 | 2018. 01. 04., cs – 14:08 )

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™

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.

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…

( summoner | 2018. 01. 04., cs – 14:53 )

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!

( turul16 v | 2018. 01. 04., cs – 18:52 )

getppid(2) 4x lassabb a patch utan.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( tobi | 2018. 01. 04., cs – 21:01 )

... 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.

( hajbazer v | 2018. 01. 04., cs – 22:27 )

"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™

Igazából az a baj, hogy hajbazer ideig-óráig még vicces is volt, amiért megérte elolvasni az új hozzászólásait. De most már kifulladt, erőltetett és szánalmas.
Egy valami viszont nem változott: érdemi szakmaiság sem akkor, sem most nincs a hozzászólásaiban.

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

Igazából az a baj, hogy Frankó Mérnök Úr éppen azt akarja bebizonyítani, hogy egy régi számítógép üzemeltetése több erőforrás igénybevételével és környezetterheléssel jár, mint egy újat legyártani, leszállítani, majd tovább használni a mínusz 1-10-15-20 wattjával.

Ezt nem én bizonyítom, hanem ez van... :)

Az ENIAC 150 kWh energiából hozott ki 18 millió 10 bites matematikai műveletet... egy i9-7900X pedig 0,14 kWh energiából hoz ki 4150000 milliárd 32 bites matematikai műveletet. A kettő között te hol húznád meg az ésszerű határt és miért pont ott?

Igen, volt idő, amikor még nem volt igaz (ENIAC kora). Ma viszont igaz az, hogy nem éri meg egy laptopot lecserélni azért, mert az új 10 Wattal kevesebbet fogyaszt. Egyrészt, a villanyszámlára sohasem fogsz annyit kifizetni, amiből kijönne a laptop, másrészt, a gyártás és a szállítás sokkal több energiát vett igénybe, mint a laptop az élettartama során bármikor is elhassznál.

Bármelyik olyan processzoron, amelyikre fejleszthető olyan szoftver, ami a mai igényeket minimálisan ellátja alkalmas arra, hogy meghúzzuk a vonalat. Minimálisan alatt értsd, hogy nem 4K-ban megy le a videó, hanem 360p-ben. Egy P3-P4 ezt az igényt ellátja. A Web-en mindenfélét csinál az ember, de az leegyszerűsíthető néhány puritán, konkrét igénnyé: szövegolvasás, szövegírás, zenehallgatás, videónézés. Ezekre pedig lehet jól optimalizált, natív szoftvereket írni, ami jól elmegy a P4-en.

Lehet, de nem minket kell meggyőznöd hanem a többi embert. Azaz arról hogy milyen jó a puritánság. Továbbra is rossz helyen házalsz a HUP-on. Mi csak kiszolgáljuk az igényeket. Megmásítani nem igazán tudjuk. Ha megjönnek a megrendelések/igények puritán optimalizált, XP kompatibilis, ASM programokra, azokat is lefejlesszük. ;)

Még midig várjuk a példamutatásod, hogy nem csak otthon működik nálad az XP, hanem erre lehet komoly vállalkozást is építeni. Kövesd Bea Johnson példáját!

"[...] meghúzzuk a vonalat [...]"

De miért húzod meg önkényesen itt a határt? Semmi objektív és racionális indokot nem tudtál erre soha felmutatni.

"Ezekre pedig lehet jól optimalizált, natív szoftvereket írni, ami jól elmegy a P4-en."

Mondok egy nagyon meglepő dolgot: a natív szoftver sokszor lassabb és erőforrás igényesebb, mint egy köztes kódra fordított szoftver.

Egyszerűen azért, mert natív esetben egyetlen egy felhasználási módra tudsz optimalizálni; köztes kód esetén viszont mindig az adott felhasználási módra fog optimalizálni a futtatókörnyezet, mindig azt a részét fogja a végletekig optimalizálni, ami épp a legjobban van használva.

Az a bajod, hogy címszavakat ismersz a technológiából és simán betiltanál egy csomó dolgot, ami kicsit is hozzáértő szemmel olyan, mintha betiltanád a vizet, mert:
- a savas eső fő komponense,
- hozzájárul az üvegházhatáshoz,
- gőze súlyos égést okozhat,
- hozzájárul természeti környezetünk eróziójához,
- számos fém korrózióját, rozsdásodását sietteti,
- hibát okozhat az áramszolgáltatásban, rontja az autók fékhatását,
- rákos daganatokban is kimutatható.

Az állítások egyenként önmagukban igazak, de ezek miatt faszság lenne betiltani a vizet. Na, te pont ezt csinálod, csak az elektronikai cuccokkal.

De miért húzod meg önkényesen itt a határt?

Mert azt kérdezted, hová húznám meg ezt a határt. Elmondtam. Ha az a kérdés, hogy miért pont itt, azt is elmondtam. Mert a szóban forgó hardverek már minimális szinten képesek bizonyos feladatokra, amiket megfelelő optimalizáció mellett el is látnak.

a natív szoftver sokszor lassabb és erőforrás igényesebb

Előfordul ilyen is, igen, de ez inkább algoritmusokra jellemző, esetleg lib-ekre. A készre írt, felhasználói szoftverek esetén sokkal inkább jellemző az a tendencia, hogy a natív, bloat framework (Qt, .NET stb.) nélküli, ezektől függetlenre megírt szoftver az, ami kevesebb CPU-ból és memóriából elvan.

azért, mert natív esetben egyetlen egy felhasználási módra tudsz optimalizálni; köztes kód esetén viszont mindig az adott felhasználási módra fog optimalizálni a futtatókörnyezet

Amellett, hogy ez egy szélsőséges idealizmus, amit szoftvergyártóék sikerrel beadtak neked, egy felhasználói szoftver esetében sokkal többe kerül a semmit nem érő run-time optimalizáció, mint ha magát a fordított kódot optimalizálták volna.

Az állítások egyenként önmagukban igazak, de ezek miatt faszság lenne betiltani a vizet.

Nem akartam betiltani sem a vizet, sem a bloatware-eket. A törvényi szabályozás és a kötelező performance tesztelés más tészta. Jónéhányszor említettem már azt is, hogy belsős használatra még a bloatware keretrendszerekkel sincs baj. Akkor van velük baj, ha milliók használják és szoftverfejlesztőék gigawattokat pocsékoltatnak el ezekkel a milliókkal, csak mert lusták voltak normáliásan optimalizált, natív kódot írni.

"Mert azt kérdezted, hová húznám meg ezt a határt."

Hardvernél. De te "bizonyos feladatokra" húzol önkényesen határt.

"A készre írt, felhasználói szoftverek esetén sokkal inkább jellemző az a tendencia, hogy a natív, bloat framework (Qt, .NET stb.) nélküli, ezektől függetlenre megírt szoftver az, ami kevesebb CPU-ból és memóriából elvan."

Nem, egyáltalán nem így van. Azért mondasz ilyen faszságokat, mert a felületét se kapargatod a technológiának, és mindenen csak azt a koszréteget látod, ami a mocskod kezedről tapadt rá. Ha akarom, akkor egy Java process kevesebb memóriából elvan, mint egy C++ implementáció. Ha akarom, akkor több memóriát használ, de gyorsabb. Ha akarom, akkor csak az a része gyors, amit épp használnak. Ha akarom, akkor minden része gyorsabb, de lassabban indul. Ezekre mind van JVM opció, nagyjából 600 paraméter szerint tudod futtatni az alkalmazásod, attól függően, hogy mire akarsz épp optimalizálni.

"Amellett, hogy ez egy szélsőséges idealizmus, amit szoftvergyártóék sikerrel beadtak neked, egy felhasználói szoftver esetében sokkal többe kerül a semmit nem érő run-time optimalizáció, mint ha magát a fordított kódot optimalizálták volna."

Nem, én ezt a saját kezemmel mértem ki.

"Akkor van velük baj, ha milliók használják és szoftverfejlesztőék gigawattokat pocsékoltatnak el ezekkel a milliókkal, csak mert lusták voltak normáliásan otimalizált, natív kódot írni."

Mutass példát, írj sokkal jobbat és tarold le a piacot. Senki nem akadályoz meg benne. Tulajdonképpen csak saját magad akadályozod meg ezt azzal, hogy az sok sírás helyett értelmes dologgal foglalkozz...

Off:

Most kicsit kicsordult a könny a szememből :) A régi szép idők, mikor még performancia optimalizáltam Javában. Nosztalgiával gondolok vissza, de már nem az én feladatom.
Mondjuk, tényleg érdekes, hogy mennyi irányba el lehet vinni egy alkalmazást anélkül, hogy újra kéne forgatnom.

És el sem fogod hinni, de képzeld el, egyes autók műszerfalát, a műszereket is .Net-ben programozzák, mert egy nagy kijelző van a helyükön. ;)

Ráadásul, egy olyan processzor van benne, ami megeszi reggelire a P4-et, jóval kevesebbet fogyaszt, és még military grade is! Sőt, még vissza is olvassa real time, mit rajzolt ki a műszerfalra. HA hibát észlel, akkor pedig 0,8 mp alatt újraindul, és újrarajzolja. .Net-ben, nem natív kódban!

Ha ez tényleg igaz és nem csak a .NET-es technológia mögötti szélszes adta be az autógyártóknak, akkor ebben az esetben nem gondolom kivetnivalónak a .NET használatát. Már persze, ha a fedélzeti számítógép több feladatot is ellát és cserébe nem fogyaszt többet az akkumulátorból (elektromos autót feltételezve).

Ez viszont még ugyanúgy nem ad jogalapot arra, hogy milliók által használt szoftvereket .NET-ben írjanak és sokkal többet pocsékoltassanak el a számítógépekkel annál, mintha C vagy C++ alapokon írták volna (nem, nem Boost-ban vagy Qt-ban).

Csak a műszeregységen megjelenő adatokért felel.

Gondolom nem jelent gondot a fogyasztás. Itt tényleg wattokról beszélhetünk (miközben 30+ kWh aksik vannak), úgy, hogy ki kell bírnia szélsőséges körülményeket. Egy ismertebb, német gyártónak, aki elég komoly villanyautó-dömpinget jelentett be, elsődlegesen nekik készül.

Az a szép a fizikában, hogy ki lehet számolni a dolgokat. Tudod, ezek a fránya Mérnök Urak szeretik a számadatokat is.

Tehát vegyünk mondjuk egy szekrényni két CPU-s P4-es szervergépet: 40 gép, 80 CPU, CPU-nként 90 W TDP, számoljunk 300 W-al/gép, azaz a komplett szekrény fogyasztása 12 kW. Vegyük mondjuk 4 évet, ami egy viszonylag átlagnak mondható használat, azaz 12kW * 4 * 365 * 24h = 420,48 MWh elfogyasztott áram.

P4-ről lehetett mondjuk Core 2 archra váltani, ami úgy jó 3x-os teljesítmény-gyorsulást hozna, azaz a 40 gép helyett ~14 gép is bőven elég lenne. Ráadásul a kedvezőbb TDP értékek miatt azok beérnék 250 W/géppel is, azaz a komplett rackunk ugyanazon terhelés kiszolgálása megvan 3,5 kW-ból, 4 évre nézve 122,64 MWh-ból.

Na most kérlek, ne akard már azt nekem bemagyarázni, hogy 14 darab számítógép előállítása ugyanannyi energiát igényel, mint amennyit egy teljes paksi reaktorblokk állít elő negyed óra alatt.

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

A bökkenő pedig ott van, hogy nem elég a 14 gép, mert az ügyfél™ természetesen növekvő marketing által kierőltetett igénye™ egyre több, a szerveroldali php, python, javascript egyre bloat-abb, hosszú távon pedig egyre több gép kell.

A megawattjaidba pedig elfelejtetted beleszámolni a kínai bányászat, a gyárhoz szállítás, a legyártás, a csomagolás, a Kínából Európai logisztikai központba szállítás és az onnan Magyarországra szállítás által elpöfékelt megawattokat (vagy gigawattokat).

Kína-Magyarország számoljunk mondjuk 25000 km-rel, csak, hogy bőven legyen ráhagyás, 80 km-es átlagos utazósebességgel, és 400 kW-os teljesítményű kamionnal. 25000 km-t, 80 km-es tempóval 312,5 óra alatt tesz meg a kamion, azaz 125 MWh-nyi munkát végez. Viszont egy kamion el tud hozni 40 tonna terhet, inkább a térfogat lesz a problémás, szóval mondjuk az átlag 34 raklapból mondjuk ha egy-másfél raklapnyi árut hozunk. Szóval itt van kb. 5 MWh-ból a cucc, ráadásul az egyik legkevésbé hatékonyabb módon. (Sokkal gazdaságosabb pl. vonattal vagy hajóval.)

És akkor azt nem is számoltam bele, hogy csomó egyéb komponens hatásfoka is javult a gépekben, szóval inkább kellene egy 350W vs 200W-ot nézni.

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

1, Kína 2016-ban minimum 1500 milliárd tonna terméket exportált és majdnem ennyit importált.
2, 2016-ban eladtak ~300 millió számítógépet.

Ha a két számot elosztom egymással, akkor az jön ki, hogy minden egyes számítógépre 5000 tonna exportált és importált egyéb termék jut, vagyis egy átlagosan 5 kilogrammos elektronikai berendezésre 1000 tonna egyéb termék, minden egyes tonna számítógépre 200 ezer tonna egyéb termék.

Értem én, hogy van egy komoly berögződésed, amitől nem tudsz szabadulni és nem fogod megérteni se soha, de vannak annál sokkal nagyobb problémák, hogy három vagy 5 évente cserélsz le egy újrahasznosítható elektronikai terméket.

http://a.te.ervelesi.hibad.hu/lenyegtelen-konkluzio

Sőt, a világon számos sokkal nagyobb probléma van, minthogy Saxus Mérnök Úr Xeon-jai 6 évente kifogynak az erőforrásból, hogy elbírjanak a .NET bloat-jával. Mondjuk, hogy sokkal több embernek számítógpe sincs a Földön, mint akinek van. (Szemléltettem a jelentéktelenítést megkísérlő csúsztatásod.)

Az a helyzet, hogy nem berögzöttségről van szó, hanem egy olyan problémáról, ami egyre csak növeli és növeli az elektronikai hulladékot, a fenntartásához szükséges energiaigényt, miközben a valódi (és nem odamarketingezett) innovációs értéke az átlagfelhasználóknak szánt termékekre nézve egyre kisebb. Ugyanazokra a célokra használunk meglévő koncepciókat kiszolgáló hardvereket és szoftvereket, mégis újra és újra megvetetik velünk, a fejlesztők kényelmének és befektetőék extraprofitjának érdekében.

Pont az a lényegtelen konklúzió, amit mindenáron ki akarsz hozni a dologból. Az a tipikus fogyókúrázó vagy, aki dupla adag krumplival eszi a tripla sajtburgert, de szigorúan zero kólával.

Próbálj ki mondjuk idén egy 50 kilométeres diétát, amikor csak azt eszel, ami igazolhatóan 50 kilométeren belül termeltek meg és készítettek el, sokkal többet tennél a környezetért.

http://a.te.ervelesi.hibad.hu/a-te-ervelesi-hibad-pont-hu-oldallal-akar…

Amit te a szoftvereknél bloatként aposztrofálsz, az csak szimplán azt jelenti, hogy megnőttek a szoftverekkel szembeni igények, az emberek több feature-t akarnak a szoftvertől, nagyobb biztonságot várnak el tőle, nagyobb adattömeget dolgoztatnak fel vele, emiatt pedig a szoftvereknek komplexebbnek kell lenniük, és ez nagyobb hardverigénnyel is jár. Ráadásul ezeket a szoftvereket mindig olyan régiekkel hasonlítod össze, amik fele-negyed annyit sem tudtak, meg fele-negyed olyan gyakorisággal voltak belőle verziók kiadva (emiatt a fejlesztéssel sem kellett sietni, volt idő optimalizálni), persze hogy kisebb volt a hardverigényük. Plusz az általad preferált szoftver megoldások (XP, DivX, stb.) is bloatok voltak a megjelenésükkor az előttük lévő még régebbi szoftverekhez képest.

Amúgy még mindig amondó vagyok, hogy nyiss valami bloatságot tárgyaló topikot, mikor erre a témára ránézek, nem azért jövök, hogy a térítéseidet olvassam, hanem hogy fejleményeket tudjak meg a mostani sebezhetőségekről a kommentelők tollából is.

„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

Persze. De ne akarjunk pontosabb meteorológiai modelleket se, hogy utána kevesebb legyen a jégkár, ne akarjunk jobb útvonalkereső algoritmusokat, hogy kevesebb üzemanyagot fogyasszon minden más, ne akarjunk hatékonyabb szabályozórendszereket, hogy takarékosabb lehessen a gazdaság többi része. Ne akarjunk semmit se szimulálni, számítógéppel modellezni, hogy olcsóbb, hatékonyabb, tartósabb legyen, majd mindenki kimatekolja kockásfüzetben 10000 év alatt.

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

Az egészben az a kár, hogy te még érvelni sem tudsz.

Egyébként az egész jajajajajelboatosodik!!!!!!-ban az a szép, hogy az általad behaluzott bloatosodás mellett is vígan lehet használni egy W10-et egy régi gépen és a sok "bloatként" megjelenő időközben beépített optimalizációk miatt még gyorsabban is. Vagy szimplán vannak olyan featurek, amik korábban nem fértek bele.

Mondjuk hiába mondom, ha homokba dugod a fejed.

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

Az egészben az a kár, hogy te még érvelni sem tudsz.

http://a.te.ervelesi.hibad.hu/lenyegtelen-konkluzio

Egyfelől, nem igaz az, hogy egy W10-et simán lehet használni egy régi gépen, mert se normális driver-ek nincsenek rá, se nem bírkózik meg a régi gép a rengeteg új, felesleges feature futtatásával, tehát végső soron lassabb és használhatatlanabb lesz a gép. A Microsoft pedig sorra dobálja ki a régi hardverekre a támogatást, letiltva a frissítéseket, ugyanis a világ egyik legnagyobb szoftverfejlesztőcégének nem futja a dollármilliárdjaiból arra, hogy régi gépeken is kiteszteljék a frissítéseiket.

Őszintén szólva, én sokkal jobban örülnék, ha a PC-k és okostelefonok piacának erőltetett növekedtetése helyett értelmesebb célokra fordítanák az erőforrásokat. Például azokra, amiket felsoroltál. Több gyártói kapacitás és fejlesztési, szellemi erőforrás maradna, így sokkal inkább fejlődnek ezek a hasznos területek, mintsem Pistike új gémer gépén eggyel több poligonnal többet renderel a Far Cry, a lusta fejlesztők által belassított Office, Photoshop, Firefox, Chrome stb. pedig visszatér korábbi, újból gyors sebességére, illetve birkáék monitorján már 4K-ban mennek a kiskutyás videók, és a futószalagon forgatott CGI-ozott hollywood-i semmiértelme divatfilmek.

Jó, hogy mondod, most raktam fel. Hát, videót ugyanúgy tudok lejátszani, hup ugyanúgy megy.
Amúgy, láttad mekkora??? Van olyan, ami 600 mega! link

Biztos nem értenek hozzá, hogy így is kellett nekik pár hónap, hogy lefejlesszék. Bezzeg, ha szénné lenne optimalizálva, mint a mostani processzorok valami könnyen átlátható, és karbantartható kódban, akkor biztos nem került volna bele hiba sosem... oh, wait.

Na, látod, ezt itt cseszted el. Az a 3 darab videókártya rengeteg környezetszennyezést okozott, el kellett hozni nem tudom én hány MW-os kamionnal Kínából. Bloatware-éhséged miatt pusztul ki a környezet, mikor játszhatnál C64-es játékokkal is, nem kell ide DirectX 11 meg 12, meg HD, meg hasonló bloat megoldások. Meg különben is fogadjunk, hogy a Win10 grafikus felületét az RX480 sokkal lassabban rendereli le, mint az igen kiváló XP szoftveres GDI-s megoldása. Csak nehogy kiderüljön, hogy te is mérnök vagy, mert akkor neked annyi, mindjárt menni fog feléd a te.ervelesi.hibad link, ha nem vigyázol.

„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

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

Van egy olyan lehetőség is, hogy az x GFLOPS/kWh processzorra írunk egy jól optimalizált, natív alkalmazást, .NET-et, Qt-t és egyéb bloat framework-öket mellőzve, ami ugyanolyan hatékonyan elvégzi az adott feladatot, mint amit a lusta .NET/Qt fejlesztők írtak a 2x GFLOPS/kWh-ra.

Teljesen laikus tippem az, hogy pl. mikrokódból nem tudod befolyásolni a spekulatív végrehajtást.
Meg amit az AMD sugall, hogy ők _nem_ olvasnak pipeline feltöltéskor olyan lapról, amihez az adott processz nem férhet hozzá, ELLENBEN az Intellel, na ezt sem hiszem, hogy tudnád mikrokódból basztatni.

(De majd egy okosabb leérvel, ha tévedek.)

FYI:

http://ftp.debian.org/debian/pool/non-free/i/intel-microcode/

[ ] intel-microcode_3.20171215.1.dsc 2018-01-05 01:24 1.8K
[ ] intel-microcode_3.20171215.1.tar.xz 2018-01-05 01:24 2.1M
[ ] intel-microcode_3.20171215.1_amd64.deb 2018-01-05 01:24 1.2M
[ ] intel-microcode_3.20171215.1_i386.deb 2018-01-05 09:41 1.4M

intel-microcode (3.20171215.1) unstable; urgency=high

* Add supplementary-ucode-CVE-2017-5715.d/: (closes: #886367)
New upstream microcodes to partially address CVE-2017-5715
+ Updated Microcodes:
sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304
* Implements IBRS and IBPB support via new MSR (Spectre variant 2
mitigation, indirect branches). Support is exposed through cpuid(7).EDX.
* LFENCE terminates all previous instructions (Spectre variant 2
mitigation, conditional branches).

-- Henrique de Moraes Holschuh Thu, 04 Jan 2018 23:04:38 -0200

Kicsit az a benyomásom, hogy mindenki nyomul a peccseivel itt-ott-amott, kérdés, hogy mennyire vannak ezek összhangban egymással? Nem hiszem, hogy ez a kapkodás jóra vezet hosszú távon. Az is kérdéses, hogy ki mit és hogyan változtat, és mennyire optimális egyáltalán a kerülő megoldás?

--
robyboy

Főleg, mert az Intel oldalán az elérhető legújabb mikrokódfrissítés 20171117-es, nem tudom Debianék honnan szedik ezt a 20171215-ös mikrokódot. Plusz úgy tudom, hogy egyelőre a 4.15-os és 4.14.11-es kernel is csak a Meltdown ellen véd, a Spectre1-2 ellen egyelőre még nem.

„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

Igazából csak egy ember, aki viszi Debianéknál a mikrokódozást, ez az Henrique de Morales hosszú nevű ürge. Kötve hiszem, hogy olyan mélyen ismerné az Intel-procikat, hogy egymaga írna mikrokódot a problémára, főleg, hogy minden egyes procimodellre külön el kell készíteni és tesztelni. Sokkal hamarabb azt tudom elképzelni, hogy a fószer vagy az egyik ismerőse olyan gyártónál dolgozik, akik megkapták az új, még nem publikus mikrokódokat BIOS-hoz. Vagy kint van valahol az új kód az Intel oldalán is, csak nem a szokásos downloadcenter.intel.com-on a support cuccok között, hanem valamelyik inteles security oldalon az egyik leírásban lenyitható JS-es szakaszban van elhintve egy kósza külsős link, amit nem találok.

Szerintem a személyes összeköttetés a legvalószínűbb, mert leszedtem az Ubuntu-tárolóból kézzel azt az ucode csomagot, ami ezt a 20171215-ös frissítést tartalmazza, és már a formátumán is látszik, hogy a szokásos .dat fájlok között a 20171115-ös a legújabb, és hozzá van passzintva Debian mappában, supplementary ucode almappában néhány .fw fájl, ez lesz az új mikrokód. Csak az a baj, hogy az .fw fájokat nem tudom megetetni az Arch Linuxszal, az ottani intel-ucode csomagnak ugyan elérhető a scriptje, hogy hogyan lehet lefordítani, de azzal csak .dat-ot lehet megetetni.

„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

"hanem valamelyik inteles security oldalon az egyik leírásban lenyitható JS-es szakaszban van elhintve egy kósza külsős link, amit nem találok."

de szépen is hangzana egy ilyen, amikor épp egy ordas secu bug fixét terítjük kb mindenre, ami egy kicsit is bonyolultabb egy kenyérpirítónál.

( uid_6201 v | 2018. 01. 04., cs – 23:00 )

ARM részéről érintettek az out-of-order feldolgozósak: Cortex-A75, Cortex-A73, Cortex-A72, Cortex-A57-, Cortex-A17, and Cortex-A9.
Az ARM Cortex A15-ről nem esik szó, de tudtommal az is out-of-order feldolgozós.

Az ARM Cortex A5, Cortex A7, Cortex A53, Cortex A55 in-order architektúrák viszon tiszták. Raspberry2/3 és Odroid és sok-sok telefon és tablet ezek szerint nem igényel semmiféle bugfixet.

Forrás: https://liliputing.com/2018/01/intel-amd-arm-weigh-spectre-meltdown-sec…

( nikin v | 2018. 01. 04., cs – 23:15 )

Közelről követem az eseményeket. Bár kicsit zavaró, hogy sok mindenki mindent mond, és nagyon hiányoznak nekem a low-end CPU-k tesztjei. Modern Pentiumok, Celeron-ok, és Atomok pl. Főleg olyan tesztek, amik nem valamilyen szintetikus benchmarkot használnak.

Fejlesztőként a feladatom viszont elég egyszerű.

Holnap délután valószínűleg elkezdem a tesztek előkészítését, mivel ma már van 4.14.11 -es kernel amiben a patch benne van. Két egyforma vas, egy patchelt és egy nem-patchelt kernel. Oszt előre. Hétfőre lehet jó kis teszt-eredmény.

És lesz egy baseline számom, hogy mekkorát üt a patch. Utána lehet gondolkodni, hogy saját kódban hogyan lehet esetleg javítani a helyzeten.
így pár nap alatt rendezve lehet a Meltdown probléma. A Spectre érdekesebb kérdés. És majd elővesszem azt is, de az mélyebb tanulmányozást fog igényelni.

Az itthoni gépeimen pedig értelemszerűen frissítek(tem). Bőven van 30% tartalék minden vasamban (Pedig 2. generációs i5-ökről meg core2-kről van szó)

Szal nyugi van ;)

### ()__))____________)~~~ ########################
# "Do what you want, but do it right" # X220/Arch

Háát, a fene tudja, az első azért érdekes, bár bűzlik. A tetején az ioból két dolog következhet:
- az újabb procit sokkal jobban érinti
- a régebbiben nem a proci, hanem az ssd capelt
Azért én inkább a másodikra szavaznék

A postgresnél meg az látszik, hogy valami nagy szar van a méréssel, mert az elvileg jobb rendszer lényegesen szarabbul muzsikál.

Szóval erre a mérésre olyan nagyon nem alapoznék, de azért az io fájdalmasnak látszik.

Az utóbbi lesz, számomra elég egyértelmű. Az NVMe-s SSD-nél azért az overhead már jócskán benn van az érezhető tartományban, míg a SATA egyszerűen túl lassú hozzá, hogy a különbség kijöjjön.

Ezt a mérést Michael tényleg elég bénán csinálta. Ok, értem a tesztgépek éppen így voltak összerakva és sietni kellett / nem volt két példány egyfajta SSD-ből és csak így lehetett párhuzamosan futtatni a tesztet. De azért na, ennél összeszedettebb teszt (egyszerre 1 változó változzon csak, vagy a CPU vagy az SSD) jobb lett volna még ha később is jön ki, pláne mert mindenki erre hivatkozik.
---
Régóta vágyok én, az androidok mezonkincsére már!

( junkfer | 2018. 01. 05., p – 07:57 )

csak 1 info:

Tegnap este a parallels access használhatatlan volt (budapest-gödöllő). Ticket-nyitás, stb...
Majd éjjel megkaptam az infót, hogy Amazon nekikezdett a tárgyban jelzett sérülékenységek javításának aminek eredményeként nem csak esetemben, de több más helyről is elérhetetlenné vált a parallels access szolgáltatás.

Igen, január 4-én jelent meg. A leírásban kitérnek rá, hogy a Kernel Page Table Isolation teljesítményveszteséggel jár és, hogy letiltható a következő kernel boot paraméterrel: pti=off

Én csak apt-get dist-upgrade -el tudtam frissíteni rá, de végülis felment.

Ja, és csak a Meltdown-ra gyógyír, a Spectre foltozására még várni kell.

--
robyboy

( Adamyno | 2018. 01. 05., p – 16:42 )

Az itten a nagy kérdés, hogy Win alatt csak administrator jogokkal futó alkalmazások tudják kihasználni a rést vagy bárki/bármi? Linux alatt ugyanez. Csak root joggal megy vagy valamilyen emelt szintű/különleges jogosultság kell hozzá vagy műxik sima userként is?

( calamari | 2018. 01. 05., p – 22:04 )

"Ubuntu users of the 64-bit x86 architecture (aka, amd64) can expect updated kernels by the original January 9, 2018 coordinated release date, and sooner if possible."
Ettől mondjuk nem lettem boldog, a 9.-étől.

♲♻♲

( uid_16313 | 2018. 01. 08., h – 13:00 )

Lenovo rövid és érthetö helyzetjelentése:

https://support.lenovo.com/de/de/solutions/len-18282

There are three related vulnerability variants. All require operating system updates to address. One requires processor microcode updates (see product impact section below).

Variant 1: Bounds check bypass (CVE-2017-5753)
•Requires operating system updates
•Vulnerable to Spectre attack

Variant 2: Branch target injection (CVE-2017-5715)
•Requires processor microcode updates
•Requires operating system updates
•Vulnerable to Spectre attack

Variant 3: Rogue data cache load (CVE-2017-5754)
•Requires operating system updates
•Vulnerable to Meltdown attack

Megjegyzés: a Thinkpad T560-os firmware-e 4-én frissült, immár a szükséges microcode update-tel.

--
robyboy

( dcsaba v | 2022. 02. 01., k – 15:48 )

A The Register most arról számolt be, hogy a beadványok egy részét jóváhagyta az illetékes bíró. Az érintett kereseteket 7 olyan vásárló nyújtotta be, akik 2017 augusztusa után vették meg a processzorokat. Az összes további vásárlást az eset szempontjából nem fontosnak minősítették, mivel a vállalat abban az időszakban valószínűleg még nem tudott a problémáról. 2017 őszén azonban már más volt a helyzet, de 2018 elejéig késlekedett az információ kiadásával, hogy ne veszélyeztesse a küszöbön álló karácsonyi forgalmát. Vagyis a vállalat akkor a vásárlóknak tudatosan hibás termékeket adott el. Mindez pedig most nagyon sokba kerülhet az Intelnek. Az imázsveszteségen kívül ugyanis komoly kártérítést fizethet, ráadásul nem fogja tudni lemosni magáról azt a bélyeget, hogy a bevétele fontosabb volt, mint az ügyfelei biztonsága. Ez pedig befolyásolhatja a jövőbeli vásárlási

forrás: https://sg.hu/cikkek/it-tech/148632/felelnie-kell-az-intelnek-a-meltdown-spectre-hibakert

Azért szerintem ez nem olyan egyértelmű. Mármint nem az Intelt akarom védeni, mert szar-szemét-szutyok cég (én ennek hívom, nem profitmultinak), de ha a gyártó szempontjából gondolod végig, ha felmerül egy ilyen sérülékenység, akkor azt nem olyan evidens foltozni, mintha csak szoftveres lenne. Át kell tervezni a procit, mindent újra kell optimalizálni, gyártósorokat át kell állítani, stb., ez mind-mind idő. Persze orvosolták bizonyos szintig microcode-dal is, de az is idő, mire megcsinálják, kitesztelik, terjesztik. Ráadásul nem csak az Intel érintett. Ezt csak azért vezetem így le, hogy legyünk következetesek.

Egyébként ez a Spectre/Meltdown mizériát mai napig egy viccnek tartom. Azóta sincs kihasználva egyik sem, de jó nagy média/tech pánikterjesztésre, mesterséges elavultatásra (Win11 hardverkövetelmények) van használva csupán. Ennek ellenére én nem kapcsolom ki ezeket a foltokat, főleg Linuxon nem ajánlott, nem a biztonság miatt, hanem azóta készültek benchmarkok, amik kimutatták, hogy ezeknek a foltoknak a kikapcsolásával nem hogy teljesítményt nem nyernek, de egyenesen regresszió lesz, lassulás, mivel azóta a kernelfejlesztők egy csomó más optimalizációt ezekre a patchekre fejlesztettek rá, és ha kikapcsolja az ember bootkor a mitigations=off kernelparaméterrel, akkor ezektől az optimalizációktól is elesik.

Kikapcsolni ezeket inkább Win7-8.1-10 esetén van értelme, de ott is csak akkor, ha valami régebbi prociról van szó, Core, Core2, Core i korai generációk (1-3), esetleg Athlon/Phenom-ok, ahol a belassulás nagyobb mértékű, és a foltok tényleg sokat lassítanak, főleg, hogy windowsos vonalon nem valami jól optimalizálták. Core i 4-7. generáción, meg AMD A/FX-es procikon már nem olyan jelentős a lassulás, még újabbakon (Core i 8+ gen, AMD Ryzen-ek) meg már hardveresen van foltozva. Sok rendszeren az OS microcode-betöltő feature, vagy BIOS frissítés okán is foltozva van ezeknek egy része.

Win11-en meg megint nem éri meg kikapcsolni semmit, mert eleve a sérülékeny procik nem is támogatottak rajta, plusz a rendszer úgy van virtualizációval az ilyen sérülékenységek köré kerülőútnak kifejlesztve, hogy a futási teljesítmény így is, úgy is rosszabb lesz a bloatosodás miatt. Ezzel meg az egész probléma holtpontra van juttatva.

“The world runs on Excel spreadsheets.” (Dylan Beattie)