Czy mozliwe jest napisanie calego systemu operacyjnego w assemblerze? Wszystkich bibliotek, driverow?
0
0
Jest
0
Heh możliwe to jest, ale mało praktyczne. Pierwsze wersje uniksa były w asmie pisane.
0
Polecam MenuetOS :)
0
oczywiscie ze jest: piszesz krytyczne rzeczy w asm, piszesz mneij krytyczne w C. jak Ci sie nie chce - sciagasz sobie zrodla linuksa, wlasnie tak wygladaja. No ale mialo byc w asm.. no to kompilujesz te wszystkie pliki C przy pomocy gcc i kazesz mu zamiast binarki wypluc z siebie listing assemblerowy. Et voila'! Masz juz caly system w ASM :)
0
Oczywiście że się da, ale dziś wielkiego sensu to nie ma - przyszłość to systemy operacyjne z garbage collectorem i VM (coś takiego jak singularity, system MS - pisany w C#). W asmie/C tylko najbardziej niskopoziomowe rzeczy, takie jak zarządzanie przerwaniami, wątkami, etc.
O ile linux (jądro) nie przejdzie na jakiś inny język (wszystko jedno jaki, byleby nie miał wskaźników, miał gc i działał na vm) za 5-10 lat praktycznie wszystkie exploity itd. będą istnieć tylko na niego... (już teraz vista jest o wiele bezpieczniejsza, aczkolwiek nie dzięki temu - ale ciągle jakieś błędy się trafiają).
Rzeczą wartą wzmianki jest także o wiele lepsza stabilność i elastyczność (krótszy kod, wyższy poziom abstrakcji) takiego systemu.
0
fr3 napisał(a)
Oczywiście że się da, ale dziś wielkiego sensu to nie ma - przyszłość to systemy operacyjne z garbage collectorem.
LOL, co to jest system operacyjny z GC ? :]
0
Rzeczą wartą wzmianki jest także o wiele lepsza stabilność i elastyczność (krótszy kod, wyższy poziom abstrakcji) takiego systemu.
A ten twoj VM to sie sam napisze? Conajwyzej aplikacje pod takie cos beda stabilniejsze i elastyczniejsze a nie system. I co maja do tego exploity?
(już teraz vista jest o wiele bezpieczniejsza, aczkolwiek nie dzięki temu - ale ciągle jakieś błędy się trafiają)
W kilka miesiecy juz cala rozgryzles? :|
0
fr3 napisał(a)
(krótszy kod, wyższy poziom abstrakcji) takiego systemu.
a to ne zawsze oznacza ze na takim czyms bedzie lepiej. raczej ze bedzie mozna tworzyc szybko rzeczy szablonowe/przewidziane przez tworcow frameworka, a te nieszablonowe/nieprzewidziane bedie sie pisac duuzo gorzej, o ile w ogole sie da :)
Oczywiście że się da, ale dziś wielkiego sensu to nie ma - przyszłość to systemy operacyjne z garbage collectorem.
rrany.. wiesz o czym mowisz? po co systemowi GC? uwolnienie zasobow po zamkonczeniu procesu nie wystarczy?:))))
0
słyszem głosy że bardzo zwiększyłoby się bezpieczeństwo OS gdyby pamięć operacyjna była podzielona ( byćmoże nawet fizycznie ) w taki sposób by odróżnić w pamięci dane od programu. Co myślicie o tym że wiekszość dziur jaką ludzie znajdują właśnie opiera się o to że program i dane programu w pamięci są jednym?
dopisane: moim zdaniem ochrona pamięci bardzo kuleje i nie jest to do końca to oczym mówię
0
gaborek napisał(a)
Co myślicie o tym że wiekszość dziur jaką ludzie znajdują właśnie opiera się o to że program i dane programu w pamięci są jednym?
Ja mysle zebys zapoznal sie ze stronicowaniem i segmentacja pamieci albo ogolnie z mechanizmami ochrony w x86 :)
0
gaborek napisał(a)
Co myślicie o tym że wiekszość dziur jaką ludzie znajdują właśnie opiera się o to że program i dane programu w pamięci są jednym?
podchwytliwe pytanie: czyli co, jest kod osobno i dane osobno i nie mozna wykonywac danych jako instrukcji ani zapisywac danych do kodu? i to miala by byc ochrona juz na poziomie procesora? to w taki sposob, jak mialby system operacyjny odczytac z dysku exeka (zapisac dane do pamieci!) a potem je uruchomic (kod!) :)
.. a tak w ogole to to juz jest od dawna zrobione.. zastosuj sie do porady wolverine'a i dodatkowo zwroc uwage na flagi okreslajace typ strony
0
Ale o ile wiem to ochrona segmentu danych w ten sposób aby nie można było wykonać kodu z obszaru danych, na poziomie procesora, to już istnieje. "NoExecute" czyli "Data Execution Prevention" programowo zrealizowana w Windows XP SP2 i wyżej.
NX-bit jest nazwą marketingową rozszerzenia technologii stronicowania pamięci, zastosowaną w niektórych procesorach rodziny K8 firmy AMD. Polega ono na zastosowaniu w tablicy stron dodatkowego bitu nazwanego NX (ang. No eXecute - "nie wykonuj"), pozwalającego oznaczyć pojedyncze strony. Gdy bit NX dla danej strony jest ustawiony, próba wykonania zawartości tej strony jako kodu kończy się wygenerowaniem wyjątku, zgłaszanego systemowi operacyjnemu, co powoduje przerwanie wykonywania programu. Mechanizm ten chroni aplikacje przed niektórymi wersjami ataku typu buffer overflow, nie pozwalając wykonać szkodliwego kodu z zablokowanej strony. Bit NX powinien być ustawiony dla wszystkich stron procesu, z wyjątkiem programu i bibliotek oraz świadomie dozwolonych przez program wyjątków.
Nie tak od dawna, ale ochrona także taka jest (i chyba quetzocoatl o tym mówisz, tak?)
0
quetzalcoatl napisał(a)
a to ne zawsze oznacza ze na takim czyms bedzie lepiej. raczej ze bedzie mozna tworzyc szybko rzeczy szablonowe/przewidziane przez tworcow frameworka, a te nieszablonowe/nieprzewidziane bedie sie pisac duuzo gorzej, o ile w ogole sie da :)
rotfl ;)
Nie no brawo, jeszcze nie widziałem żeby ktoś uznał hll za 'framework' i zakwestionował kompletność (w sensie turinga) tych języków...
rrany.. wiesz o czym mowisz? po co systemowi GC? uwolnienie zasobow po zamkonczeniu procesu nie wystarczy?:))))
Miałem generalnie na myśli wpisanie gc w system + całkowity brak dostępu bezpośredniego dostępu do pamięci. Bezpośrednia kontrola stron, segmentów, TLB - w rezultacie garbage collector miałby ogromne fory - szybsze działanie i lepsza optymalizacja dla cache procesora/wielkości zajmowanej pamięci.
Brak bezpośredniego dostępu do pamięci + vm umożliwia także prawdziwe działanie równoległe - każda aplikacja będzie (prawie) całkowicie sama zajmować się zwalnianiem swoich zasobów (trochę jak w dosie), w rezultacie architektura systemu zostanie ogromnie uproszczona - większa stabilność, szybkość, drastycznie zmniejszona podatność na błędy...
I taka jest na szczęście przyszłość, co widać po takim singularity.
P.S Zwalnianie zasobów od razu po wyłączeniu procesu nie jest takie mądre - istnieje dużo prawdopodobieństwo, że nowy proces użyje np. załadowane biblioteki, czy otworzy ten sam plik...
0
Singularity, tak jak i Windows poza desktopy nie wyjdzie wiec sie tak nie podniecaj :]
0
yacooh, możesz jakieś konkretne argumetny przeciwko wypowiedzi fr3m3na postwić? Mam wrażenie, że nie miałeś nawet styczności z GC. Jako człowiek, który przez kilka lat pisał prawie wszystko w assemblerze, jako reverse engineer mogę powiedzieć, że GC byłby jest świetnym rozwiązaniem dla systemu operacyjnego. Wymaga to zwiększenia poziomu abstrakcji. Hm, pisałeś kiedys w C++ czy innym języku z zastosowaniem smart pointerów? Taki kontener udający wskaźnik zwalniający trzymaną pamięć gdy liczba referencji do niej spadnie do zera - to taka namiastka najprostszego GC. Implementacja GC pociąga za sobą konieczność zrezygnowania z bezpośrednich wskaźników. Oczywiście nie w 100% - powinna istnieć możliwość zablokowania obszaru na czas wykonywania na nim operacji /optymalizacja czasu dostępu/. Wirtualizacja programów? Zobacz jak wiele komponentów Visty jest opartych na .Net. Może nie jest to najlepsze porównanie ale szybkość Visty - a właściwie jej brak - jest spowodowana zmienioną architekturą kernela. Tak, owszem, VM I GC wymagają dodatkowych zasobów pamięci ale... to jest niewielka cena. GC /szczególnie z remapowaniem obszarów poprzez stronnicowanie/ optymalizuje pamięć i jej użycie.
Słyszałeś może o pomyśle sprzętowego GC, w procesorze?
Jeżeli zaś o opóźnione zwalnianie chodzi - jest to całkiem skuteczne rozwiązanie, nie wiem czy wiesz, ale Windows dosyć mocno tego używa przy buforowaniu plików.
Prawda jest taka, że niskopoziomowość jest konieczna aby zapewnić odpowiednio wydajną i pewną wysokopoziomowość. Widziałem eksperymentalne OS'y w wielu językach, nawet w lispie... wiele z nich miało fenomentalne rozwiązania... cóż, czy jest jeszcze ktoś, kto wierzy, że oprogramowanie powinno się pisać wyłącznie w asm?
0
deus napisał(a)
Słyszałeś może o pomyśle sprzętowego GC, w procesorze?
Moglbys troche przyblizyc? :)
Podstawowym moim argumentem dla tworow typu Singularity jest wlasnie pytanie: "dlaczego nie mozna takiego srodowiska jak VM .NETa czy Javy odtworzyc sprzetowo?" Przeciez juz dzisiaj Intelowska platforma ma wystarczajaco duzo mechanizmow ochrony wiec po co na sile emulowac jeszcze jakiegos CLR (czy cokolwiek innego) skoro za wiele nowego on nie wnosi? Singularity zabiera sens tym wszystkim sprzetowym mechanizmom (ringi, stronicowanie, segmentacja etc) a w zamian daje nam VMa ktory emuluje to samo + GC i pare [CIACH!] (te [CIACH!] to tylko takie zabezpieczenie bo nawet nie przychodzi mi nic do glowy).
Byla mowa o bezpieczenstwie, ale czy napisanie OSa ktory calkowicie oddziela od siebie procesy jest niemozliwe na x86? Nie jest, wiec bezpieczenstwo imo byloby takie same.
Wydajnosc? Jakikolwiek JIT nie bedzie chyba szybszy niz natywny kod, bo jakim cudem?
//WTF z tym ciach? ;d
0
Wolverine napisał(a)
deus napisał(a)
Słyszałeś może o pomyśle sprzętowego GC, w procesorze?
Moglbys troche przyblizyc? :)
Cóż, przyznam się, że nie pamiętam dokładnie, ktoś coś jakiś czas temu mówił na #4pogrammers /btw. jak się nudzisz to mógłbyś wpaść - czasem się właśnie takie ciekawe dyskusje trafiają/.
Wolverine napisał(a)
Byla mowa o bezpieczenstwie, ale czy napisanie OSa ktory calkowicie oddziela od siebie procesy jest niemozliwe na x86? Nie jest, wiec bezpieczenstwo imo byloby takie same.
Już Windows NT to oferuje... oczywiście łamią to debug api, współdzielone sekcje itd. Po wywaleniu Debug API i najbardziej niskopoziomowych operacji /jak np. mapowanie konkretnego adresu z pamięci fizycznej w przestrzeń procesu/ otrzymujemy całkiem przyzwoitą hermetyzację.
Co do poziomu bezpieczeństwa to się nie zgodzę - natywny kod ma zbyt łatwy dostęp do wszystkiego. Microsoft nie udokumentował np. niektórych native api, byle program jednak może ich używać. Zakładając, że spora część jądra jest natywna /tak ring0 jak i ring3/ można uzyskać przyzwoitą wydajność i poziom bezpieczeństwa na VM. Jedynym zagrożeniem byłyby luki w natywnych modułach.
Wolverine napisał(a)
Wydajnosc? Jakikolwiek JIT nie bedzie chyba szybszy niz natywny kod, bo jakim cudem?
Hm.. tu jest problem. Zakładając, że bytecode jest tłumaczony na natywny to może być szybszy od programu napisanego bezpośrednio w kodzie natywnym. Dlaczego? Tłumaczenie kontekstowe - kod jest tworzony z uwzględnieniem aktualnych warunków. Oczywiście kompilacja swoje trwa ale... zakładając, że chodzi o jakieś skomplikowane, specyficzne obliczenia w pętli z ogromną liczbą iteracji to uwzględnienie warunków pracy przy tłumaczeniu może dać mimo wszystko większą wydajność... Obawiam się nawet, że mógłbym przegrać z taką zabawką jeżeli chodzi o szybkość tworzonego kodu w wynikowego - dotychczas nawet z kompilatorami Intela udało mi się wygrać dzięki przewidywaniu warunków pracy właśnie /coś, czego nie da się w 100% przekazać w HLL/. Jeżeli mówimy o interpretacji bytecode'u to oczywiście, że wydajność będzie mniejsza - przy bardzo dobrze opracowanym VM ~3x.
W każdym razie czas kompilacji powinien się w optymalnych warunkach zwrócić w wykonywaniu.
Hm... a gdyby tak 4p rozpoczęło własne 'badania' nad VM? Z fr3m3nem 'trochę' siedzieliśmy nad optymalizacją, różnymi cudami z GC związanymi właśnie? To tylko lekka sugestia, do tego potrzeba wielu osób z wiedzą, zapałem, pasją i czasem. Z tym ostatnim wiadomo jak jest :/
0
Wolverine napisał(a)
deus napisał(a)
Słyszałeś może o pomyśle sprzętowego GC, w procesorze?
Moglbys troche przyblizyc? :)
http://en.wikipedia.org/wiki/Intel_iAPX_432
Jest jakis nowoczesny odpowiednik ale zapomniałem nazwy
Byla mowa o bezpieczenstwie, ale czy napisanie OSa ktory calkowicie oddziela od siebie procesy jest niemozliwe na x86? Nie jest, wiec bezpieczenstwo imo byloby takie same.
Bezpieczenstwo dla calego systemu - owszem, w sumie takie same. Ale dla jednego procesu - nieporownywalnie lepsze, odpada 99% typowych exploitowalnych błędów - zostają tylko bardzo rzadkie i trudne do wykorzystania błędy logiczne, jak np. złe sprawdzanie warunku w sprawdzaniu jakiegoś poziomu dostępu...
NX nie zapobiega wykorzystaniu błędu buffer overflow (ktos cos o tym wczesniej mowil), jedynie to utrudnia - ciagle jest możliwy atak typu return-to-libc itd...
Wydajnosc? Jakikolwiek JIT nie bedzie chyba szybszy niz natywny kod, bo jakim cudem?
Jak deus niżej napisał... do tego jit=kontrola kodu=brak wymaganych zabezpieczeń w runtime=szybsze działanie ;]
Jacooh napisał(a)
Singularity, tak jak i Windows poza desktopy nie wyjdzie wiec sie tak nie podniecaj
Singularity nie wyjdzie nawet na desktopy, bo to research os - ale następne windowsy będą przynajmniej częściowo bazowały na jego ideach.
Co do windowsa... jakbyś nie wiedział, to Windows NT* [którego wejście wyrugowało z rynku serwerowego praktycznie wszystkie unixy ;) ] był i jest systemem SERWEROWYM, wiec stwierdzenie 'i tak poza desktopy nie wyjdzie' jest bez sensu.
0
fr3 napisał(a)
Nie no brawo, jeszcze nie widziałem żeby ktoś uznał hll za 'framework' i zakwestionował kompletność (w sensie turinga) tych języków...
nie kwestionowalem kompletnosci, tylko czas/wysilek potrzebny na osiagniecie efektu nie przewidzianego przez projektantow danego 3/4GL. wez dowolny 4GL i sprobuj zrobic cos nieszablonowego, bez uzycia native/winapi/etc.. poza tym, 4GL to zazwyczaj framework oparty na 3GL plus jakis prosty DSL w ktorym podajesz metaopis tego co ma powstac, stad takie moje okreslenie
deus napisał(a)
Hm... a gdyby tak 4p rozpoczęło własne 'badania' nad VM? Z fr3m3nem 'trochę' siedzieliśmy nad optymalizacją, różnymi cudami z GC związanymi właśnie? To tylko lekka sugestia, do tego potrzeba wielu osób z wiedzą, zapałem, pasją i czasem. Z tym ostatnim wiadomo jak jest :/
ciekawa idea, acz nie wiem na ile sam moglbym sie przydac.. a wlasnie, propo zapalu i czasu, zdazyles z raportem na hc? obejrzalem sobie ichnie 'protection map'.. niby dwie sumy kontrolne, a zadna mojego patcha nie wykryla i nawet ich plrzeliczac nie musialem, sie nie postarali:) poza tym maja blad we wlasnym wzorze.. z disasma wynikalo wprost ze wzor to a/()+x-y a nie a/()-y.. dziwne to troche
0
nie kwestionowalem kompletnosci, tylko czas/wysilek potrzebny na osiagniecie efektu nie przewidzianego przez projektantow danego 3/4GL. wez dowolny 4GL i sprobuj zrobic cos nieszablonowego, bez uzycia native/winapi/etc.. poza tym, 4GL to zazwyczaj framework oparty na 3GL plus jakis prosty DSL w ktorym podajesz metaopis tego co ma powstac, stad takie moje okreslenie
Obecne 4GL sa trochę zbyt wyspecjalizowane, myślałem o 3GL z GC, funkcjami jako obiekty pierwszej klasy, OO (ew pattern matching albo dwa na raz).
Przydały by się makra ale to ma tylko lisp więc języki ms starczą (C#, F#).
quetzalcoatl napisał(a)
deus napisał(a)
Hm... a gdyby tak 4p rozpoczęło własne 'badania' nad VM? Z fr3m3nem 'trochę' siedzieliśmy nad optymalizacją, różnymi cudami z GC związanymi właśnie? To tylko lekka sugestia, do tego potrzeba wielu osób z wiedzą, zapałem, pasją i czasem. Z tym ostatnim wiadomo jak jest :/
ciekawa idea, acz nie wiem na ile sam moglbym sie przydac.. a wlasnie, propo zapalu i czasu, zdazyles z raportem na hc? obejrzalem sobie ichnie 'protection map'.. niby dwie sumy kontrolne, a zadna mojego patcha nie wykryla i nawet ich plrzeliczac nie musialem, sie nie postarali:) poza tym maja blad we wlasnym wzorze.. z disasma wynikalo wprost ze wzor to a/()+x-y a nie a/()-y.. dziwne to troche
Nie ominąłeś antydebuga? x to antydebug, normalnie jest ustawiany na 0.0, ale w przypadku wykrycia debuggera jest ustawiane na pi
Więc sama formula jest poprawna, skoro x to zawsze ;) będzie 0.0
A checksum dotyczy tylko rozpakowanej sekcji .text więc jeśli zmieniłeś liczbę w rdata to tego nie wykryje
0
hmm moze jestem brzydki i sie nie znam, ale nie dokonca rozumiem krzyk zwolennikow Singularity i jej podobnych, z tego co wiem da sie napisac system hakieroodporny w C i asmie bez wiekszych problemow, chodzi mi mianowicie o system fortece - OpenBSD.
0
fr3 - tego antydebuga zauwazylem, oczywiscie, ale omijalem go tylko podczas sledzenia procesu i zachowawszy oryginalna wartosc "stalych" juz sie dalej nie zajmowalem nimi - i przegapilem ze to byla ona. co do checksuma to tylko chcialem powiedziec ze no to taka troche plama z ich strony:)
Obecne 4GL sa trochę zbyt wyspecjalizowane, myślałem o 3GL z GC, funkcjami jako obiekty pierwszej klasy, OO (ew pattern matching albo dwa na raz).
ja sie wlasnie czepialem 4GL, tosmy sie mineli :) hm.. o ile dobrze pamietam funkcje ani clasy chyba nie sa 1stclass w C#? fajny jezyk, ale szkoda tez ze nie mozna go bez frameworka .net uzywac..