- „Új mérce az Android világában” – Kezünkben a Vivo X300 és X300 Pro
- Fotók, videók mobillal
- Milliókkal olcsóbb a Model Y Standard Magyarországon
- Samsung Galaxy S25 FE - fenséges, felejthető vagy felesleges?
- Android alkalmazások - szoftver kibeszélő topik
- Google Pixel topik
- Hetekig bírják töltő nélkül a Huawei sportórái
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- One mobilszolgáltatások
- Redmi Buds 5 és Buds 5 Pro - feláron vagy féláron?
Aktív témák
-
válasz
Darth Vader #84 üzenetére
OFF
''Ha feluletesen olvasol el egy ilyen konyvet, akkor pl fel sem tunik, h az adott proci tud szegmentalni es milyen vedelemmel rendelkezik.
Sokan szerintem ugy gondoljak, h a szegmentalas elavult dolog, ezert ezt a reszt, adott esetben ki is hagyjak, at se nezik. Igy mondanak utana butasagokat.''
Arról nem is beszélve, hogy ez a legbonyolultabb része a doksinak...:)
No meg a V86-os mód...:o -
Szia!
No, itt van a kutya elásva:
''These patches mostly operate by using the x86 segmentation feature to set the code segment 'limit' value to a certain fixed value that points right below the stack frame. The exec-shield tries to cover as much virtual memory via the code segment limit as possible - not just the stack.''
Azért állítják a kód szegmens határait, mert pont az határozza meg, hogy melyik rész futhat. Ami azon kívül van, az nem. Itt tehát a patch a szegmentálást használja. Mivel nem ismerem a Linux kernelt, ezért csak tippelni tudok, hogy valószínűleg tényleg nem használ szegmenseket, ezért kellett ez a patch.
Szóval a probléma nehézsége nem abból adódott, hogy egyáltalán nehéz megcsinálni, hanem abból, hogy csak lapozással kell megoldani. Nyilván nem kellett volna a patch, ha a kernel írói is akarták volna használni a szegmentálást, mert akkor maguk implementálták volna a patch tartalmát. :)
Nem szabad elfelejteni, hogy a Linux platformfüggetlen szeretne maradni, tudomásom szerint viszont nincs másik processzor, ami ehhez hasonló szegmentálást biztosítana. -
válasz
Darth Vader #76 üzenetére
Meg lehet oldani, hogy ne lassuljon a címfordítás. A címgeneráló pl. fixen hozzáadja a bázist.
Mellesleg tuti, hogy így van, gondoljatok csak a valós módra, ott is folyton hozzá kell adni a szegmens*16-ot (ami ugye a bázis). -
Már ne haragudj, de tényleg töltsd le valamelyik x86-os (értelemszerűen 386+) processzor programmers (vagy users) guide-ját, értsd meg, majd meglátod, hogy bizony szegmentálással simán elkerülhető ez! Ha pedig arra gondolsz, hogy nem oda tér vissza a program (mert a visszatérési címet felülírta), azt ez a flag sem fogja megoldani. A nemkívánatos stack-felülírás (a visszatérési címre gondolva) csak valami állítható határregiszterekkel lenne megoldható.
OFF
Egyébként az ''i386 nagyon meghaladta a korat'' kijelentés nagyon sántít. Pl. a 68020 (ami vagy 3!! évvel korábban jelent meg) is címzett 4GB memóriát, és a 386-tal egyidőben megjelent 68030 ráadásul 1.5-szer gyorsabb is volt azonos órajelen. Persze nem volt benne szegmentálás, de cserébe egy flexibilisebb lapozás figyelt ott (az utasításkészletről már nem is beszélve). Meg, ugye, a 256 byte kód és 256 byte adat cache... -
Ez az idegen kód végrehajtásosdi inkább a system process-ekre veszélyes.
Normál esetben megfelelően reagál mondjuk egy Apache. Ekkor simán csak a neked való oldalakat tudod lekérdezni. Ha egy lekéréssel be tudod juttatni a saját kódodat, akkor olyan oldalt, Apache rendszerfile-t is megkaphatsz, amit nem tudnál normálisan.
E? -
''de előfordulhat az, hogy egy teljesen normális rutin gonosz paraméterekkel meghívva gonosz dolgot csinál. A verem átírásával (a verembe írást semmi nem akadályozza meg) ilyen módon továbbra is támadható marad a gép.''
Persze ez nem az architektúra hibája, hanem a szubrutiné. Illetve a rendszeré, ha nem azonos jogú dolgok egy vermet használnak. -
Nem olvastam még el, de én úgy tudom elképzelni, hogy csak az futhat (lap), aminek be van állítva az execute flag-je. A rendszer pedig csak a kód lapjainak állítja be. A kód lapjait meg nem lehet módosítani, mert read-only. Tehát nincs gonosz kód. Vagy valamit kifelejtettem?
-
Eleinte nekem sem tetszett (főleg az el.....-t valós módú:)). Biztonságosabbak lehetnének egy nagyságrenddel a programok. Persze ez az execute-only page is OK. Hogy miért nem csinálták meg előbb...
Egyébként a szegmensek annyival jobbak még, hogy ha a szegmens nem nagyobb, mint 1 MB, akkor byte-ra pontosan megadhatod a méretét. -
Szerintem nem lenne gáz a sel:offs típusú címzés, feltéve, hogy csak lib-enként lenne külön szegmens (máskülönben minek máshova rakni). A BSS-részüket meg egy nagy közösbe. BSS alatt értem a dinamikusan foglalt, futás alatt módosuló szegmenst.
Egyszerűen csak azért hagyták ki az op.rendszerekből, mert másik architektúra nem támogatta. Szerintem, persze... -
Aktív témák
- Autós topik
- EAFC 26
- Béta iOS-t használók topikja
- „Új mérce az Android világában” – Kezünkben a Vivo X300 és X300 Pro
- Gumi és felni topik
- SzDavid99: Van 20 perced? Akkor tanulj meg koreait olvasni!
- Házimozi haladó szinten
- Fujifilm X
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Suzuki topik
- További aktív témák...
- Intel Core i5 4440 4mag 4szál processzor garanciával hibátlan működéssel
- Intel Core i5 4590S 4 mag 4 szál processzor garanciával hibátlan működéssel
- AMD Ryzen 5 8400F - Új, 3 év garancia - Eladó!
- Intel Core i7-14700 20-Core 2.1GHz LGA1700 (33M Cache, up to 5.40GHz) Processzor
- AMD Ryzen 7 9800X3D - Új, 3 év garancia - Eladó!
- Gyors, Precíz, Megbízható TELEFONSZERVIZ, amire számíthatsz! Akár 1 órán belül
- LG 77C4 - 77" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - 1000 Nits
- Dell Precision 5560 i7-11850H FHD+ 100%sRGB 32GB 1000GB Nvidia Quadro T1200 1 év teljeskörű gar!
- 2db UK billes (146 / 147) - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4090
- Apple iPhone 13 Pro Alpine Green ProMotion 120 Hz, Pro kamerák 128 GB-100%
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest