Stary komputer nowy samolot - to tylko pozornie OT

Apr 29, 2020 55 Replies

Przepraszam Cie, ale to jest możliwe w prawie każdym CPU. Nawet w super wypasionych x86 z super bezpiecznymi mechanizmami chronienia przed wykonywaniem kodu z ram wymyślono np. obejście o nazwie return-oriented-programming które jest absurdalnie ale działające i daje konkretne efekty (jak hacking PS4). Ba, dzięki tej technice można wykonywac "kod z ramu" majac do czyniena z architekturą która tego nie potrafi sprzętowo (Harvard). Niezłe jaja nie?

Serio, dajesz wiarę że komplikacja CPU powoduje że coś nie da się zhackowac? Że większa przestrzeń adresowa przed czymś chroni? Że, w końcu o to zapytam, w duperelowatej przelotce RS485, której pies z kulawą nogą nie będzie hackował, to w ogóle POTRZEBNE i jest argumentem za uzyciem linixa czy Cortexa M500? Urządzenia oparte o Linxua hackuje się łatwiej tylko dlatego że można wykorzystać znane podatności w Linuxie, można znaleźć backdoory zostawiane przez idiotów w procesie produkcji, można znaleźć zabezpieczenia które nia mają sensu itd itp.

W przelotce użyto linuxa bo była zrobiona na odpierdol. Nikomu on tam w środku potrzebny nie jest, przelotka nie ma adnych zaawansowanych funkcji poza otwarciem portu TCP i przerzucaniem bajtów z lewa na prawo.

Tak, to jest ten mały fragment zajmujący się przyjmowaniem przerwań, implementujący sekcje krytyczne, zajmujący się multitaskingiem, specyficzny dla każdego rdzenia i bardzo często specyficzny dla konkretnego SoCa. Do dzisiaj w tym małym, duperelowatym fragmencie kodu czaiły się błedy, nawet na tej super wypasionej, przetestowanej pornolami, platformie x86. Dasz wiarę?

Oczywiście, zawsze jest rynek dla dziadowskich rozwiązań, szczgólnie ze sprawnym marketingiem. Oby to nie był rynek dla rozwiązań w lotnictwie.

Bierzesz wypasonego ARMa który ma MMU. Na dzien dobry dostajesz w łeb sporką komplikacją kodu wynikajacą z pamieci wirtualnej. Możesz jej nie używać, oczywiscie, ale co jesli urządzenia I/O są mapowane przez jakieś MMUIO? Nagle musisz napisać dużo cholerne skomplikowanego kodu tylko po to aby to obsługiwać. Coś co dawniej robione jako PORTD |= FOO; dzisiaj urasta do kilkuset linijek zabawy w dostęp przez MMU, najpewniej z bugami.

Idź teraz i wlacz z przetestowaniem tego invitro.

To wszystko zależy ile kodu, boiler plate, niesie ze sobą architektura. Im większy CPU tym trudniej pisać to co chcesz bez zajmowania się pierdołami dookoła. W skrajnych przypadkach, jak mikorontrolery na x86, trzeba było się zajmować całym tym debilizmem jak tryby real, protected, long, short i h... wie co jeszcze, żeby w końcu po kilku tygodniach zamigać diodą.

Rozumiesz że każda linijka kodu, kazdy if, każdy zapis do rejestru, każda akcja globalna to jest nowa ścieżka testowania i generuje coraz trudniejsze w audytowaniu środowisko?

Jak ktoś miga diodą to pal sześć. Jak to lata samolotem to NIE chcę skomplikowanego cpu na którym się pisze łatwiej. Bo się cieżej

*testuje*. Dziwne, że wiele osób zapomina o tym, że kod krytyczny podlega restrykcyjnemu testowaniu a popieprzone architektury nie usprawniają tego procesu. Wręcz uniemożliwiają w skończonym czasie.

W dniu 2020-04-30 o 02:28, snipped-for-privacy@math.uni.wroc.pl pisze:

Generalnie Benek uchodził za takiego, co uważa, że decyzje podejmuje pilot, z kolei Arbuz miał filozofię, że pilot ma jedynie podziwiać dyskotekę w kokpicie. I wszystko było dobrze, do czasu, aż Benek postanowił pójść w ślady Arbuza. No cóż, stara zasada serwisantów mówi: Jeśli coś dobrze działa, to nie poprawiaj. Coś mi się zdaje, że nie byłby to wielki problem "wyczucie" nowego samolotu bez tego felernego systemu.

Pozdroofka, Pawel Chorzempa

Nie rozumiem jak to działa. Na stosie podkładamy adres wybranej i pasującej instrukcji (gadżet) z istniejącej przestrzeni (kodu/liba/whatever). Ale co dalej? Przecież CPU zrobi skok tam, wykona tą instrukcje ALE pójdzie dalej. Jak niby połączyć w sensowną całość (jeden kontekst) instrukcje które się chce wykonać?

Gadżet wygląda tak [...]

-2. kod

-1. kod

0 adres wejścia
  1. kod
  2. kod
  3. kod
  4. return

Na stosie układasz listę adresów wejścia w rózne fragmenty istniejącego kodu. Powoduje to wykonywanie się kawałków kodu, następnie dzięki return nastepuje *uzyteczny* skok do innego gadżetu, bo return jest uzywany jako jump. I tak w kółko, każdy "return" powoduje skok dalej, do następnego. Wszystko gadety połaczone sa w jeden łańcuch, return działają jak jump.

Nie rozumiem, przecież idea mówi o tym, że gadżetem jest JEDNA instrukcja (pod adresem 0 j.w.) + return a w/w instrukcje 1. 2.... do return to instrukcje w dalszym fragmencie np. liba ALE z innego kontekstu, które mogą popsuć to co się zrobi "at 0".

Nie. gadżetem jest zakończenie funkcji zawierajace użyteczny kod, razem z return. Może zawierać jedną instrukcję i return, może zawierać kilka instrukcji (z czego uzyteczna instruckja bądź instrukcje mogą być w środku bezuzytecznych) i return.

Ogólnie to jest dowolna, przydatna, końcówka funkcji. Nie ma okreslonego ile zawiera instrucji. Ile potrzebujesz, jeśli jest użyteczna.

Celem zazwyczaj jest przestawienie jakiegoś bitu we właściym miejscu które pozwoli z normalnego kodu na dostęp gdzieś dalej. Często te "liniowe" wykonywanie kodu może być wystarczające do tak prostych zastosowań. Przy odpowiednich gadźetach możesz zrobić wszystko, zazwyczaj gadżety są turing-complete.

Dobieranie gadżetów tak by wzajmenie nie niszczyły sobie danych na których pracujesz jest istotą tej sztuczki. Z tego co słyszalem jest jakiś dodatek do Ghidra (a może do ida pro? nie pamietam) wspomagający wyszukiwanie gadżetów w istniejącym kodzie.

Polecam:

formatting link

Tak, wierzę że dołożenie zabezpieczeń sprzętowych i programowych do CPU zwiększa szansę na wykrycie błędu i reakcję.

Równie dobrze mógłbyś mnie przekonywać że komplikowanie konstrukcji windy przez dokładanie hamulców bezpieczeństwa jest bez sensu bo:

  1. komplikuje konstrukcję i zwiększa ilość testów
  2. hamulce mogą mieć błędy konstrukcyjne
  3. hamulce marki Linux używane w windach towarowych to już w ogóle tragedia, bo można je zablokować śrubokrętem. Co najwyżej można użyć drewnianego klina wystruganego w garażu, bo pan Mieczysław pokrył go w
100% testami i ma na to papier.

No wiec ma się to nijak do współczesnego świata. Zwiększanie poziomu komplikacji hardware doprowadza albo do idiotycznych probelmów z bezpieczeństwem (wyciakenia danych z powodu speculative execution / cache) albo wręcz uszkadzania danych (row hammer) w tych super zabezpieczonych kawałkach hardware z masą 3-literowych skrutów. Pomijam fakt że skompikowany hardware jest skomplikowany z punktu widzenia programisty i wymaga *znacznie* bardziej bugogennego kodu.

Problem polega na tym że porówniae powinno być pociągnięte dalej:

Pan Mieczysław potrzebuje hamował koło zamachowe w swoim stołowym modelu silnika parowego.

Ma do wyboru użyć kawałka drewna, co przetestowano już na milion sposóbo albo wybrać hamulec brake-on-wire na bazie linuxa na czymś z okolicy Ryzena.

Pan Mieczysław wybiera Ryzena. Bo kto by nie chciał nowocześnie?

Natomiast gdybyś się nieco postarał, to porównanie prawidłwoe jest inne:

Mieczysław LTD od 30 lat produkuje sterowniki hamulców ręcznych do samolotów. Hamulce są oparte o jakiegoś starego MIPSa z 4kB RAMu, ale za to są odporne na promieniowanie kosmiczne, zweryfikowane formalnie na poziomu software i hardware dzieki czemu dopuszczone do latania stosownymi certyfikatami, w dodatku pracują reduntantnie a ich konstrukcja umożliwia ekslopatację przez kilkadziesiąt lat bez sewisowania, a z uwagi na to że kod jest niezmienny, ustalono również że będzie wypalony w ROMie dzięki czemu nie straszne mu rozbłyski gamma, pioruny czy nawet toksyczne wydzieliny mniej kontrolowanego końca przewodu pokarmowego. Dzięki tym prymitywnym urządzeniom każdy samolot może bez problemu zahamować zaraz po zaciągnięciu mimo że ich moc obliczeniowa jest milion razy mniejsza niż w smarfonie od oglądania porno dowolnego pasażera i troche siara.

Łomatko! Przepraszam, jeśli ktoś opluł monitor.

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

Czytasz na co odpisujesz? Była mowa o zwiększaniu a zabezpieczeń a Ty odpowiadasz ogólnie o zwiększaniu kompikacji. Speculative execution nie jest zabezpieczeniem tylko metodą zwiększenia wydajności. Zabezpieczeniem jest np. DEP.

Wszystko w artykule jest, ja tylko bardzo skrótowo zrobiłem wstęp, bo inaczej to bym musiał prawie cały artykuł zacytować. Ale zacytuję podsumowanie: 'Ten samolot będzie teraz prześwietlony tak dokładnie, jak żaden inny, a to może spowodować, że zamiast skrócić czas uziemienia Maxa, przedłuży się go w nieskończoność. Na końcu okaże się, że firma i tak będzie musiała zainwestować i przeprojektować cały system komputerów pokładowych, ale nieciekawe wrażenie pozostanie już na zawsze. Nie wiem jak dla Was, ale dla mnie, to jedna z największych afer „produktowych”, o jakiej słyszałem. Jest mi też ciężko sobie wyobrazić, żebym mógł kiedykolwiek wejść na pokład tego samolotu albo co grosza wsadzić do niego rodzinę. '

Dobrze, wiec dodajesz paging z bitami excutable.

To nie jest za darmo. Musisz dopisać kod do obsługi. Czasami, jak w przypadku debilnej architektury x86, to jest absurdalnie skomplikowany kod.

Właśnie Ci pokazałem ile ten DEP jest warty w zderzeniu z ROP. Masz następną bzdurę która nie zabezpiecza a jedynie powoduje komplikacjie kodu klienta i delikatnie spowalnia hackera.

formatting link
Serio, uważasz że w tym samolocie albo w tej przelotce ethernet chodzi o to aby zabezpieczeń skomplikowany system? A nie lepiej napisać *mało* kodu i następnie metodami formalnymi stwierdzić że nie posiadają dziur, błedów czy innych niespodzianek?

Jest mi też ciężko sobie wyobrazić, żebym mógł

No to zabawmy się w grę "zaraza skończona". Wykupujesz wczasy w jakiejś agencji turystycznej, a na lotnisku dowiadujesz się, że to właśnie ten felerny. Co robisz, lecisz, czy mówisz rodzinie "tym nie lecimy" i odwołujesz zapłacone już wczasy?

Miłego. Irek.N.

U mnie było jasno napisane jaki samolot, jakiego przewoźnika o jakiej godzinie. Zmienili na 3 dni wcześniej, znajdując inny czarter, w którym jeden z silników wyraźnie wibrował cała drogę mocniej. Wysiadać w trakcie ;) ?

Aby przyśpieszyć

I tutaj moim zdaniem jest pies pogrzebany. Chcieli wykorzystać istniejącą wiedzą/przyzwyczajenia/dopuszczenia, aby możliwie przyspieszyć moment oddania samolotu do eksploatacji jak najszerszej klienteli, bez ponoszenia przez nich kosztów szkoleń. Przecwaniaczyli, ale nie tylko oni. Wierzycie w to, że żadna z linii nie zastanowiła się nad sposobem w jaki oddano te samoloty? Im też było "po drodze, że pasuje po staremu". Gdyby klienci byli wymagający jak powinni i nie poszli na łatwiznę, to B też by takiego wałka nie zrobił.

Miłego. Irek.N.

A nie szerzej? Są chyba jakieś normy projektowania w tej branży? Wiem jakie są wymagania w dziedzinie wykonawstwa elementów dla branży lotniczej (znaczy trochę wiem). Jak to jest możliwe, że w przypadku pojazdu który nie można ot tak zatrzymać dla bezpieczeństwa pasażerów na poboczu - jak samochód przykładowo, dopuszcza się pojedyncze układy czujników? W mniej newralgicznych dziedzinach dubluje się, a tutaj wolno nie dublować? Nie pasuje mi to... znaczy... śmierdzi na odległość.

Tak więc po mojemu winny jest praktycznie każdy w łańcuszku w którym powstał, a następnie mógł polecieć taki samolot. Mam tutaj na myśli wszystkich od "początkowego pomysłu", po przez konstruktorów/programistów, po kontrolę, certyfikację, kupującego, a na pilotach skończywszy.

Takie moje zdanie w temacie. Miłego. Irek.N.

No właśnie tutaj jest problem. Niby wszystko wiesz, masz sprawdzone, jesteś skrupulatny. Ale z niezależnych od nikogo powodów nie da się zrealizować planu i to w ostatnim momencie przed wsiadaniem. Co wtedy? Nie wierzę, żę można zapisać w umowie zdanie "albo taki a taki samolot tej a tej linii, albo umowa nieważna" ;)

Miłego. Irek.N.

Na koniec zawsze winna jest kontrola jakości. Moralnie to sobie mogą być winni programiści, managerowie, księgowe itd itp. Ale to kontrola jakości przepuściła bubla, JEŚLI to problem z software i zgadza się z opisem z tego watku (za mała moc obliczeniowa, czyli brak testowania w warunkach prawdziwej eksploatacji).

Zaznaczam, JEŚLI to problem z wydajnoscią sterowania. Bo prawda jest taka że problem leżał też w czujniku i procedurach.

W dniu 2020-04-30 o 15:53, Irek.N. pisze:

Musisz sobie odpowiedzieć na ile cenisz zdrowie i życie swoje i rodziny, czy warto ryzykować czy nie. Może dlatego jeszcze nie latałem :)

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required