Új hozzászólás Aktív témák

• #93 747 senior tag X-COM #54

  Új Válasz 2005-05-14 16:04:11 #93

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  747

  senior tag

  válasz X-COM #54 üzenetére

  ''köszönöm, akkor ez így egyelőre egy elméleti lehetőségnek tűnik.''
  
  megbocsass, de a cikkben kozolt asm kurvara nem elmeleti.
  
  jmp article
  mov brain, info
  
  

• #57 WN31RD addikt X-COM #54

  Új Válasz 2005-05-13 21:49:37 #57

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz X-COM #54 üzenetére

  Kérdés, hogy ez-e a maximum, amit ebből ki lehet hozni, vagy ez csak az első kis lépés, és csak most kezdődik majd igazán az ilyen irányú ''fejlesztés''...

• #53 WN31RD addikt X-COM #45

  Új Válasz 2005-05-13 21:38:42 #53

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz X-COM #45 üzenetére

  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.

• #23 steveetm őstag X-COM #20

  Új Válasz 2005-05-13 16:05:46 #23

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  steveetm

  őstag

  válasz X-COM #20 üzenetére

  Sztem pont azért mert nem akartak fölöslegesen paráztatni. De majd úgyis kiderül.
  Üdv.: steveetm

• #21 Adi senior tag X-COM #13

  Új Válasz 2005-05-13 15:55:59 #21

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Adi

  senior tag

  válasz X-COM #13 üzenetére

  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.

Új hozzászólás Aktív témák