Zastanawiam się czy wszyscy specjalnie piszą tak, żeby zaciemnić krytyczny moment, żeby przypadkiem jakiś hakier nie zrozumiał o co chodzi
Opisałeś altcoin tylko pół prawdy czyli to jak tajne dane mogą znaleźć się w rejestrze C i B. Owszem tam trafiają, ALE po wykonaniu kroku 4 procesor już wie, że są to wartości z obszaru chronionego i nie pozwoli ich hakierowi użyć
dostałbyś wyjątkiem po twarzy próbując robić cokolwiek z zawartościami rejestrów C i B
Poprawiam programik tak, żeby zadział:
Kod: Zaznacz cały
Co robi HAKIER? - to prościutki programik:
krok 1. zadeklaruj tablicę 300 bajtów - to taka tabelka jak w Excelu
krok 2. do komórki tablicy nr 1 wpisz 1
krok 3. do komórki tablicy nr 2 wpisz 2
krok 4. każ procesorowi usunąć tabelkę z pamięci podręcznej
krok 5. załaduj do rejestru B liczbę 302
krok 6. jeśli zawartość rejestru B jest mniejsza niż wielkość tablicy, która umieszczona jest w pamięci o adresie 100000000 to przejdź do kroku 7. w przeciwnym wypadku do kroku 9.
krok 7. załaduj do rejestru C zawartość tablicy nr 301
krok 8. jeśli pierwszy bit rejestru C wynosi 1 to teraz wczytaj do rejestru B komórkę tablicy nr 1 w przeciwnym wypadku komórkę numer 2
krok 9. wczytaj do rejestru B komórkę tablicy nr 1 i zmierz ile czasu to trwało
krok 10. UWAGA! jeśli krok 9. trwał MNIEJ niż 80 nanosekund to znaczy, że bit numer 1 chronionej zawartości komórki tablicy nr 301 wynosi JEDEN w przeciwnym wypadku pierwszy bit komórki tablicy nr 301 wynosi ZERO
itd. dla kolejnych bitów od kroku 4. do kroku 10.
Co robi PROCEK?
krok 1. no to tworzymy tablicę, gdzieś daleko w pamięci
krok 2. wpisuje do tablicy nr 1 wartość 1
krok 3. o znowu wpisywanie do tablicy - żeby było szybciej przepiszę sobie 300b ramu do cache. Tylko gdzie? W cache mam już INIT/Kernel - te procesy są często używane, o i jeszcze jest 1000 procesów HAKIER z najwyższym priorytetem. Hmm - o tutaj przed INIT/KERNEL jest trochę wolnego - ładuję właśnie tutaj.
Wpisuję w cache do tablicy[2] wartość 2 - to chyba pisał jakiś lamer!
krok 4. super zwolni się trochę miejsca w pamięci podręcznej! Od tej pory nie wiem już co to za tabelka i jaką ma wielkość!
krok 5. nic strasznego
krok 6. O tutaj mam warunek, skok i sprawdzenie pamięci, której nie mam w cache - ta operacja będzie trwała bardzo długo, a ja jestem najwydajniejszym PROCKEIM więc zobaczę czy w tym czasie mogę zrobić coś jeszcze. Zarówno w krokach 7 jak i 8 można wykorzystać cache! Widzę że kompilator się postarał i zoptymalizował kod bo w trakcie żmudnego odczytywania ramu z korku 6 mogę wykonać kroki 7 i 8 i nic się nie stanie. Szkoda tylko że nie mogę ustawiać żadnych flag bo wartość warunku może się zmienić. Ale co tam robię kroki 7 i 8 przed 6.
Wpisuję do C zawartość tablicy [301] i sprawdzam jej pierwszy bit zależnie od tego czy wynosi 0 czy jeden zaczynam odczytywać komórkę tablicy 1 lub 2 i wczytuję ja do cache
O pamięć 1000000 już odczytałem i niestety okazuje się, że tych operacji które przed chwilą wykonałem nie mogłem wykonać, kurde. Dobra zatem co to ja mam teraz zrobić? Acha... wczytać komórkę nr 1 tablicy....
ale zaraz zaraz! przypadkiem tak się składa, że robiąc na wyrost niedozwolone operacje już ją wczytałem do cache! acha! więc jednak nie ma co się martwić, na marne ta robota nie poszła! zamiast wczytywać znowu z ramu wezmę ją sobie z cache!
hakier tylko na to czekał! sprawdza ile czasu operacja zajęła... jeśli zajęła krótko to zawartość komórki nr 1 siedziała w cache.... jeśli trwała długo to siedziała tam zawartość komórki nr 2
od czego to zależało? od tego czy 1 bit tajnej komórki 301 wynosił 1 czy 0!
w ten sposób właśnie poznałem 1 bit chronionej pamięci!
w żaden inny sposób procesor nie pozwoliłby mi go odczytać!!!
~
problem jest oczywiście bardzo wredny, bo uderza w całą przyjętą filozofię optymalizacji, to optymalizacja powoduje, że ten sam kod może się raz wykonać szybciej, a raz wolniej... zależnie od tego czym procesor się w międzyczasie zajmuje... analizując algorytmy procesora i czas wykonania kodu można pośrednio wnioskować co robił.... jeszcze nie jeden tego typu mechanizm będzie odkryty! oj nie jeden! to dopiero początek, ktoś pokazał gdzie jest słaby punkt i teraz wszyscy wiedzą gdzie szukać... słabym punktem jest upływ czasu
dlatego możliwości są dwie - albo popsucie optymalizacji albo przebudowa całego mechanizmu zarządzania czasem....
mi się marzy to drugie... wyobraźmy sobie co by było gdyby program wiedział z jaką prędkością się wykonuje i miał gwarancję, że to się nie zmieni.... te paski postępu wreszcie pokazujące prawdę