[vitaindító] Hello Mr. Harvard. Gondoljuk újra.

Mára szinte mindennapossá váltak az ilyen-olyan oprendszereket érintő sebezhetőségek és nagyon úgy tűnik, hogy ezzel meg kell tanulnunk együttélni. A számítástechnika, pontosabban a hardver fejlődésének egy korábbi állapotában két fő irányzat fejlődött ki  A Von Neumann és a Harvard architektúra. Számszerűsítve a dolgot, a Neumann lett az abszolút nyertes. A Harvard csak az iparban, a nagy biztonságot igénylő rendszerekben tudott teret hódítani, a PC-k, palm eszközök világában nem. Pedig, az elvet mindenki ismeri. A memória két fő szegmentumra oszlik. Az egyikben a futtatandó kód, a másikban az adat. Így nem fordulhat elő, hogy adat formájában becsempészett kódra kerül a vezérlés. Jó, tudom-tudom, létezik módosított Harvard, de nem ez a lényeg. Hanem ez:
 

Úgy érzem, talán rossz útra léptünk.
Csak menetelünk befelé egy erdőbe, ahonnan annál keservesebb,  hosszabb lesz a kiút, a visszaút, minél mélyebben leszünk a rengetegben. Akkor, amikor a helyzet tarthatatlansága okán a visszafordulás mellett döntünk, majd, valamikor.

Ma már, túl a sokezredik wormon, víruson, exploiton, egyéb kártevőn, talán érdemes lenne ezt az egész architekturális kérdést újragondolni.
Ennek a gondolatnak, mint próbacselekvésnek a premisszáira, és esetleges következményeire - ergo, mások véleményére - lennék kiváncsi. Előnyök, hátrányok, a dolog kivitelezhetősége, anyagi, vagy egyéb vonzata. A meglévő kódbázisokra kifejtett hatás, satöbbi, bármi.

"Fecseg a felszín, hallgat a mély"

Írta József attila.

Ez egy vitaindító.
Adjon bele minden hozzászóló apait-anyait. Ne csak a felszín fecsegjen, kapjon szót a mély is. Rajta hát. Írjunk, olvassunk, a téma adott.

Hozzászólások

Szerkesztve: 2021. 04. 27., k – 16:21

Elvileg pont erre a problémára lenne már lassan húsz éve a DEP. Az amúgy miért nem elég jó? Ha jól értelmezem a működését a lapok megjelölésével pont ugyanazt csinálja, mint egy Harvard CPU esetén, a megjelölt lapokban levő kódot nem lehet futtatni. Igaz sosem mélyedtem el a működésében, de 64 bitet tudó x86 procikon kötelező.

Szerkesztve: 2021. 04. 27., k – 16:44

Darabra Harvardbol sokkal tobb van. Szinte az osszes mikrokontroller ilyen, nem is lehetne mas, mert a kod flashen van, az adat meg RAMban.

PC oldalon meg a vedett modnal mar volt olyan (talan 386-tol), hogy a kodszegmens vagy csak futtathato, vagy olvashato is (irhato nem lehet), adatszegmens meg vagy olvashato, vagy olvashato es irhato. Kulon bit van erre hardware-szinten. Persze ha fizikailag ugyanarra a memoriara van mappelve, akkor tudod irni a kodot. Illetve a HDD/SSD szinten ugyanazon az eszkozon van az adat es a program.

szerk: Ja, a masik, hogy PC-n/weben nagyon sok dolog valamilyen scriptnyelven van. Ott a "kod" nem is lehetne a kod helyen, mert kvazi az adat fut.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

A hardveres lapvédelmet senki nem használja. Meg is van az oka.
A háttértár még hagyján, bár nyilván azt hackelnék akkor. Az adat és a kód a Neumann architektúrán is elkülönül, eredendően. Ezért lenne jobb a hardveres védelem. Azzal nem tudnának mit csinálni. A ROM az ROM. 

Amúgy, most eszembe jutott valami. Mi volna, ha a HDD-t fizikailag lehetne lockolni, Read onlyvá tenni? Mint régen a floppy diskeket. Az írása egy más, körülményesebb úton valósulna meg. Úgy legalább azt el lehetne érni, hogy a fertőzés a gép kikapcsolása után megsemmisüljön.

Csak sajnos a verziófrissítések is interneten keresztül történnek ma már. Erre utaltam az egyre sűrűbb erdő hasonlattal. 

Ezért lenne jobb a hardveres védelem. Azzal nem tudnának mit csinálni.

Aha persze. Lásd: Meltdown. Itt az amúgy jól definiált hardveres védelem volt az, amiről kiderült, hogy valójában csak papíron létezik az Intelnél... mert valamivel le kellett nyomni az AMD-t teljesítményben.

Másrészt: olyan nem nagyon lesz, hogy tökéletes hardveres védelem, mert pl. az NSA tesz róla, hogy ilyen ne lehessen. Lásd Intel ME, és ennek AMD megfelelője. ARM oldalon nem kell ezzel pöcsölni, mert azok nagyrészt mobilokba kerülnek, ott pedig a baseband CPU-nak teljes hozzáférése van mindenhez, legalábbis az amerikai Qualcomm-nál. A kínai csipekben kínai backdoor van...

Pedig nagyon is igény van arra, hogy adatból legyen kód - a JIT compilation. Amikor is futásidőben készül el a gépi kód, adatként.

Nem csak a Java csinál JIT-et. Bármelyik scriptnyelv is. De még a Linux kernel is (eBPF: https://ebpf.io/ ).

 

De mondok más: reguláris kifejezés kiértékelés. Ezt is hatékonyan, gyorsan JIT-elve lehet megtenni. 
https://pcre.org/original/doc/html/pcrejit.html

Pár kérdés:
Hogyan különbözteted meg mi a programkód és mi az adat a háttértáron?
Hogyan biztosítod, hogy a háttértáron ne lehessen módosítani a programkódot?
Hogyan lesz program kódból adat és adatból kód biztonságosan? Pl. Van egy kódod amit be akarsz tömöríteni. Akkor az adat lesz és nem kód. Mikor előállítasz, fordítasz egy programkódot, akkor a fordító adat kimenete programkód.
Ha OS szinten átjárható a két terület, akor hogyan akadályozod meg, hogy ide-oda ne történjen szivárgás?

Ugyanezt elérheted nem Harvard architektúrán is sima szigorú objektum orientált szemlélettel. Egyszerűen annyi kellene, hogy minden programod egy szigorúan szabályozott, zárt területen tevékenykedjen, szigorúan szabályozottfeltételek mellet. Mi lenne az ára? Kegyetlenül lassú lenne.
 

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Remek kérdések.

A háttértáron nincs jelentősége, mert az, tegyük fel, hogy read only. A betöltés során "válik ketté" a kód. 

Hardveres biztosítás lenne megfelelő. Minmt írtam, ahogy anno a floppyk írásvédelme működött.

Tömörítés ma már nem bír akkora jelentőséggel, hiszen a kódon érdemben nem tud kompresszálni semmi, az adat meg amúgy is tömör [.mpeg,.jpeg], ha annak egyébként van is értelme.

Szivárgás azért nem lenne, mert a tiszta kód és adat a háttértéron foglalna helyet. A betöltés után meg fizikailag elkülönülne.

Az utolsó bekezdésedet nem értem helytállónak. A vírusok terjedése ellen ma is megvan oprendszer szinten a védelem. A memória kezelése, stb. De nem ér sokat. Amint azt tapasztaljuk is. Elvileg nem történhetne ennyi gond, de mégis történik. Most is szigorúan szabályozott feltételek vannak, nem lehet csak úgy, ezt vagy azt tenni. Létezik hardver védelem. Bizonyos utasításokat az oprendszer eleve tilt. Mégis van gond elég.
 

Read only háttértár nem túl praktikus egy mindennapi számítógépnél. Plusz ami írható, az módosítható is.
Arról nem beszélve, hogy a használhatatlanság netovábbja lenne egy olyan számítógép ahol a programkódok ROMból futnának az adatoké lenne a RAM. És még ez sem zárná ki a programok manipulálási lehetőségét, mert egyes változóikat kénytelenek lennének a RAM-ban tárolni, tehát kellő ügyességgel manipulálhatóak lennének. Továbbá rendkívül kényelmetlen lenne az új programok telepítése, régiek törlése. (Hirtelen valami sci-fi ugrott be, ahol kristályok cserélgetésével telepítettek és töröltek programokat.)

Annó, 2004 felé, raktam össze net kioszkhoz disztribúciót, ahol CD-n volt az OS. Ha leszámítom az elérési időket, működött a dolog.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Eleg sok megalapozatlan kijelentes szerepel itt (pl "hiszen a kódon érdemben nem tud kompresszálni semmi" - ezt azert probald ki, akar egy sima gzip-pel elotte), de igazabol csak egy linket helyeznek itt el:

https://en.wikipedia.org/wiki/Return-oriented_programming

Ezt olvasd el, ertsd meg, es utana ra fogsz jonni, hogy a read-only programmemoria azellen miert nemved.

Régóta vágyok én, az androidok mezonkincsére már!

Miután manapság minden második alkalmazás valami csoda Elektronos, Chromiumos csoda a tárhely témakört átgondolnám. Másrészt a 2 TB-s HDD nem túl reprezentatív a zömében 16..64G tárhellyel szerelt mobiltelefonok és 128..256G tárhellyel szerelt notik korában. Persze, legalább SSD.

A viccess az hogy harvardnak mondott archok csaladjaban is felbukan a memoriabol valo futatas lehetosege,
csak azert mert a RAM gyorsabb, mint a flash. Egyes  esetekben a kritikus kodreszlet ram -ba masolalsa tortenik.

Mas chippek rammot tesznek a flash es a core koze, es szep lassan flash tartalma RAM -ba lesz.

Egyebkent, eleg egyszeru egy Neuman archon megcsinalni hogy a cim ter bizonyos reszi nem futathatoak,
vagy nem irhatoak akkar lapazas nelkul is.

Ha mar bolond biztnsagi otleteknel jarunk, akkor stacket kene betiltani, legtobb
tamadas a stack felre hasznalatahoz kapcsolodik.
Ill. https://en.wikipedia.org/wiki/Return-to-libc_attack stilusu tamadas harvard archon is lehetseges.
stackless egyebkent is egy sikerese buzword.

Tiszta harvard arch szinte nem is letezik, kb. pic16 -az.

 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Szerkesztve: 2021. 04. 27., k – 20:50

A Neumann es a Harvard kozott azt mondanam alapveto kulonbsegnek hogy ezelobbi esetben 1, ezutobbi esetben 2 (vagyis: legalabb 2) buszt vezerel a CPU. Hogy most a program honnan jon, mit modosithat, milyen modon kerulheti meg az egesz latszolagos vedelmet (lasd: modositott Harvard, MMU-periferiak, barmi) az mar masodlagos. Es vannak olyan igencsak elterjedt architekturak ahol 3 busz is log ki a CPU-bol, es azzal is lehetne cifra varazslasokat vegezni ha nagyon akarnank... es olyasmi architekturak terjedtek volna el "nagyban", pl azokban az eszkozokben ami az internetet elero atlagember kezeben van.

Semmi koze nincs a konkret vedelemhez/biztonsagossaghoz ennek. Hogy kiscicas videokat inkabb Neumann-on nezunk... hat, istenem, ezt dobta a gep.

Szerk: hogy MCU-kban van sok Harvard is, annak meg inkabb az az oka hogy egyszerubb implementalni, kiszamithato a timing-ja es sokkal tobb featuraja van wait cycle-k es/vagy stall allapotok nelkul. Azaz pl egy CAN vagy USB bitbanget-et Harvardon meg tudsz irni, Neumann-on mar nem igazan (vagy csak sokkal kevesbe hatekonyan).

Vegre valaki leirta, hogy ez a Neumann vs. Harvard valojaban mirol is szolt.

Sot tovabbmegyek. Valojaban ma nincs is igazan tiszta Neumann architektura sehol hasznalatban. A mai x86 CPU-k kb a 486 (de legkesobb a Pentium) ota belul Harvard architekturasak. A tobbi utasitaskeszlet architekturanal is korabban vagy kesobb, de vegul atalltak a Harvard-jellegu megvalositasra, pont a fent leirt teljesitmeny-okok miatt.

Valojaban manapsag ket teljesen kulon belso busz van az utasitas fetch-re es az adat load/store-ra. Ez latszik a kulon L1I es L1D cache-nel is. Csak lejjebb talalkozik ossze a ket ag.

Régóta vágyok én, az androidok mezonkincsére már!

Hat, igy igen ;) Raadasul ha ugy csinalsz Harvard core-t hogy van benne wait cycle tamogatas is, akkor egy faek egyszeru arbitrerrel at tudod alakitani Neumanna. Nyilvan ezzel elveszitjuk az osszes (kulso programozas szempontjabol fontos) elonyet a Harvardak ugy hogy a hatranyai megmaradnak - de megtehetjuk.

Amikor az I bus nem fer hozza ramhoz:

https://adammunich.com/stm32-dma-cheat-sheet/

Amikor hozza fer (tipikus):
(3.2.1  page 12)
https://www.st.com/resource/en/application_note/dm00033267-migrating-a-…

Hagyomanyos buszok Z-statel (tristate) chippen belul manapsag nem szokas (nehez tesztelni).
Bus-matrix van. Sok point-to-point .

szerk:
A DMA leirasnal nem jeloltek hogy I-bus hozza ferne SRAM -hoz,
de meg minidg nem talaltam meg azt az ARM -ot ahol tenyleg igy lene.
A per tipus doksik szerint hozza fer, eddig mindegyiknel amit neztem,
ill. olyan forumot sem lattam volna ahol nem PEBKAC okozta volna
hogy rambol nem fut a program.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hogy most a program honnan jon, mit modosithat, milyen modon kerulheti meg az egesz latszolagos vedelmet (lasd: modositott Harvard, MMU-periferiak, barmi) az mar masodlagos.

Miért másodlagos? A módosított Harvard is csak azt engedi, hogy a kódot olvassa a proci adatként, ennek fordítottját már nem. Hogy lesz ebből végrehajtás? Sehogy.
Ez nekünk éppen jó is lenne.

Hogy kiscicas videokat inkabb Neumann-on nezunk... hat, istenem, ezt dobta a gep.

Már rég nem kiscicás videók, meg Prince of Persia létezik csak, egyéb játékokkal, meg hajnalig mulatozással a LAN partikon. A számítógépek köré kiépült egy komplett párhuzamos világ. Tananyag lett, alapkészséggé vált a használata, jobban beépült az emberek életébe, mint a TV. A számítógép produktív segédeszköz és produktumok létrehozására képes, immár teljesen önállóan. Már megszületett két generáció, amely úgy tekint a számítógépre, mint ősember a kőbaltára. Anélkül egy lépést sem, mondják. Vagy legalábbis, gondolják, de hogy teszik, az biztos.
Száz éve bement az egyszeri polgár a kovács, vagy  más mesterember  műhelyébe és azt mondta: nézze mester, nem rossz ez a termék, de így ellkészítve még jobb lenne. És elmagyarázta, lerajzolta, hogyan is képzeli. A mester pedig figyelembe vette az igényeit. Ezt bizonyítékok igazolják. Pedig sokszor nem is szakmabeli kérte a módosítást, hanem valami totál laikus végfelhasználó.  Most kinek az igényeit veszik figyelembe a tervezők? Kire volt tekintettel Steve Jobs? Még a saját anyjára sem.

 

Rossz úton járunk, és az irány is rossz. Lényegében mindenki. Elképesztő. Számomra befogadhatatlan. A legjobb nem is gondolni rá.

Kicsit olyan érzésem van, mint amikor a Ford szakszervizben dolgozó ismerőst megkérdezzük, hogy jó kocsik-e a Fordok, érdemes-e venni? Erre azt válaszolja, hogy szarok, mert egész nap azokat szereli. Amúgy meg igazából átlagembereknek teljesen megfelelők, a problémák meg nem is olyan borzasztók más termékekhez képest.

Nekem meg egy kicsit olyan érzésem vagy, hogy itt egy gép mellettem, ami kb. 5000-szer akkora számítási teljesítményre képes, mint az a 4,77 Mhz-en ketyegő XT, amin valamikor kezdtem, mégis, az egész plusz teljesítmény zömét felzabálja egy olyan operációs rendszer, ami ma   GigaByte-okon terpeszkedik, pedig nem sokkal nyújt többet, mint a korábbi, ami még ~ 100 MB-on is elfért. A processzort pedig a kártevővédelem járatja folyamatosan, az a kártevővédelem, amely soha nem volt elég hatékony és hát, "természetesen" ma sem az.
Emellett, az IBM kompatibilis PC ma már nyomaiban sem hasonlít az egykori szabványteremtőre, azaz, mindent kicseréltek rajta, amit lehetett. Apropó, ISA buszt ki mikor látott utoljára? Ja, hogy nem csak ISA-t, de még VLB-t sem az elmúlt negyed évszázadban?
Az USB 1.0 egy merő szívás volt? Az hát, de mégis, ki lenne meg ma USB nélkül?
Hol van ma már a CD-R? Kb. ott ahol a DVD, pedig ...  Hát erről beszélek.
A serial ATA újszerűsége rémlik még? Na és a vergődés az első generációs SSD-kkel? 
Ezzel csak arra szeretnék utalni, hogy a legtöbb ember fél a változástól, pedig folyamatosan alkalmazkodásra kényszerítik. Ha akarja, ha nem.

Szóval, egyesek szerint jó a ford, szerintem meg nem jó. Nem jó az még szerintük sem, tudják is, hogy miért nem, csak félnek valami újba beleállni. Pedig beleállítják őket előbb utóbb, most is azon dolgozik sok tízezer mérnök. 

 
 

"ISA buszt ki mikor látott utoljára"

00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
        Subsystem: Dell Device 07f9
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        NUMA node: 0

"ISA bus or LPC bridge. ISA slots are no longer provided on more recent motherboards. The LPC bridge provides a data and control path to the super I/O (the normal attachment for the PS/2 keyboard and mouse, parallel port, serial port, IR port, and floppy controller) and FWH (firmware hub which provides access to BIOS flash storage)."

Slot nincs, ISA van.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.