Ha van még Intel CPU-d, érdekes lehet, bejelentés itt: https://twitter.com/_markel___/status/1373059797155778562
- 975 megtekintés
Hozzászólások
"Ha van még Intel CPU-d" - van, nagy valoszinuseggel az utolso (kovetkezo vagy ARM vagy AMD lesz, attol fugg az elobbi mennyire gyorsan fejlodik).
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
azért a zintel elég erősen bele tud kapaszkodni a windózos játékokba.
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
Az intel CPU-k egyik fele sérülékenység, a másik fele hátsóajtó. Ráadásul azt írják, hogy még user mode-ban is dekódolódnak.
Egyébként, ahogy nézem, volt előzménye a dolognak, akkor az intel azt mondta, hogy amiket ezek találtak, azok "nem jelentenek biztonsági kockázatot az ügyfelek számára"...
Viszont ez felveti a kérdést, hogy vajon ugyanilyen "feature" nem lehet az AMD és ARM CPU-kban is? Nem vagyunk előrébb a nyílt szoftverekkel, ha közben a hardware-ek, amiket használunk, zártak. Ezért van létjogosultsága pl. a POWER CPU-s gépeknek, mert ott az architektúra is nyílt.
- A hozzászóláshoz be kell jelentkezni
Ha az architektúra alatt az ISA-t érted, annak nyíltsága nem garancia semmire. Attól még lehet benne nem dokumentált utasítás, hogy a dokumentáltakat szépen végrehajtja. Amíg az implementáció nem nyílt, bármilyen extrát elhelyezhet benne a gyártó, nem fogjuk észrevenni vagy csak a jó ég tudja, mikor. Semmi nem zárja ki, hogy ugyanilyen "feature" lehet az AMD és ARM CPU-kban is. Nem is véletlen, hogy például Kínában és Indiában dolgoznak saját processzorokon, saját kiskapukkal.
- A hozzászóláshoz be kell jelentkezni
Ha az architektúra alatt az ISA-t érted, annak nyíltsága nem garancia semmire. Attól még lehet benne nem dokumentált utasítás, hogy a dokumentáltakat szépen végrehajtja. Amíg az implementáció nem nyílt, bármilyen extrát elhelyezhet benne a gyártó, nem fogjuk észrevenni vagy csak a jó ég tudja, mikor.
Nem csak az ISA nyílt, az implementációk közt is vannak nyíltak, pl. az IBM-től a referenciaként használt Microwatt és Chiselwatt, de ott a Libre-SOC projekt is.
Semmi nem zárja ki, hogy ugyanilyen "feature" lehet az AMD és ARM CPU-kban is. Nem is véletlen, hogy például Kínában és Indiában dolgoznak saját processzorokon, saját kiskapukkal.
Szónoki kérdés volt, hogy lehet-e bennük ilyen "feature".
- A hozzászóláshoz be kell jelentkezni
Bocsánat, a gondolatok felét talán kihagytam: Még ha a CPU terv elérhető valamilyen HDL-ben sem garancia arra, hogy a lapkán ugyanaz van. A gyártó simán kihagyhat a közzétett forrásból bizonyos "feature"-ket, de akár kapu szinten is bele lehet nyúlni. Ha nem ad ki mindent, ami a lapka reprodukáláshoz szükséges, továbbra is lehetséges, hogy nem pont azt kapod, amire számítasz ;)
Tudom, hogy vannak nyílt CPU tervek is, én például az OpenSPARC-al találkoztam a múltkor. De az emberiség leginkább Intel, AMD és ARM CPU-ra bízza az adatait, a többiek meg sajnos nem nagyon tudják felkavarni a vizet. Őszintén örülnék, ha ez változna.
- A hozzászóláshoz be kell jelentkezni
Ez egy valós probléma, láttam egy papert, ahol valamelyik Intel *Bridge szériás CPU-ban levő véletlenszám generátort módosították úgy, hogy elektronmikroszkóppal sem volt látható a módosítás, átment a FIPS teszten, de jóval kisebb volt az entrópiája, tehát a vele végzett titkosítás is jóval kevésbé volt erős.
Viszont ez minden legyártott chipre igaz, tehát ezt a kockázatot mindenképpen kezelni kell függetlenül attól, hogy a tervek nyiltak vagy zártak.
Edit: lehet hogy nem a CPU-ban, hanem talán a southbridge-ben...
- A hozzászóláshoz be kell jelentkezni
Bocsánat, a gondolatok felét talán kihagytam: Még ha a CPU terv elérhető valamilyen HDL-ben sem garancia arra, hogy a lapkán ugyanaz van. A gyártó simán kihagyhat a közzétett forrásból bizonyos "feature"-ket, de akár kapu szinten is bele lehet nyúlni. Ha nem ad ki mindent, ami a lapka reprodukáláshoz szükséges, továbbra is lehetséges, hogy nem pont azt kapod, amire számítasz ;)
Hát amiket felsoroltam, ott minden ki van adva, ami a lapka reprodukálásához kell. Hogy aztán aki majd ténylegesen gyártja, az nem módosítja-e sutyiban, az más kérdés, de ennyi erővel ne vegyünk semmit; alig hinném, hogy olyan kis cégeknek, mint pl. a Raptor, érdekében állna, hogy a nyílt tervekre épülő legyártott CPU-kba mindenféle köcsögséget pakoljon; mire mennének vele?
Tudom, hogy vannak nyílt CPU tervek is, én például az OpenSPARC-al találkoztam a múltkor. De az emberiség leginkább Intel, AMD és ARM CPU-ra bízza az adatait, a többiek meg sajnos nem nagyon tudják felkavarni a vizet. Őszintén örülnék, ha ez változna.
Ebben egyetértünk.
- A hozzászóláshoz be kell jelentkezni
Köszi a Libre-SOC linket, nagyon érdekes projekt. Be akartam írni a RISC-V-t, de láttam, hogy eredetileg azt akarták használni, de aztán az OpenPower mellett döntöttek a RISC-V alapítvány legkevésbé sem nyílt működése miatt...ez elég szomorú.
- A hozzászóláshoz be kell jelentkezni
Sajnos a RISC-V egyéb pontokon sem felelt meg; a Raptortól el is érhető egy kis leírás a témában.
- A hozzászóláshoz be kell jelentkezni
https://www.powerpc-notebook.org/en/
GNU tolja ezt az openhardware, open-PPC64 laptop projektet, nem látni előre hogy mikor lesz kész. havonta egyszer rá szoktam nézni.
- A hozzászóláshoz be kell jelentkezni
Ebből is látszik, hogy a húsz éve egyik tanárom által vallott zárt szoftverek/hardverek paradigmája háát nagy ....
Minden titok kiderül egy idő után. Akkor már tényleg legyenek rákényszerítve a kor tudása szerint helyes algoritmusokra és megfelelő minőségű kód írására, amibe, ha bele tudnak kukkantani, akkor se nagyon találjanak rést benne. Ne csak azért mert nem elérhető a forrás (vagy a tervek, bár lassan azok is programkódok)
Színes vászon, színes vászon, fúj!
Kérem a Fiátot..
- A hozzászóláshoz be kell jelentkezni
2018 óta semmiképp nem kéne meglepődni azon, hogy tele dokumentálatlan de felettébb hasznos utasításokkal a legtöbb CPU: https://www.youtube.com/watch?v=_eSAF_qT_FY
(Szerk.: link javítva, valamiért feltettek egy 9 perces példányt is belőle...)
(Szerk.: ... ééés egyébként 2017 és ez az előadás, de majdnem stimmel minden: https://www.youtube.com/watch?v=KrksBdWcZgQ :) )
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- A hozzászóláshoz be kell jelentkezni
2018 óta? Ezzel megleptél, mert én egyetemistaként a C64 / C+4 processzorával játszottam egy évfolyamtársammal, és pontosan azt keresgéltük, hogy a nem dokumentált processzorutasítások pontosan mit is csinálnak, és mennyire lehet azokat a parancsokat hordozhatóan használni. És a nem túl bonyolult utasításkészlet és kis számú címzésmód miatt viszonylag könnyen nagy részét ki lehetett találni - mondjuk a +4-be épített monitor program ehhez azért nagy segítség volt. (Ja, nem 2018-ban voltam egyetemista - ezt azért a számítógépek tipusából lehet sejteni.)
- A hozzászóláshoz be kell jelentkezni
Azóta semmiképp, előtte meg csak AFAIK nyilvánosan senki nem unatkozott annyira, hogy nekiálljon az x86 implementációi feltérképezésének ezen a szinten, úgyhogy tudtuk, csak épp nem sejtettük :)
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- A hozzászóláshoz be kell jelentkezni
Többek között ez a könyv is taglalta anno.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
A régi 8-bites CPU-k nem dokumentált utasításai nem szándékosan tervezett és eltitkolt műveletek voltak, hanem a CPU működési mechanizmusának fel nem derített melléktermékei. A dekóder szétbontotta az utasításokat elemi lépésekre és a nem dokumentált utasítások lényegében nem dokumentált lépéskombinációk voltak, amiknek csak egy része volt használható bármire, mert a másik része vagy stochasztikus végeredményeket produkált, vagy csak simán értelmetlen/használhatatlan volt a művelet, amit végrehajtott.
- A hozzászóláshoz be kell jelentkezni
Viszont akkor még nem volt érdekes ez, mivel holmi random (távoli) user nem injektált bele futásidőben bármiféle saját kódot. A probléma azzal van, hogy a procis eszközök az Internetnek hívott nagy és nem feltétlen békés ökoszisztéma részei lettek.
Ha van egy processzoros kakukkosórád önmagában, ott ma sem érdekes.
- A hozzászóláshoz be kell jelentkezni
Részben igaz. Elég nagy baj, hogy manapság az emberek mindenüket is a zinternetre aggatják, a kakukkosórától a hűtőszekrényen át a műfaszig mindent, de ettől még nem biztos, hogy egy internetről leválasztott eszköz biztonságban van; régen is voltak vírusok, amik az adathordozókat fertőzték össze. Nyilván egy 100%-ig szeparált, semmivel sem kommunikáló, adathordozót nem fogadó rendszernél mindegy, hogy hány hátsóajtó van benne.
A másik probléma a folyamatos generalizálódás, ahogy egyre több esetben dobják oda megoldásként a populáris megoldásokat; nem nem csináljuk meg mikrokontrollerre, mert azt drága kifejleszteni és kisszériásan gyártani, sokkal olcsóbb egy olcsó intelpécé óemvindózzal/ingyenlinuksszal...
- A hozzászóláshoz be kell jelentkezni
Erre én is emlékszem. Eddig tudtommal ez volt az egyetlen eset, ahol cáfolhatatlanul szándékos hátsóajtó (és nem csak egy "jajelbasztuk") volt valamilyen mainstream processzorban.
Őszintén, nem számítottam rá, hogy az Intelt is ilyenen fogják rajtakapni. Ok, persze ki lehet magyarázni, hogy ez bennfelejtett debug feature, de valahogy azt vártam volna, hogy 2018 január (Spectre/Meltdown szempontból vízválasztó dátum) után tartanak egy komoly házon belüli audit-ot, és becsukják az eddig ki nem derült, de security szempontból potenciálisan gázos megoldásaikat.
Persze azután, hogy kb tavaly ősz óta a mikrokódot valamelyest vissza tudják fejteni, visszamenőleg is meg lehet találni a change-ek alapján a stikában fixált sebezhetőségeket.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Hala az oktatasnak, a mai programozok egy c++ listat nrm tudnak megirni, ha nincs a magas szintu nyelvukben egy generic. Nemhogy egy undocu asm hivast... Mondjuk 7mrd emberbol eleg ha 1-10pld unatkozik.
Veszely azert van.
- A hozzászóláshoz be kell jelentkezni
Nézd a jó oldalát, legalább javascript-ből nem kihasználható (legalábbis remélem, hogy a ma használt csoda js engine-ek legalább erre nem adnak lehetőséget...)
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Csak egy vulnerability kell a browserben, ami lehetővé teszi, hogy x86 kódot injektáljon be és futtasson JS-ből és máris kihasználható. :(
- A hozzászóláshoz be kell jelentkezni
Ez az utasítás, amit találtak, mennyiben tér el attól az utasítástól, amivel az új mikrokódot tölti fel a Linux kernel a CPU-ba?
- A hozzászóláshoz be kell jelentkezni
oda csak signed mehet fel, vagyis nem tudsz belenyúlni, szemben a mostanival ami gyakorlatban bármit enged, akár userspace-ből is különleges jogosultság nélkül
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Az szerző azt írja, hogy - szerencsére - nem teljesen így van:
https://twitter.com/_markel___/status/1373059799307390981
They're decoded in all modes (even in User Mode) but the ucode in MSROM throws #UD if not in Red Unlocked state.
Persze Meltdown óta tudjuk, hogy az ilyen "decoded but throws XY trap" védelmek nem feltétlen megkerülhetetlenek. Szóval tartok tőle, hogy jön itt még kutyára úthenger.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Most nem is tudom, hogy azt írjam-e, hogy ennek sosem lesz már vége, vagy azt, hogy ezek semmiből sem tanulnak.
Fasza.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
- A hozzászóláshoz be kell jelentkezni
Amíg ott a ME addig igazából teljesen mindegy, hogy a CPU amúgy mit művelne :)
- A hozzászóláshoz be kell jelentkezni
És a valóság már megint (nagyon sokadszorra) a "hülye, idealista, papoló, valóságtól elrugaszkodott, erkölcscsősz" Richard Stallmant igazolja. Jó tudni, hogy visszatér, remélem, ő nem alkuszik meg. =)
- A hozzászóláshoz be kell jelentkezni