Zadanie 4: Powrót Kalkulatora Wyborczego

Data ogłoszenia: 06.06.2019

Termin oddania: 05.09.2019 (brak możliwości spóźnienia)

Materiały dodatkowe

• parse.py: narzędzie do wyświetlania danych z ulepszonych plików core

• z4-test.tar.gz: testy do zadania

Wprowadzenie

Niestety, nie wszystkie rozwiązania pierwszego zadania spełniły nasze oczekiwania – w niektórych okręgach wyborczych, Kalkulator Wyborczy zakończył działanie śmiertelnym sygnałem SIGSEGV. Ze względów bezpieczeństwa, nie możemy używać debuggera na maszynach liczących głosy – dostaliśmy jedynie zrzuty core wytworzone przez nasz Kalkulator. Przy analizie tych zrzutów pojawił się poważny problem: przyczyna błędów leży najprawdopodobniej w kodzie obsługi plików, a zrzuty core nie zawierają żadnych informacji o otwartych plikach w momencie awarii programu.

Zadanie

Dopisać do kodu tworzącego pliki core w jądrze kod zrzucający tablicę otwartych plików w momencie śmierci procesu, pozwalając nam na zdebugowanie kodu przed jesiennymi wyborami.

Szczegóły

Ponieważ jeden plik core może zawierać wiele wątków z różnymi tablicami deskryptorów (przypadek CLONE_VM bez CLONE_FILES), plik powinien zawierać osobny zrzut tablicy deskryptorów dla każdego wątku (analogicznie do zrzutów rejestrów). Każdy z tych zrzutów powinien być jedną strukturą ElfXX_Note o nazwie LINUX i nowo zdefiniowanym typie NT_FDS (numeryczna wartość 0x4f4453). Struktura ta powinna być umieszczona bezpośrednio po wszystkich strukturach opisujących stan rejestrów danego wątku. Zawartość (pole desc) tej struktury powinna być następująca:

• uint32_t num_fds: liczba otwartych deskryptorów

• dla każdego deskryptora, po kolei:

  • uint32_t fd: numer deskryptora,

  • uint32_t flags: flagi pliku (pole f_flags w struct file),

  • uint64_t pos (niekoniecznie wyrównane): pozycja w pliku (pole f_pos),

  • uint32_t mode: tryb otwarcia pliku (pole f_mode),

  • uint32_t domain: jeżeli plik jest socketem, domena socketu (czyli stała AF_*), w przeciwnym wypadku -1,

  • uint32_t type: jeżeli plik jest socketem, typ socketu (czyli stała SOCK_*), w przeciwnym wypadku -1,

  • uint16_t local_addr_len jeżeli plik jest socketem i ma lokalny adres, rozmiar lokalnego adresu w bajtach, w przeciwnym wypadku 0,

  • uint16_t remote_addr_len jeżeli plik jest socketem i ma zdalny adres, rozmiar zdalnego adresu w bajtach, w przeciwnym wypadku 0,

  • uint8_t local_addr[local_addr_len]: jeżeli plik jest socketem, lokalny adres (czyli to, co zwróciłoby getsockname),

  • uint8_t remote_addr[remote_addr_len]: jeżeli plik jest socketem, zdalny adres (czyli to, co zwróciłoby getpeername),

  • char path[]: ścieżka do pliku, zakończona bajtem zerowym. W przypadku plików specjalnych (socket, pipe, …), należy użyć tej samej sztucznej nazwy, co system plików proc,

  • uint8_t _pad[]: tyle bajtów zerowych, ile potrzeba, by wyrównać pozycję do 4 bajtów.

Do weryfikacji, że dane są zrzucane w poprawnym formacie, dostarczamy skrypt parse.py.

Zasady oceniania

Za zadanie można uzyskać do 10 punktów. Na ocenę zadania składają się dwie części:

• funkcjonalność rozwiązania:

  • brak specjalnej obsługi socketów – wypełnienie pól domain/type/*_addr stałymi wartościami (0 punktów)

  • pełne rozwiązanie z obsługą socketów (2 punkty)

• wynik testów (od 0 do 8 punktów)

• ocena kodu rozwiązania (od 0 do -10 punktów)

Punktacja

Testy weryfikujące działanie socketów były warte 2 pkt., a pozostałe testy - 8pkt.

Punkty z oceny kodu:

1. Niepoprawna postać rozwiązania / nienakładający patch (-2.0)

2. Brak README (-0.1)

3. Copy-paste kodu (wiele funkcji zamiast makra) (-0.0)

4. Wyciek pamięci (-0.5)

5. Nadmiarowy diff (zmiany dot. wyłącnie białych znaków) (-0.0)

6. Dodawanie stałej (małej) liczby bajtów local_addr / remote_addr do core (-0.5, tylko jeśli przechodzą testy)

7. Użycie polskiego nazewnictwa (-0.2)

8. Definicja typu NT_FDS w niestandardowym miejscu / brak definicji (-0.0)

9. Race condition – możliwoć wystąpienia zmiany stanu między obliczaniem potrzebnej pamięci a momentem kopiowania (-0.5)

Forma rozwiązania

Jako rozwiązanie należy wysłać paczkę zawierającą:

• patcha na jądro w wersji 4.20.8, w jednym z następujących formatów:

  • patch wygenerowaniy przez diffa z opcjami -uprN nakładający się przez patch -p1

  • git format-patch

• krótki opis rozwiązania

Rozwiązania prosimy nadsyłać na adres p.zuk@mimuw.edu.pl z kopią do mwk@mimuw.edu.pl.