Hirdetés
- Szénszál és réz találkozik az Inno3D egyslotos RTX VGA-in
- Vezetékmentes és kompakt gaming klaviatúra a Cherry Xtrfy védjegyével
- Cserélhető filtereket biztosít az Elgato legfrissebb, 4K-s webkamerája
- A YouTube-ot is betiltják a gyereknél az ausztrálok
- Gyilkosságban és öncsonkításban akart segíteni a ChatGPT
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
Új hozzászólás Aktív témák
-
lenox
veterán
Ahogy en ertelmezem 2 modon lehet lopni a biteket:
1. A negyzetreemelest masik koddal oldja meg ez a proggy, mint a szorzast, mert az picit gyorsabb. A mas kod mas cache hozzaferest eredmenyez - ezt lehet detektalni. Megoldas: a pici sebessegkulonbseget bealdozod, es ugyanazzal a koddal emelsz negyzetre (onmagaval szorzol), mint szorzol.
2. A szorzashoz hasznalt egyutthatok egy tablazatban vannak, es hogy melyiket olvassa ki a proggy azt lehet detektalni. Ez azert van, mert az A es B egyutthato bytejai igy vannak a memoriaban: A1, A2, A3, ... B1, B2, B3. Szal ha kiolvasod A-t, akkor a cache hasznalatbol tisztan latszik, hogy honnan olvastad ki. Megoldas: a byteokat ugy kell a memoriaban tartani: A1, B1, C1, D1, ... A2, B2, C2 stb. Igy megintcsak lassabb a kod, de A kiolvasasa ugyanazokat a cacheline elereseket jelenti, mint B kiolvasasa (illetve C, D stb), szal nem tudod megmondani, hogy melyik volt amit olvasott a proggy.
En ennyit olvastam ki a pdf-bol, ezekre a fenti megoldasok szerintem mukodnek. Hogy lehet meg mashogy megszerezni a kulcs bajtjait? Szerintem csak igy, de lehet, hogy kihagytam valamit... -
lenox
veterán
Ha jol ertem, megfelelo programozassal siman meg lehet oldani ezt a problemat. Szal ha pl. nem folytonosan vannak az adatok a memoriaban, hanem byteonkent interleave-elve (kvazi transzponalva), akkor a kiolvasasuk is vegigmegy az egesz cache-en, szal akkor nem lehet kifigyelni, hogy melyik line-bol olvastunk adatot. Nyilvan igy valamivel lassabb lesz a kod, de megszunik ez a problema. Mondjuk az igaz, hogy ehhez vegig kell az osszes programot analizalni, hogy letezik-e ez a problema az adott programnal, es ha igen at kell irni, ez eleg sok munka, es ehhez nem mezei programozok kellenek - draga mulatsag...
-
molnarcs
tag
Átfutottam a topikot, néhány válasz:
Miért kell kihirdetni?
Colin Percival a lehető legetikusabban járt el. Nem csak úgy fogta magát és jól megmondta, hanem kapcsolatba lépett az összes szakemberrel amikor már volt kézzelfogható bizonyítéka. Például, az Intelt is értesítette korábban, valamint azokat az RSA/crypto szakembereket akik érdekeltek a témában. Sőt, úgy tűnik, hogy a kriptósok már épp készültek egy hasonló kaliberű támadás leírásával CP-től teljesen függetlenül.
Egyébként a faszi nem csak comitter, ő a FreeBSD Security Officer, azaz a biztonsági csapat vezetője. Hozzáteszem, hogy 19 évesen szerzett programozói diplomát, és most 23 évesen egy OXFORDI Ph.D. várományosa - nem semmi fickó.
Ami a veszélyeztetettséget illeti - nyilvánvalóan ez a kör elég nagy. Minden olyan szolgáltató, aki ssh hozzáférést biztosít, gyakorlatilag érintett lehet. Valaki írta hogy nemsokára megjenhetnek példák arra, hogy miként lehet ezt kihasználni. Nos, a 12 oldalas pdf eleve tartalmaz egy proof of concept leírást! Viszont hangsúlyozom, hogy az Intel értesítve lett korábban is, nem beszélve arról, hogy CP szólt a prezentáció előtt, hogy lesz egy bemutató, és addig is amíg ez nyilvánosságra kerül, ha lehet akkor az érintettek kapcsolják ki a HT-ét. Ezenkívül a 12 oldalas prezentáció nem csak a hiba leírását, hanem annak orvoslására tett javaslatokat is tartalmaz, mind oprendszer szinten, mind pedig chip design szinten (!) - mint említettem, ez a fickó tudhat valamit
-
Raymond
titán
''A virágzás valószínű 2 dologgal van összefüggésben. Az egyik az ár, a másik a hozzáértés.''
Nem teljesen vilagos elottem hogy a ''hozzaertes''-t pozitiv vagy negativ ertelembe vegyem itt, igy nem tudok erdemben valaszoni (feleslegesen nem gepelek).
''De szerintem ahol komoly a feladat, ott többnyire mindkettő megvan, így oda nem raknak x86 -ot. (most komoly feladat alatt nem egy oriási webserverre gondolok... )''
Ez szerintem elegge szuklatokoru megkozelites. Mindenkinek mas mast jelent a ''komoly feledat''. Most mar ertem az elozot is, tehat a ''hozzaertes'' negativ ertelemben volt. Tartottam ettol
Megint csak a lenyeghez terunk vissza. Egy feladathoz amelyhez teljesen megfelel egy X86 alapu szerver ahoz valaki miert vegyen egy feleslegesen dragabb nem X86 alaput ?
''Egyébiránt nem értem hogy keveredett ide az Apple, meg a Mac.''
Nezd meg kinek valaszolgatnak itt az emberek a legtobbet es rajossz -
atus33
tag
Beleolvastam a doksiba, valósnak tűnik a kifogás, ezzel tényleg el lehet más program által éppen feldolgozott adatokat lopni! Leginkább ahhoz hasonlítható, mint amikor egy chipkártyát mágneses mező mérővel figyelnek működés közben, hogy rájöjjenek, hogyan működik és milyen elemi műveleteket végez -- hogy feltörhessék. A chipkártyák gyártói ez ellen úgy tudnak védekezni, hogy zavaró műveleteket is végeztetnek a chippel. Ami ott el is megy, de egy ugyanilyen a processzort viszont lelassítaná, vagyis pont közömbösítené a Hyperthreading előnyét! Az Intel ezt a problémát nem fogja tudni megoldani architekturális változtatás nélkül, ha feltételezzük, hogy bármilyen kód debuggolható (ami igaz).
A hiba egyébként bármilyen olyan processzor-architektúrának jellemzője, amely az Intel HT-hez hasonló módon osztja ki a szálaknak az erőforrásokat.
Szerintem nem jó érv, hogy kicsi a gyakorlati valószínűsége a hibának. A bűnözők pont az ilyen 0.001% hibalehetőségeket használják ki. Vagy lehet, hogy már ki is használták. A Netes felmérések szerint az Internetre kapcsolt gépek több mint fele trójai programokkal fertőzött (mindez windows update-n keresztül automatikusan érkező m$ antispyware és ingyenes vírusirtók ellenére!). Ha egy ilyen HT-t kihasználó trójai elterjedne, és hozzá tudna férni pl. a HTTPS forgalomhoz, az annyira GÁZ, hogy még akár az Intel is azt fogja javasolja a usereknek, hogy inkább tiltsák le a HT-t Az AMD-nek mostanában kellene elhatárolódni a ''HT''-től, amely véletlenül a ''HyperTransport'' rövidítése is. És persze az is számítani fog, hogy mekkorára fújja fel az egészet a média. -
taltos
senior tag
A virágzás valószínű 2 dologgal van összefüggésben. Az egyik az ár, a másik a hozzáértés.
De szerintem ahol komoly a feladat, ott többnyire mindkettő megvan, így oda nem raknak x86 -ot. (most komoly feladat alatt nem egy oriási webserverre gondolok... )
Egyébiránt nem értem hogy keveredett ide az Apple, meg a Mac. Ha már ezeknél tartunk, amiknek az alapja a PPC, akkor már inkább az IBM-ről kellene beszélni, nem? -
-
747
senior tag
''Ilyen jók azok az Apple gépek?''
egy szoval nem mondtam, hogy Apple gepet hasznaljon szervernek barki is, bar az utobbi idoben jo sok XServe-et eladtak.
http://www.apple.com/xserve/
termeszetesen olyan cuccokra celoztam, mint a Sun Fire, vagy a HP PA-RISCes Enterprise szeriaja. Sun legujabb cuccai pl olyanokat tudnak, hogy a sima gigabites halokari mellett van egy DEDIKALT halokari, ami mogott egy RS232 konverter ul, es REMOTE BUZERALHATOD A FIRMWARET!! ha valoban 100%os uptime-ot kell garantalnod, akkor az ilyen feature-ok elengedhetetlenek, ehhez kepest egy linuxszal/windowszal felszerelt P4es/Athlonos PC egy ovodai toy.
''Kb 5 éve ültem utoljára apple előtt de az nagyon lassú volt''
OS9 suxx.
latogass el valamelyik dealerhez es gyozodj meg magad hogy mit tud a Mac es mit nem:
http://www.xms.hu/
http://www.macbolt.hu/
hogy csak kettot emlitsek a jobbak kozul -
Raymond
titán
''Talán nem ártana a Pentium M vonalra ráfeküdni és azt fejleszteni tovább.''
Ezt mar regen eldontottek, csakhat nem olyan egyszeru kozolni a nagyerdemuvel a sokeves P4 agymosas utan. A tervek a tavalyi IDF utan is mar vilagosak voltak annak aki olvas a sorok kozt, egy ev telt el mire ezt hivatalosan is ''bevallottak''.
Bővebben: link -
rudi
nagyúr
Azon a magasabb szinten amit Te emlegetsz nem nagy befolyása van egy asztali rendszereknél vagy legfeljebb kisebb szervereknél esetleg jelentkező hibának. Azon a szinten nem budget processzorokban gondolkodnak. A korábban linkelt pdf-ben többféle javítási módszerről is szó van.
-
BluEyes
őstag
Azt hiszem, nem értitek ennek a biztonsági hibának, és általában a sebezhetőségnek a valódi veszélyeit. Az, hogy 12 éves kölkök meghekkelik az otthoni gépünket, mindössze lokális kellemetlenség, a konrét júzer persze dühöng meg anyázik, de igazán komoly következményekkel nem jár egy ilyen betörés, még a bankkártya adatainak a lenyúlása is csak személyes probléma, az áldozaton kívül mást nem igazán rendít meg.
Azonban van az információszerzésnek egy magasabb, számunkra láthatatlan szintje, ami -bár közvetlenül nem találkozunk vele- sokkal nagyobb befolyást gyakorol a mindennapjainkra, mint holmi kiscserkészek gonosz kis tréfái. Konkrétan a nemzetbiztonsági szolgálatokra, a katonai hírszerzésre, meg az ördög tudja milyen célok és érdekek szolgálatában álló titkos szervezetekre gondolok. Jót somolyogtam a ''mé nem atta el a zintelnek'' ötleteken, a Moszad vagy a KGB a többszörösét fizette volna. Az ember a legjobb megoldást választotta, amikor nyilvánosságra hozta a hibát, így legalább minden érdekelt tudja, hogy luk van a falon.
Ja igen, nincs üldözési mániám, már megszoktam, hogy követnek. -
#77
djyuri
őstag
Zordkaszás
#75
djyuri
őstag
válasz
Zordkaszás
#75
üzenetére
Én is egy nagy hálózati cuccost akarok a család és a haverok között......
-
_seth_
veterán
De ezt minek kell kihírdetni?????
Ugye eddig nem tudták (mi legalábbis nem tudtuk) de most már minden rosszindualtó user tudja ez a hülye meg még be is mutatja mindenkinek....
Ha lett volna esze küld egy okos kis mailt az Intelnek, az vissza pár milla $$$-t javítják/vagy nem a hibát és letudva a dolog.
[Szerkesztve] -
steveetm
őstag
Ez mondjuk azért így érdekes. Mondjatok már nekem egy ma használt egy felhasználós rendszert.
Az ok hogy te winbe(linuxba stb) mindig ugyanazzal a userrel jelentkezel be, de fut ott azért még néhány progam egészen más felhasználóval(jogokkal). És nem csak egy RSA kulcs megszerzése érinthet kellemetlenül egyeseket...
Üdv.: steveetm -
WN31RD
addikt
Szerintem - talán a korábbi ''sérelmek'' hatására egyébként érthető módon - túlreagálod kicsit a dolgot. Egyébként nyugodtan kérj meg egy másik moderátort, hogy nézze át a topicot, ha úgy gondolod, hogy van még moderálni való.
Ezt viszont folytassuk inkább máshol (már ha van még mondanivalód), mert itt nagyon OFF. -
Egon
nagyúr
A 3. pont valóban kimaradt: melléütöttem.
Arról van szó, hogy van egy adott hír (amiből perpill messzemenő következtetéseket nem lehet levonni - de azért megjelenik _menetrendszerűen_ a sok ''dögevő'', és osztja az észt/flémel orrba-szájba - vagy legalábbis finoman fogalmazva sem konstruktív. Ez persze nem moderálandó...
-
WN31RD
addikt
1. Nem állítottam, hogy nem tartalmaz érdemi részt a hozzászólásod.
2. Te személyeskedtél vele szemben, míg ő nem személyeskedett.
(3.?
)
4. Ez egy nyilvános fórum, amit sokan olvasnak. Itt egyáltalán nincs helye a korábbi sérelmek felemlegetésének, akkor sem, ha az egyébként emberileg érthető és jogos lenne (nem foglalok állást abban a kérdésben, hogy kinek van igaza, és itt és most jogos lenne-e).
Ha problémád van valakivel, akkor beszéld meg vele lehetőleg privátban, vagy ha ez nem lehetséges, akkor ott helyben, ahol a probléma felvetődött, vagy valami ring topicban. De ne csinálj mindenütt ring topicot! -
WN31RD
addikt
Ha jól értem, - a szokásos covert channel mókán kívül, ami kevésbé érdekes - a P4-en HT segítségével párhuzamosan futó processzek információt szerezhetnek egymás memóriaeléréséről annak következtében, hogy osztoznak a processzor L1 cache-én. Amennyiben az egyik processz pl. az OpenSSL segítségével RSA kulcsokkal végez műveleteket, akkor, mivel a számításokhoz viszonylag sok különféle átmeneti érték van szétdobálva a memóriában, ezzel a módszerrel akár az RSA kulcsok tartalmáról is lehet információt szerezni, elvileg eleget ahhoz, hogy abból könnyen visszafejthető legyen az egész kulcs.
(Saját kommentár: A példában 1024 bites RSA szerepel, nem tudom, mennyire alkalmazható a módszer nagyobb kulcshossz esetében, illetve továbbfejleszthető-e ahhoz. Kérdés még, hogy egy valós rendszerben, a párhozamosan futó igen sok processz ''zaja'' mennyire zavar be, és egyáltalán valós környezetben működik-e ez a fajta kémkedés.)
Megoldási javaslatokat is ad:
- nincs HT, illetve le van tiltva ()
- végrehajtási szálanként külön L1 cache
- módosított cache ürítési stratégia (nem részletezem)
- az operációs rendszer ütemezője csak egy privilégiumszinten levő processzeket ütemez párhuzamosan egy processzoron
- alkalmazás szinten a kritikus kódokat átírni olyan módon, hogy a memóriaelérések (beleértve a kód végrehajtását is) ne adjanak információt a feldolgozott adatról
Röviden ennyi. Ha valamit elnéztem, javítsátok ki. -
Egon
nagyúr
1. Akkor nézd a középső bekezdést - az érdemi részt is tartalmaz.
2. Nem látom be, hogy kevésbé lettem volna destruktív, mint fent nevezett egyén: pl. Chipzilla ekvivalens Microfos-sal, amit már többen kifogásoltak, mint megjelölést. Mennyiben volt konstruktív a hozzászólása?!?
4. Fent nevezett egyén hozzászólásait nem bírom a korábbi hozzászólásaitól függetlenül vizsgálni - ennek tükrében még kevesebb kivetnivalót látok a saját hozzászólásomban...
[Szerkesztve] -
WN31RD
addikt
válasz
Scream007
#48
üzenetére
Ha van valami értelmes hozzáfűznivalód, pl. ellenérved, akkor azt írd le. De ha lövésed sincs a témához, akkor inkább hallgass, és főleg ne írj ilyen hülyeségeket.
Az ilyen stílusú hozzászólásokat a továbbiakban törölni fogom.
Szerk.: Meggondoltam magam, ezt is töröltem. Scream007, ezt vedd figyelmeztetésnek. -
Egon
nagyúr
Miért is vehettem biztosra, hogy (többek között) hobizoli megjelenik ebben a topicban, és ''elélvezésközeli'' hozzászólást eszközöl?!?
Na mindegy.
Gondolom, a ''lokális user'' kitétel nem szúrt szemet senkinek... Komoly rendszerekben minden logolva van, és létezik Informatikai Biztonsági Felügyelő, illetőleg informatikai biztonsági ellenőrzés is...
Nyilván az _elterjedtebb_ rendszerek hibái jönnek ki előbb (azaz még mindig baromira savanyú a szőlő, lásd piaci részesedés...
(ha mág ez hobizoli kedvenc szmájlija, akkor alkalmazzuk ahol lehet); illetve kíváncsi lennék, hogy a hírben szereplő üzletember bankszámláján melyik (konkurens) chipgyártó komoly összegű átutalása realizálódott a közelmúltban (vagy fog a közeljövőben?!? Láttunk már ilyet). -
orbano
félisten
Szerintem itt sem az igazi biztonsági résen lesz a hangsúly, hanem az Intel hírnevén. Akár van alapja, akár nincs, a köztudat hamar megjegyzi, hogy HT = támadhatóság... Azt hiszem ez sok táska pénzbe fog kerülni az Intelnek.
Az meg nem olyan egyszerű, hogy kapcsolja ki a rednszergazda a HT-t és kész. Elvégre sokszor töbletteljesítményt jelent a HT, a kikapcsolt állapothoz képest, amiből egy szerver könnyen profitálhat, főleg egy töbfelhasználós rendszerben... Ez olyan, kicsit kisarkítva, mint ha azt mondanák, hogy kapcsold ki az AMD-ben az SSE/2/3 utasításkészlet-bővítéseket mert bugosak... (nem mint ha ki lehetne kapcsolni ) -
#41
Zordkaszás
senior tag
Zordkaszás
senior tag
Tudtam én, hogy nem kell nekem HT, marad az amd csak 64 bites lesz
-
X-COM
nagyúr
időközben felkerült egy pdf
Bővebben: link -
Szőrös
veterán
kicsit figyelmesebben tessék elolvasni :
''Percival azt tanácsolja a többfelhasználós rendszerek adminisztrátorainak, hogy kapcsolják ki a Hyper-Threadinget – egyfelhasználós gépeket azonban nem érint a hiba.'' tehát a szimpla usert nem igazán érinti.persze ettől függetlneül még sokaknak kellemetlen lehet a hír. -
steveetm
őstag
azért remélem az érezhető hogy nem egy ''hello world'' szintü programozói tudás szükséges egy ien hiba kihasználásához, és nem is kicsit kell ismerni az adott technológiát. Nem kell ezen meglepődni hogy most jött ki.
anno a f00f bug is talán 2 évvel késöbb derült ki, de az tuti hogy asse rögtön
Üdv.: steveetm -
Adi
senior tag
Ez a ''leáll a fél net'' azért túlzás, de a dolog valóban komoly lehet. A Xeonokban mér régóta van HT, még az asztali P4-ek előtt megjelent és bizony nagyon sok szerverben Xeon pörög. Persze ebből elég sokat nem érint a dolog, amin pl. nincsenek felhasználók, csak vmi zárt funkciója van, de a maradék is elég szép mennyiség.
Megjegyzem, hogy az Intelre az utóbbi időben nagyon rájár a rúd, mégha a mérete miatt ez az eladásokban (egyelőre még) nem is jelentkezik. Az Opteronok már egy jó ideje gyorsabbak, mint a Xeonok, a többprocis rendszereken ez a különbség még jobban kibukik (dedikált Hypertransport kapcsolat vs. közös memóriabusz), hamarabb tudtak 64 bites üzemmódot, kevesebbet fogyasztanak. A kétmagos Opteronok fogyasztása a második magtól elhanyagolható mértékben emelkedik csak, a Xeonoknál viszont jelentősen megnő, ráadásul úgy, hogy amúgy is magasabb volt. Pluszban most még ez is.
Talán nem ártana a Pentium M vonalra ráfeküdni és azt fejleszteni tovább. -
X-COM
nagyúr
hmmmm, mér telt el ennyi idő a felfedezés és a parázás beindulása között?
Bővebben: link
Late October, 2004: Initial discovery.
December 2004: Proof-of-concept exploit written and tested.
December 31, 2004: FreeBSD Security Officer Team notified of upcoming security issue.
February 2005: First draft of paper completed.
February 27, 2005 - March 18, 2005: Other security teams contacted.
May 13, 2005 @ 00:00 UTC: Official public disclosure that a security flaw exists in Hyper-Threading.
May 13, 2005 @ 15:00 UTC: Full details to be released. -
#11
killahdrums
senior tag
anulu
#4
-
#4
anulu
félisten
killahdrums
#2
anulu
félisten
válasz
killahdrums
#2
üzenetére
egy topicot nem szeretek flame gyanús beszólással indítani
-
#2
killahdrums
senior tag
killahdrums
senior tag
...én erre csak annyit, hogy lol!
Megint csak a lenyeghez terunk vissza. Egy feladathoz amelyhez teljesen megfelel egy X86 alapu szerver ahoz valaki miert vegyen egy feleslegesen dragabb nem X86 alaput ?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Intel Xeon W3505 2.53GHz LGA1366 Server
- Intel Core i7-14700K 20-Core 3.4GHz LGA1700 (33M Cache, up to 5.60 GHz) Processzor! BeszámítOK
- 27% Számlával! Intel Core i7-7700K 4.2GHz (8M Cache, up to 4.50 GHz) LGA1151 Processzor
- AMD Ryzen 5 5500 - Új, 3 év garancia - Eladó!
- AMD Ryzen 5 5600 - Új, 3 év garancia - Eladó!
- Bomba ár! Lenovo ThinkPad Yoga 260 - i5-G6 I 8GB I 256SSD I 12,5" Touch I W10 I Cam I Gari!
- Bomba ár! Dell Latitude E6530 - i5-3GEN I 4GB I 500GB I HDMI I 15,6" HD+ I W10 I Garancia!
- Lenovo IdeaPad 3 17ITL6 - 17.3" HD+ Intel 6305 - 8GB - 256GB SSD - Win11 - MAGYAR
- Honor 200 Smart 256GB Kártyafüggetlen 1Év Garanciával
- Bomba Ár! Lenovo ThinkPad P71 - i7-7820HQ I 64GB I 512SSD I FHD I Nvidia 6GB I W11 I Cam I Garancia