artykuły

Intel Core i7-3770K – pierwszy 22-nanometrowy procesor desktopowy

Testujemy Ivy Bridge!

214
23 kwietnia 2012, 18:00 Michał Grzegorz Wójcik, Mateusz Brzostek

Ulepszone rdzenie procesora

Ogólna budowa układu pozostała bez zmian: mamy do czynienia z czterema dwuwątkowymi rdzeniami x86, czterema blokami pamięci podręcznej L3, układem graficznym i częścią uncore, zawierającą kontrolery pamięci, zasilania, PCI Express, DMI i wyjścia obrazu. Wszystko to połączono dwukierunkową magistralą pierścieniową. W rdzeniach x86 w Ivy Bridge wprowadzono kilka dodatkowych funkcji i instrukcji.

DRNG – cyfrowy rzut monetą trzy miliardy razy na sekundę

Z szyfrowania danych korzystają dziś niemal wszyscy, więc nic dziwnego, że sprzętowe wspomagacze szyfrowania pojawiają się w większości procesorów. Obecne algorytmy potrzebują liczb losowych jako tak zwanych zarodków, z których algorytm generujący liczby pseudolosowe generuje klucze prywatne. W Ivy Bridge umieszczono sprzętowy generator liczb pseudolosowych, które mogą posłużyć jako zarodki. Jak to działa? Pierwszym etapem jest wspomniany cyfrowy rzut monetą. Polega na połączeniu ze sobą dwóch logicznych bramek NOT (zaprzeczenie logiczne) i podłączeniu wyjścia pierwszej do wejścia drugiej, i na odwrót.

Po podaniu sygnału zegarowego oba tranzystory włączają się na chwilę, a punkty pomiarowe przez moment znajdują się w stanie nieustalonym. Po chwili losowe fluktuacje atomów w bramkach NOT spowodują, że punkt pomiarowy z niestabilnego stanu przełączy się w logiczne zero lub jedynkę. Historia „rzutów” jest zapamiętywana i jeśli wyniki zaczynają wypadać z nierówną częstością, są odrzucane. Generator w Ivy Bridge zbiera 256 takich losowych bitów i traktuje je jako dane dla deterministycznego algorytmu generującego pseudolosowe ciągi liczb. Z jednego 256-bitowego zarodka generowane są najwyżej 1022 64-bitowe liczby, które przedstawia się jako wyniki instrukcji RDRAND, specjalnie po to wprowadzonej. Oczywiście, 1022 kolejne wygenerowane liczby mają ze sobą coś wspólnego, ale generujący je algorytm spełnia wymogi amerykańskiego instytutu NIST co do jakości liczb pseudolosowych. W Ivy Bridge jest jeden generator na cały układ – korzystają z niego wszystkie rdzenie.

Instrukcja RDRAND jest obsługiwana przez jądro Linuksa począwszy od wersji z sierpnia 2011 roku i ma być obsługiwana przez następną wersję OpenSSL. Jak zwykle na obsługę w systemach Microsoftu i windowsowym oprogramowaniu musimy jeszcze poczekać.

SMEP

Pamiętacie technikę NX-bit, zastosowaną pierwszy raz przez AMD w procesorach Athlon 64, a potem przez Intela pod nazwą XD-bit? Umożliwiono wtedy programistom oznaczenie strony w pamięci i zablokowanie możliwości wykonywania kodu z tej strony. Chodziło o zablokowanie mechanizmu wykorzystywanego czasem przez złośliwe oprogramowanie, w którym podmienia się dane programu na szkodliwy kod. SMEP (ang. Supervisory Mode Execution Prevention – 'blokada wykonywania w trybie systemu operacyjnego') jest rozwinięciem tamtej idei. W tej technice strony w pamięci mogą być oznaczone jako należące do „userlandu”, czyli programów uruchomionych przez użytkownika. Pozostałe należą do „supervisora”, głównego programu systemu operacyjnego, który obsługuje przerwania i przydziela zasoby sprzętowe innym programom. Supervisor i inne programy działające z najwyższym poziomem uprawnień nie mogą wykonać kodu ze strony oznaczonej jako należąca do użytkownika. Takie zabezpieczenie blokuje możliwość ataku na system operacyjny przez wykonanie nieautoryzowanego kodu z najwyższymi uprawnieniami.

Jest tylko kilka problemów. Po pierwsze, zalety SMEP są dostępne tylko w systemach operacyjnych, które obsługują tę funkcję. Odpowiednia łatka do Linuksa jest już od dawna dostępna, zresztą została przygotowana przez inżynierów Intela. Systemy Microsoftu jeszcze nie obsługują SMEP i nie wiadomo, kiedy zaczną. Po drugie, dokumentacja SMEP znajduje się na stronie Intela od niecałego roku, więc twórcy „exploitów” mogli już dawno temu zapoznać się z zasadą jej działania, znaleźć nowe luki w zabezpieczeniach i wykorzystać je w swoim kodzie. Mateusz Jurczyk, ekspert od zabezpieczeń z firmy Google, podaje kilka sposobów ominięcia SMEP. Zwraca też uwagę na potencjalny problem z obsługą SMEP w Windows: wiele niefachowo napisanych sterowników robi dokładnie to, co SMEP próbuje zablokować, i te sterowniki po prostu nie będą działać jak należy. Według Dana Rosenberga, eksperta z firmy Virtual Security Research, samo wprowadzenie SMEP nie poprawia znacząco bezpieczeństwa systemów operacyjnych, ale w połączeniu z dodatkowymi zabezpieczeniami w tych systemach może istotnie utrudnić pisanie exploitów. Dla przeciętnego użytkownika korzystającego z Windows nie ma to na razie większego znaczenia: jeśli już obsługa SMEP pojawi się w tym systemie, to i tak zablokuje tylko starsze złośliwe oprogramowanie.

3