- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Két Zen 5-ös dizájnjának mintáit is szállítja már az AMD
- A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
- A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
Hirdetés
-
Premier előzetest kapott a V Rising
gp Napokon belül befut a teljes PC-s kiadás, az év során pedig megkapjuk a PlayStation 5 változatot.
-
Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
ph Megkezdődött az NPU-k elleni hadjárat, de egy fontos részletet nem említ a cég.
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
Új hozzászólás Aktív témák
-
XMI
csendes tag
A jelszó ennyire nyíltan nincs a memóriában,csak egy hash érték (128 bit).
Már amikor. Ne tudd meg, hány olyan trehányul kódolt alkalmazás van szerver-oldalon, ahol nem figyelnek ilyesmire. A kliens oldal még nehezebb ott általában elvileg sem tudod elkerülni, hogy átmenetileg a plaintext jelszó memóriában legyen. Legfeljebb annyit lehet (és kellene is) tenni, hogy amilyen hamar csak lehetséges, felülírja a kérdéses memóriaterületet. És akkor jönnek a menedzselt-memóriás, és immutable-változós programnyelvek, ahol hiába írod felül a string változó értékét, újat allokál helyette a régit meg kitakarítja a garbage collector... majd valamikor... (Igen, némelyik programnyelvre lehet találni - sokszor nyakatekert - secure wiping megoldást, némelyikre egyáltalán nincs) -
XMI
csendes tag
+ a cache tartalommal címezhető memória - kihasználva következtetni lehet memóriaterületek tartalmára.
Ez a rész nem teljesen pontos. A cache-nek csak egy része, az ún. tag memóriája tartalom szerint címezhető, de ez csak az adott cache line-ban tárolt adat memóriacímét tárolja (annak sem az összes bitjét - a set asszociativitás részleteibe most nem megyek bele), magát az adatot nem. A tényleges adat a cache line-ban van, ennek tartalmára (olvasási jogosultság nélkül) nem lehet következtetni, csak arra, hogy benn van-e vagy sem. A mostani támadások során valójában mindig csak a benn van/nincs benn számít, a tényleges adattartalom lényegtelen.de kihasználni nehéz,ha nincs más sebezhetőség.
Nem, sajnos ezt nagyon triviális kihasználni, és ez egyáltalán nem újdonság. Csak két összejátszó szereplő kell hozzá. Az egyik - a szivárogtató - neki van joga ill. lehetősége beolvasni a szivárogtatni kívánt adatot, annak veszi a soron következő bitjét és vagy olvas egy előre meghatározott memóriacímről vagy nem. A másik - megfigyelő - félnek csak a második memóriacímet van joga olvasni, kiméri az olvasás idejét, ha gyors volt, akkor a szivárogtató fél 1-est küldött, ha lassú, akkor 0-t. Ezzel 1 bitet kiszivárgott úgy, hogy senki nem végzett írásműveletet.Miért releváns ez: mert ha kiderült egy spekulatív végrehajtási ágról, hogy a kezdeti elágazási feltétele tévesen becsült volt, akkor az általa végzett írásműveletek eredményét törli a processzor (pontosabban egyáltalán nem is írja vissza), hiszen az egész logikailag "meg sem történt". Az olvasás műveleteknek nincs logikai hatása, azokon elvileg nincs mit törölni... kivéve az ilyen mellékhatásokat, mint a cache időzítés - és a NetSpectre esetén újdonságként - az egyes végrehajtóegységek power management állapotait. Az írás nélküli szivárogtatási technika lehetővé teszi, hogy a visszatörölt spekulatív végrehajtási ágak kommunikáljanak a külvilág felé. A te leírásodban annyi a ponttalanság, hogy "mivel a spekulatív ág nem törli maga után a regisztereket" - de igen törli.
Ami nem teljesen helyes a második felének leírásában, hogy a Meltdown esetén az Intelnél is dobna exception-t a az első - jogosulatlan - memóriaolvasás hatására, csak túl későn. A végrehajtás előredolgozik annyira, hogy a második - szivárogtató - olvasás is végre tudjon hajtódni és ez éppen elég. De ez valószínűleg orvosolható lesz jövőbeli processzorokban.
Az eredeti Spectre sebezhetőségek abból a szempontból kellemetlenebbek, hogy ott az első olvasás nem jogosulatlan, mert egy olyan folyamat szivárogtat - akaratlanul - ami rendszer normális, biztonsági szempontból jól megírt programkódjának része, nem a támadó kódja. A támadó csak olyan hibás bemenő adatokat ad neki, amit a hibakezelési elágazások amúgy megfognak, de mielőtt ez megtörténik, a processzor spekulatívan előreszaladt és megnézte "mi lett volna", ha nem fogta volna meg a hibakezelés. Ügyesen megválasztott szivárogtató "gadget" kódrészlet esetén marad valami megfigyelhető mellékhatás, amit a támadó által írt megfigyelő kód ki tud deríteni.
A NetSpectre még egyel tovább megy. Itt már sem a szivárogtató, sem a megfigyelő folyamatnak nem kell a támadó kódjának lennie. A támadó az oprendszer hálózati stackjében keres olyan részeket, amik - megfelelően formázott hibás csomagokkal etetve - finom válaszidő-eltérésekkel elárulják 1-1 bit értékét. Nyilván a kiolvasni kívánt memóriacímet a hibás hálózati csomagba kell valahogy belekódolni, hogy pontosan hova és milyen formában, az függ attól, hogy melyik protokoll-mező feldolgozó kódrészletet tudja a támadó kihasználni szivárogtatónak.
Új hozzászólás Aktív témák
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Renault, Dacia topik
- Jövő hónapban érkezik Apple eszközökre az Assassin's Creed: Mirage
- Elektromos autók - motorok
- Futás, futópályák
- Vezetékes FEJhallgatók
- Telekom mobilszolgáltatások
- Energiaital topic
- Autós kamerák
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...