On 10/12/2023 18:02, Zbych wrote:
>> Maszynista przedyktuje przez telefon w razie awarii lini IRQ na PCI-E?
> Zrobi zdjęcie i wyśle geniuszu.

I co dalej? Kolega mu przedyktuje, żeby wszedł w tryb single user i
zeskanował dysk fdiskiem, geniuszu?

do góry

On 10.12.2023 22:18, heby wrote:
> On 10/12/2023 18:02, Zbych wrote:
>>> Maszynista przedyktuje przez telefon w razie awarii lini IRQ na PCI-E?
>> Zrobi zdjęcie i wyśle geniuszu.
>
> I co dalej? Kolega mu przedyktuje, żeby wszedł w tryb single user i
> zeskanował dysk fdiskiem, geniuszu?

A co zazwyczaj pracownik robi jak się pojawia problem?

do góry

On 10/12/2023 18:14, vamastah wrote:
>> Jesli robisz domowy projekcik, albo nawet kompercyjny, konsumencki
>> projekcik, typu zabawkowego, nalezy jak najwięcej czerpać z gotowców.
>> Zawieszenie się tabletu dziacku spowoduje tylko płacz i traumę u
>> przedszkolaka, gdy to samo w pociągu może doprowadzić do utraty życia.
> Wlasnie dlatego w przypadku pociagu tez trzeba korzystac z gotowca, o
> ile takowy istnieje - istniejacy kod to kod sprawdzony przez
> poprzedniego uzytkownika.

Ten kod nigdy nie był pisany z myślą o pociągach. On był pisany z myślą
o kernelowaniu kompili i dicking around.

> Im wiecej uzytkownikow, tym wieksza szansa na
> wylapanie bledow.

To głupie myślenie: architektura sterownika-komputera ma zaledwie kilku
użytkowników.

Linux roił się od błedów w momencie pojawienia się innych architektur.

Ba, część kodu krytycznego (wątki, wywołania systemowe itd) jest
specyficzna dla danej architektury i to że działa na x86 nie oznacza że
działa na procesorze Foo firmy Bar.

> Mozna sie wrecz pokusic o stwierdzenie, ze
> pasazerowie zyskaliby na bezpieczenstwie, gdyby zaczeto stosowac
> oprogramowanie na licencji open source.

To coś zupełnie innego niż Linux.

OpenSource tak.

Akurat Linux - niekoniecznie.

>> Przepychanie wszystkich czujników i sterowania przez jeden, deliktny
>> system, jest naiwne. Linux, jako OS, może co najwyżej pełnić rolę
>> nadzorcy nad układami, ale układy powinny być autonomiczne i mieć
>> niezalezną możliwośc sterowania, pomijającą ten ekran (dotykowy?).
> No zgadza sie, przy czym to nie jest problem stricte Linuxa, a
> scentralizowanej architektury sprzetowej.

Posiadanie *wypasionego* systemu powoduje nieuchronne trendy do
wciskania do niego obsługi spryskiwaczy szyb i falowników silników w
jednym. Bo można zaoszczędzić pół centa.

Ten trend, nawet nie jest jakoś projektowany. Pojawia się samoczynnie,
kiedy projektem zaczynają interesować się księgowi.

>>> W tym przypadku (chodzi o sterowanie pociągu) argumentujesz w drugą
>>> stronę: dziwisz się, że producent poszedł "na łatwiznę" i
>>> zastosował coś co działa (choć jest wykorzystywane w innym
>>> zakresie) i jednak (jako producent) powinien zrobić coś całkowicie
>>> od nowa.
>> To nie branża, gdzie wolno iść na łatwiznę.
> Tu nie chodzi o pojscie na latwizne, tylko o aspekt czysto praktyczny.

Czyli łatwizna właśnie.

Zamaist robić trudniej, ale bezpieczniej, wsadzimy jakieś Ubuntu,
piszemy jakieś workaroundy w bashu i reszta dnia wolnego.

> I tak jak pisalem wyzej, byloby wskazane zeby producent nie odkrywal
> kola na nowo, a korzystal z tego, co juz wymyslono, niezaleznie od
> tego, czy to jest soft, czy nowy design hardware'u.

Producent, do ekspresu do kawy, wsadził Windows XP.

Uważasz że to rozsądne?

Zamiast podpiąc i nacisnac "kawa", teraz czekasz kilkanaście sekund, aż
to coś się uruchomi i wtedy naciskasz "kawa". Gdzie masz zysk?

Gdzie jest zysk z użycia Linuxa, startującego minutę i wyświetlającym
kilka kresek, nad oprogramowaniem wyświetlającym kilka kresek po
milisekundzie?

Czas pracy tak, ale w przypadku seryjnej produkcji asymptotycznie dąży
do zera.

>>> Gdzie w tym przypadku leży różnica pomiędzy szarym człowiekiem z
>>> konkretnymi wymaganiami i "dużym graczem" który jednak idzie na
>>> skróty ?
>> Bezpieczeństwo.
> Nowy design nie gwarantuje bezpieczenstwa, wrecz przeciwnie.

Myślę, że nie pojmujesz problemu: Linux jest tak strasznie
skomplikowanym systemem, że nie jesteś w stanie go przetestować. Nie
istnieje fizyczna możliwość odpowiedzi na pytanie "czy to bezpieczne"
ponieważ ten system ma tryliony punktów swobody wzajemnie zazębiajacych
się i generujacych nowe stany.

W przypadku systemu specjalizowanego, pisanego od zera, możliwość
pełnego testowania jest możliwa, jesteś w stanie ogarnąć znaczą, a może
i nawet cała zawartość, poprawnymi procedurami testowania.

Są przypadki w przemyśle, kiedy wymagane jest testowanie systemu, który
czymś steruje, w sposób formalny.

Linuxa nie da się przetestować inaczej jak "yyyy, no szwagier i jego
milion kolegów używają i chyba działa".

To czasami jest wystarczające, ale czasami nie.

>> Aby była 100% jasność: w urządzeniach sterujących, szczególnie typu
>> RT i infrastrukturze krytycznej, nie ma miejsca na rozwiązania
>> szybkie i tanie, a takim jest Linux.
> Oczywiscie, ze jest. W innym watku pisalem o patchach RT na kernel
> Linuxa, stosowanych z powodzeniem w przemysle.

Ten przemysł to szerokie pojęcie. Machanie serwem w sortowni śmieci to
innych kaliber niż hamowanie składu na zderzeniu czołowym. To, że Linux
może być RT, to nie oznacza, że to jest do, co chciałbyś mieć w ukłądach
sterowania pociągiem. To nie ta skala bezpieczeństwa.

>> Może być tak, że wyświetlacz w pociągu nie jest krytyczny i można
>> używać pociąg bez niego. Wtedy nie ma problemu. Acz zaczyna wtedy
>> pojawiać się pytanie: to po co on tam jest?
> Dla wygody? Dla redundancji? Dla serwisanta?

a) dla wygody? Odpala się z minutę. Jest słabo czytelny, na oko ten
ekran to jakieś tanie badziewie. Co złego w kilku kontrolkach i
wskaźnikach analogowych?

b) dla redundancji? A gdzie jest to pierwotne coś, co redundetuje?

c) Dla serwisanta? To po co one jest centralnie na konsoli?

> Od pociagu mozesz odpiac wagon, tez pojedzie. Tez zapytasz "to po co
> ten wagon byl?" ? Raz jechalem taborem TLK w wagonie bez drzwi, chyba
> je urwalo gdzies po drodze. Tez zapytasz "to po co te drzwi, skoro
> pociag dalej jedzie?" ? Itp. Itd.

Nie. Tutaj pytanie jest: jaki cel ma dublowanie wskaźników czytelnych,
bezpiecznych i sprawdzonych jakimś gównianym ekranem LCD.

W przypadku samolotu jestem w stanie pojąć argumentację: wskaźników jest
za dużo i się nie mieszczą, muszą być dynamiczne.

W przypadku pociągu tak nie jest.

Podpowiem: moda taka. Gówniana.

do góry

On 10/12/2023 22:32, Zbych wrote:
>>> Zrobi zdjęcie i wyśle geniuszu.
>> I co dalej? Kolega mu przedyktuje, żeby wszedł w tryb single user i
>> zeskanował dysk fdiskiem, geniuszu?
> A co zazwyczaj pracownik robi jak się pojawia problem?

Dzwoni po serwis z informacją "skład nie jedzie". Reszta dnia wolnego.

do góry

W dniu 10.12.2023 o 23:21, heby pisze:
> On 10/12/2023 22:32, Zbych wrote:
>>>> Zrobi zdjęcie i wyśle geniuszu.
>>> I co dalej? Kolega mu przedyktuje, żeby wszedł w tryb single user i
>>> zeskanował dysk fdiskiem, geniuszu?
>> A co zazwyczaj pracownik robi jak się pojawia problem?
>
> Dzwoni po serwis z informacją "skład nie jedzie". Reszta dnia wolnego.
>

Bumelka :-)

do góry

W dniu 10.12.2023 o 16:20, heby pisze:
...
>> Kiedy argumentowałem, że nie chcę takich rozwiązań ponieważ nie widzę
>> dla nich zastosowania w moim przypadku kontrowałeś, że chcę "wymyślać
>> koło na nowo".
>
> Jesli robisz domowy projekcik, albo nawet kompercyjny, konsumencki
> projekcik, typu zabawkowego, nalezy jak najwięcej czerpać z gotowców.
> Zawieszenie się tabletu dziacku spowoduje tylko płacz i traumę u
> przedszkolaka, gdy to samo w pociągu może doprowadzić do utraty życia.
>
> Przepychanie wszystkich czujników i sterowania przez jeden, deliktny
> system, jest naiwne. Linux, jako OS, może co najwyżej pełnić rolę
> nadzorcy nad układami, ale układy powinny być autonomiczne i mieć
> niezalezną możliwośc sterowania, pomijającą ten ekran (dotykowy?).
>
> Podobnie, przepytachnie wszystkch ukłądów przez centralny komputer jest
> naiwne. Znacznie bardziej neizawodne były by osobne elementy, pracujące
> autonomiczne i co najwyżej oczujnikowane.

Dlatego HA jest zabawką.

>
...
>
> Aby była 100% jasność: w urządzeniach sterujących, szczególnie typu RT i
> infrastrukturze krytycznej, nie ma miejsca na rozwiązania szybkie i
> tanie, a takim jest Linux.

Czego konkretnie spodziewasz się po innym systemie operacyjnym?

>
> Może być tak, że wyświetlacz w pociągu nie jest krytyczny i można używać
> pociąg bez niego. Wtedy nie ma problemu. Acz zaczyna wtedy pojawiać się
> pytanie: to po co on tam jest?
>

No hamować raczej można bez niego.

do góry

W dniu 10.12.2023 o 13:05, Mirek pisze:
> On 10.12.2023 12:29, io wrote:
>> W dniu 10.12.2023 o 10:43, Kamil Jońca pisze:
>>> io <i...@o...pl.invalid> writes:
>>>
>>> [...]
>>>>
>>>> Więc właśnie tak by to musiało być realizowane a hackerzy twierdzą że
>>>> pobrali kod, zmodyfikowali i wgrali bez większego trudu, pociąg
>>>> "naprawiony", więc zapomnij.
>>>
>>> O ile ja dobrze rozumiem. To  pobrali kod, zdebugowali, zrozumieli co
>>> trzeba przestawić w danych (jakieś flagi czy coś) i przestawili. Kodu
>>> nie zmieniali.
>>
>> Możliwe. Możliwość zmodyfikowania i wgrania mogła być tylko czyjąś,
>> niekoniecznie trafioną konkluzją, którą gdzieś wyczytałem w tych
>> materiałach medialnych. Coś to tam zmienia.
>
> Ostatecznie chyba Newag wgrał "poprawki" do kilkunastu pociągów.
> Co do hakerów, to tam piszą że nie do końca poznali kod, bo nie mieli
> disasemblera. Jeżeli kod nie był obfuskowany, to dane takie jak
> współrzędne geograficzne, data, czas, łańcuchy znaków itp, można łatwo
> znaleźć bez tego. Wystarczy zmodyfikować jeden czy kilka bajtów w tym
> miejscu żeby zdezaktywować działanie: np. datę zmienić na 30 lutego a
> współrzędne zmienić na Antarktydę. Oczywiście o ile spójność kodu nie
> jest sprawdzana. ale to też można obejść jeśli wiemy jak.
> BTW: Pod DOS-em była taka gierka "Żużel" - ona świetnie wykrywała
> niektóre wirusy, bo jak plik był zmodyfikowany to się nie chciała
> uruchomić. Nie wiem czy sprawdzana była wielkość pliku czy suma
> kontrolna, ale to działało.
>

Mogło nie być możliwości wgrania poprawianego programu, ale jeśli nawet
była to niekoniecznie należało to zrobić.

do góry

No i mamy odpowiedź hakerów i tak jak pisałem, ściąggają Newag-owi
majtki przez głowę
"0 grudnia grupa Dragon Sector wysłała do mediów swoje oświadczenie.
Zaznaczono w nim m.in., że ,,producent sterownika CPU831, firma
Selectron, nie udostępnia narzędzi bezpośrednio pozwalających pobrać kod
zainstalowany na sterowniku". Pozwoliła na to dopiero analiza i
stworzone przez Dragon Sector specjalne narzędzia.

Jesteśmy stuprocentowo pewni naszej analizy. Raporty techniczne
przygotowane na jej podstawie zostały przekazane współpracującym z nami
warsztatom, przewoźnikom oraz odpowiednim organom i instytucjom.
Zabezpieczyliśmy kopie wszystkich znalezionych przez nas wersji
oprogramowania ze wszystkich analizowanych przez nas pojazdów. Część
tych zabezpieczeń została wykonana komisyjnie wraz z udziałem
niezależnych audytorów.
- przekonują hakerzy.

Grupa nie ma wątpliwości: oprogramowanie zawierało złośliwy kod
symulujący usterki, aktywowany między innymi na podstawie współrzędnych
GPS warsztatów naprawczych konkurencyjnych dla Newag. Z analizy 29
pojazdów wynikało, że 24 z nich posiadało ,,mniej lub bardziej
zaawansowany system blokad". Hakerzy zwracają uwagę, że wraz z postępami
ich prac nowe oprogramowanie było pozbawiane mechanizmu odblokowywania
pociągów.

W odpowiedzi na stwierdzenie, że złośliwe fragmenty kodu miałyby
być wynikiem działania innych niż Newag podmiotów możemy stwierdzić, że
jest to dość nieudolna, a zarazem karkołomna linia obrony, gdyż
funkcjonalności zostały wprowadzone w sposób wskazujący na pełen dostęp
do kodu źródłowego programu. W kilku przypadkach pojazdy były wysłane do
Newag w celu naprawy, a my zgraliśmy kod tuż przed wysłaniem do Newag i
porównaliśmy z kodem zgranym tuż po powrocie z serwisu w Newag. Po
przyjeździe kod wgrany do sterownika zmienił się i w szczególności
zawierał istotne zmiany w logice blokady (przykładowo: wydłużono czas
postoju po którym pojazd się miał zablokować z 10 na 21 dni).
- dodają.

Hakerzy w swoim oświadczeniu piszą wprost:

uważamy, że Newag nie był świadomy, że możliwe jest wykrycie tej
ingerencji za pomocą inżynierii wstecznej i możliwości dokładnej analizy
funkcjonalności wgranej do sterownika - w szczególności obecności
sprawdzania koordynatów geograficznych GPS warsztatów konkurencji."

Wg mnie to już kompletnie rozstrzyga winę newag-u i wszystkie teorie
spiskowe.
Dali ciała po całości, chcieli mieć wyłączność na serwis ale sprawa się
rypła i teraz czekamy na konsekwencje tego. Myślę że już pewnie takie
są, na pewno stracą klientów albo klienci będą żądać pełnego kodu
sterowników i blokady zdalnej aktualizacji.



--
Janusz

do góry

On Mon, 11 Dec 2023 15:00:24 +0100, Janusz wrote:

> W odpowiedzi na stwierdzenie, że złośliwe fragmenty kodu miałyby
> być wynikiem działania innych niż Newag podmiotów możemy stwierdzić, że
> jest to dość nieudolna, a zarazem karkołomna linia obrony, gdyż
> funkcjonalności zostały wprowadzone w sposób wskazujący na pełen dostęp
> do kodu źródłowego programu. W kilku przypadkach pojazdy były wysłane do
> Newag w celu naprawy, a my zgraliśmy kod tuż przed wysłaniem do Newag i
> porównaliśmy z kodem zgranym tuż po powrocie z serwisu w Newag. Po
> przyjeździe kod wgrany do sterownika zmienił się i w szczególności
> zawierał istotne zmiany w logice blokady (przykładowo: wydłużono czas
> postoju po którym pojazd się miał zablokować z 10 na 21 dni).

Przy czym - wgrywanie najnowszej wersji oprogramowania, to może być
standardowa procedura serwisu.

Ale wydłuzenie ... czyżby zdarzały sie postoje przez 11 dni z innych
przyczyn?

> Wg mnie to już kompletnie rozstrzyga winę newag-u i wszystkie teorie
> spiskowe.
> Dali ciała po całości, chcieli mieć wyłączność na serwis ale sprawa się
> rypła i teraz czekamy na konsekwencje tego. Myślę że już pewnie takie
> są, na pewno stracą klientów albo klienci będą żądać pełnego kodu
> sterowników i blokady zdalnej aktualizacji.

Ba - ale żądać powinni od wszystkich dostawców, skoro to zamówienia
publiczne.
Kodów źródłowych mogą nie dostać, bo taka polityka firm, zreszta nie
wiadomo, czy binarki na pewno z nich pochodzą, ale odpowiednie
oswiadczenia, że nie zawierają, plus zobowiązanie do bezpłatnej pomocy
serwisowej się może pojawic.

I się zacznie wojna na kruczki - jak tu napisać instrukcje, zeby inny
serwisant sie pomylił, albo przeoczył, i wyszło na to, że to jego wina
:-)

No chyba, że po prostu skonczy się normalnie - będzie bez takich
numerów ...


J.

do góry

W dniu 11.12.2023 o 15:00, Janusz pisze:
> No i mamy odpowiedź hakerów i tak jak pisałem, ściąggają Newag-owi
> majtki przez głowę
> "0 grudnia grupa Dragon Sector wysłała do mediów swoje oświadczenie.
> Zaznaczono w nim m.in., że ,,producent sterownika CPU831, firma
> Selectron, nie udostępnia narzędzi bezpośrednio pozwalających pobrać kod
> zainstalowany na sterowniku". Pozwoliła na to dopiero analiza i
> stworzone przez Dragon Sector specjalne narzędzia.

Nic nowego, od początku było wiadomo, że wykorzystali debugowanie.

>
>     Jesteśmy stuprocentowo pewni naszej analizy. Raporty techniczne
> przygotowane na jej podstawie zostały przekazane współpracującym z nami
> warsztatom, przewoźnikom oraz odpowiednim organom i instytucjom.
> Zabezpieczyliśmy kopie wszystkich znalezionych przez nas wersji
> oprogramowania ze wszystkich analizowanych przez nas pojazdów. Część
> tych zabezpieczeń została wykonana komisyjnie wraz z udziałem
> niezależnych audytorów.
>     - przekonują hakerzy.
>
> Grupa nie ma wątpliwości: oprogramowanie zawierało złośliwy kod
> symulujący usterki, aktywowany między innymi na podstawie współrzędnych
> GPS warsztatów naprawczych konkurencyjnych dla Newag. Z analizy 29
> pojazdów wynikało, że 24 z nich posiadało ,,mniej lub bardziej
> zaawansowany system blokad". Hakerzy zwracają uwagę, że wraz z postępami
> ich prac nowe oprogramowanie było pozbawiane mechanizmu odblokowywania
> pociągów.

To już nawet tych blokad nie można odblokować?

>
>     W odpowiedzi na stwierdzenie, że złośliwe fragmenty kodu miałyby
> być wynikiem działania innych niż Newag podmiotów możemy stwierdzić, że
> jest to dość nieudolna, a zarazem karkołomna linia obrony, gdyż
> funkcjonalności zostały wprowadzone w sposób wskazujący na pełen dostęp
> do kodu źródłowego programu. W kilku przypadkach pojazdy były wysłane do
> Newag w celu naprawy, a my zgraliśmy kod tuż przed wysłaniem do Newag i
> porównaliśmy z kodem zgranym tuż po powrocie z serwisu w Newag. Po
> przyjeździe kod wgrany do sterownika zmienił się i w szczególności
> zawierał istotne zmiany w logice blokady (przykładowo: wydłużono czas
> postoju po którym pojazd się miał zablokować z 10 na 21 dni).
>     - dodają.

Gdzie tu zmiana logiki?

>
> Hakerzy w swoim oświadczeniu piszą wprost:
>
>     uważamy, że Newag nie był świadomy, że możliwe jest wykrycie tej
> ingerencji za pomocą inżynierii wstecznej i możliwości dokładnej analizy
> funkcjonalności wgranej do sterownika - w szczególności obecności
> sprawdzania koordynatów geograficznych GPS warsztatów konkurencji."

Nie padło wcześniej, że doszło do naruszenia bezpieczeństwa?

>
> Wg mnie to już kompletnie rozstrzyga winę newag-u i wszystkie teorie
> spiskowe.
> Dali ciała po całości, chcieli mieć wyłączność na serwis ale sprawa się
> rypła i teraz czekamy na konsekwencje tego. Myślę że już pewnie takie
> są, na pewno stracą klientów albo klienci będą żądać pełnego kodu
> sterowników i blokady zdalnej aktualizacji.
>

Nie padło wcześniej, że kod źródłowy jest dostępny i odbiorca może sobie
go samodzielnie skompilować i wgrać?

do góry