Ulepszanie funkcji skrótu
Amir Godstein opublikował małą łatkę do funkcji jądra, która tworzy unikalne wartości skrótu (hash) dla wejściowego ciągu znaków. Zauważył, że w przypadku 64-bitowych wartości, zanim skrót zostanie obliczony, niektóre bity są gubione, przez co cały proces odbiegał od ideału. Dla ciągów 32-bitowych, nie było takiej utraty i dlatego kod pozostał niezmieniony. Ponieważ jednak odpowiedzialny za to plik stringhash.h nie miał oficjalnego opiekuna, a zmiany wprowadzał w nim dawniej Linus Torvalds, Amir poprosił Linusa o opinię na temat łatki i porady dotyczące testowania zmiany. Jak to określił: „Nie wiem nawet, od czego zacząć testy lub jak udowodnić, że problem rzeczywiście istnieje”.
Linus próbował sobie przypomnieć, o co chodziło. Powiedział, że bity prawdopodobnie były gubione umyślnie, ale przyznał, że „to było dawno temu i od tego czasu zmieniliśmy trochę funkcję skrótu”.
Jednak Linus powiedział też: „mylisz się, mówiąc, że dla 32 bitów jest to no-op. W tym wypadku również występuje bardzo drogie i bezcelowe mnożenie, nawet jeśli przesunięcie nic nie zrobi. Tworzenie wartości skrótu dla nazw może być dosyć drogie”.
Amir poprawił Linusa, mówiąc, że nie powiedział, że łatka byłaby no-op (no-op to kod, który nic nie robi), ale że pozostawił kod dla 32 bitów niezmieniony, oprócz przesunięcia, o którym wspomniał Linus.
Linus zauważył, że chociaż przesunięcie nic nie kosztuje, to wywołanie __hash_32() użyte w tym miejscu jest bardzo kosztowne. Stwierdził więc: „wydaje się, że łatka nic nie wnosi, poza kosztem”. Dodał: „Robiliśmy w pewnym momencie obliczenia. Liczy się to, jak dobre są wartości skrótu. Jeśli mam przyjąć łatkę, to muszę widzieć, że rzeczywiście usprawnia cały proces, tak, że usprawiedliwi to dodatkowy koszt”.
Amir odpowiedział, że to nie jego łatka dodała wywołanie __hash_32(). Ono już tam było.
Wtedy Linus odpowiedział: „Kurczę, mój błąd. Rzeczywiście to już tam było. Muszę sprawdzić historię zmian tego kodu”.
Kilka dni później, napisał trochę więcej:
„Przyjrzałem się łatce i wycofuję co do niej wszystkie moje zastrzeżenia. Miałeś rację, a ja źle to zinterpretowałem lub po prostu głupio się zachowałem.
Nie martwi mnie też za bardzo możliwy spadek wydajności na 64 bitach, ponieważ większość architektur dbających o wydajność nie korzysta z tego zbyt wiele (kod dcache jest najlepszy pod względem wydajności, ale w przypadku działania słowo po słowie i tak używane są osobne funkcje skrótu).
W efekcie kod ten jest używany w systemach plików, które same obliczają wartości skrótów (zwykle dlatego że potrzebują funkcji porównujących, które będą niewrażliwe na wielkość znaków).
_Drobnym_ problemem jest tylko to, że nie wszyscy używają DCACHE_WORD_ACCESS. W takim przypadku koszty mogą być większe na architekturze 64-bitowej, na której nie ma szybkich mnożników (a może nawet w przypadku, kiedy są one obecne).
Jednak realistycznie patrząc, jedyna taka architektura, która mi przychodzi do głowy, to PA-RISC. Nikt nie dba na niej o wydajność. Jest to typ platformy, którym dzieciaki się chwalą, jeśli chcą pokazać, że mają coś egzotycznego.
Myślę wiec, że twoja łatka jest dobra, a wszystkie moje początkowe wątpliwości wynikały z tego, że źle na to spojrzałem.
Przepraszam”.
Linus dodał też: „*Chciałbym* zobaczyć szacowania rozkładu wartości skrótu po tych zmianach. Posiadasz może coś takiego? Funkcja ta jest tak zaprojektowana, że górne bity powinny być wykorzystane do porcjowania skrótu, więc sprawdzenie rozmiarów porcji (bucket) dla (powiedzmy) około 12 górnych bitów, dla prawdziwych danych, byłoby pomocne”.
Amir odpowiedział: „Dodałem do dcache liczniki porcji i śledzenie liczby wpisów/liczby niepustych porcji oraz największej porcji (z dołączoną łatką). Powiększyłem d_hash_shift, tak aby pobierane było tylko 12 bitów dla wartości tablicy mieszającej. Wyniki trochę się różnią w poszczególnych przebiegach. Poniżej przedstawiłem rezultaty testów przeszukania 55K wpisów, zaraz po rozruchu. Okazuje się, przynajmniej w tym wypadku, z uproszczoną analizą porcji, łatka nie wpływa na wydajność. Rozkład porcji przed i po wprowadzaniu łatki jest również zbliżony do wyników działania słowo po słowie”.
Załączył wyniki i na tym wątek się zakończył.
Stałe wartości, modyfikowane w czasie rozruchu
Niektóre części jądra pracują tak intensywnie, że nawet niewielki narzut spowodowany przypisaniem wartości do zmiennej może powodować różnicę w szybkości działania. Kirill A. Shutemov opublikował ostatnio łatkę wprowadzającą „modyfikowane wartości stałe”. Są to wartości stałe, które można ustawić w czasie rozruchu jako część konfiguracji jądra lub przez użytkownika z pomocą wiersza poleceń programu rozruchowego. Po ustawieniu zachowują się w jądrze jak prawdziwe wartości stałe, a nie zmienne.
Kirill wyjaśniał: „Modyfikowane wartości stałe wprowadzone są przez zastąpienie stałych wywołaniami funkcji otwartej (inline), zwracającymi wartości z wykorzystaniem kodu asemblera. W kodzie tym, w oddzielnej sekcji, podajemy lokalizację instrukcji ładującej stałą. W ten sposób możemy później odnaleźć lokalizację i dostosować wartość”.
Powodem, dla którego Kirill chciał wprowadzić taką opcję, było rozwiązanie konkretnego problemu ze zmienną _PHYSICAL_MASK. Aby wykonać szyfrowanie pamięci, musiało być możliwe dynamiczne jej ustawianie. Jednak ponieważ szyfrowanie pamięci wpływa na szybkość działania wszystkiego innego, Kirill chciał znaleźć sposób na pozbycie się tak wielu instrukcji jak to tylko możliwe. Wprowadzone przez niego zmiany rozwiązały ten problem.
Kirill stwierdził, że koszt wprowadzenia działania jego łatki jest akceptowalny. Powiedział: „Konwersja ta sprawia, że GCC generuje gorszy kod. Zmiana __PHYSICAL_MASK na modyfikowalną stałą dodaje 5k do .text w defconfig i sprawia, że troszkę wolniej działa (na mojej maszynie o około 0,2%)”.
Okazuje się więc, że próba przyspieszenia jednego fragmentu kodu spowalnia inną część. Kirill zauważył, że publikuje tę łatkę nie po to, by ją włączać do jądra, ale w nadziei, że ktoś może mieć lepszy pomysł na to, jak wykorzystać modyfikowalne stałe, bez zwiększania kosztu.
Linus Torvalds odpowiedział:
„Myślałem o czymś bardzo podobnym do twojego rozwiązania, które jest jednak zbyt uproszczone. Wrzucasz wszystkie stałe do rejestru, chcąc osiągnąć najbardziej optymalny kod wyjściowy. Dodatkowo wymuszasz dużą instrukcję movabsq, która jest naprawdę olbrzymia i prawie nigdy nie jest potrzebna. Razem z wykorzystaniem rejestru cały kod jest bardzo rozbudowany”.
Dodał: „Chciałem, aby można było zamienić takie rzeczy jak na przykład przesunięcie o zmienną, którą określamy raz, na przesunięcie o stałą ustawianą w czasie rozruchu. Oznacza to, że dosłownie aktualizujemy 8-bitową wartość w samej instrukcji przesunięcia”.
Opublikował fragment kodu w asemblerze i pokazał, jak kilka wierszy kodu można logicznie przekształcić w jeden, dzięki czemu wynikiem będzie „dużo krótszy kod, a rejestr %rcx nie będzie w ogóle używany. Nie zgubimy też D$ przy ładowaniu tej stałej (jest to stała zależna od ustawień definiowanych przy rozruchu)”. Kontynuował, mówiąc: „Jest to bardziej skomplikowane, ale więcej zyskujemy. Kod będzie lepszy i krótszy, chociaż wymaga dość problematycznej *infrastruktury*”.
Odniósł się do dyskusji sprzed 18 miesięcy, w której H. Peter Anvin pracował nad podobnym zagadnieniem. Peter określił je jako „wredny pomysł na niby-samo-modyfikujący się kod”. Nie ukończył go jeszcze, gdyż po drodze wszystko się skomplikowało.
Peter odpowiedział: „Pracuję właśnie nad bardziej kompleksowym zestawem łatek dla tego problemu. Rozwiązanie jest już dość zaawansowane i wspiera większość operacji”. Dodał: „Łatki są gotowe w 85%. Kod musi jeszcze zostać wyczyszczony, przetestowany i podzielony na sensowne kawałki”. Następnie stwierdził: „Głównym powodem, dla którego jeszcze tego nie opublikowałem, jest to, że podszedłem do sprawy zbyt ambitnie i chciałem obsłużyć cały zestaw bardziej skomplikowanych przypadków, tak jak przesunięcia 64-bitowe na jądrze 32-bitowych. Zysk jest całkiem spory, ale wymaga aktualizacji kodu w zależności od danych, a nie tylko aktualizacji zmiennej w kodzie, przez co potrzebne jest powiększenie alternatywnego frameworka”.
Na tym dyskusja się zakończyła.
Ponieważ otwarte oprogramowanie jest bytem zdecentralizowanym, dublujące się projekty, tak jak w tym przypadku, czasami się zdarzają, często oznaczając mnóstwo zmarnowanej pracy i dyskusje, które rozwiązanie jest lepsze. Jednak w tym wypadku, biorąc pod uwagę, że Kirill opublikował swoją łatkę, ponieważ nie mógł znaleźć rozwiązania problemu, nie wygląda na to, aby pojawiły się jakieś kontrowersje. Przynajmniej jeśli chodzi o decyzje, które zmiany wprowadzić do jądra. Pojawi się pewnie dyskusja, czy warto dodawać tak dużo skomplikowanych rozwiązań, aby obsługiwać samomodyfikujące się stałe. Może się okazać, że łatka jest podatna na błędy i trudna w zarządzaniu tak, że wady wynikające z jej wprowadzenia przewyższać będą zalety.
Działania związane z wadą projektową Intela
W ostatnim czasie poważne wady w projekcie mikroprocesorów Intela wymusiły wprowadzanie aktualizacji do wielu systemów operacyjnych, wliczając w to Linuksa. KarimAllah Ahmed opublikował łatkę do kontroli IBS (Indirect Branch Speculation – przewidywania rozgałęzień), próbując opanować wadliwe rozwiązania układów Intela, aktywując je, kiedy jest bezpiecznie i są potrzebne, oraz blokując, kiedy mogą naruszać bezpieczeństwo systemu.
Linus odpowiedział: „To się kupy nie trzyma. Czy Intel naprawdę planuje tworzyć tak gównianą architekturę? Czy ktokolwiek rozmawiał z nimi i powiedział im, że są k*wa nienormalni? Proszę, inżynierowie Intela, pomówcie z waszymi menedżerami”.
David Woodhouse powiedział: „Jeśli alternatywą było wycofanie produktów sprzedawanych od 20 lat i zaoferowanie każdemu darmowych procesorów, to nie jestem pewien, czy jest to tak zupełnie szalone”. Zgodził się, że łatka KarimAllaha to „paskudne obejście”, ale dodał: „hej – świat stanął w ogniu, a my nie musieliśmy dzięki tej łatce wyłączać ośrodków obliczeniowych i wracać do wypasu kóz, więc w sumie nie wyszło tak źle”.
Linus odpowiedział: „Widzę, że łykasz ich propagandową papkę. Proszę, dodaj szczyptę krytyki. Ponieważ nie jest to papka, dzięki której będziesz miał piękne wizje, ale taka, od której roztopi ci się mózg”.
Kontynuował, mówiąc, że to „paskudne obejście” to tylko początek problemów.
Najpierw Linus zauważył: „To, że podawane są dane na temat procesora, pokazuje, że Intel planuje odpowiednio rozwiązać problem Meltdowna (główne pytanie brzmi: _kiedy_). Nie jest to wielką niespodzianką, gdyż powinno to być łatwe do naprawy, a w tej chwili jest to olbrzymia dziura w zabezpieczeniach. Inne działania byłyby nie do zaakceptowania”.
Jednak dalej stwierdził: „jednak śmieciowy mechanizm IBRS (ograniczone przewidywanie rozgałęzień) pokazuje, że Intel _nie_ ma zamiaru załatwić problemu we właściwy sposób. Prawdę mówiąc, jest to całkowicie nieakceptowalne”.
Kontynuował:
„Całe to rozwiązanie z IRBS_ALL mówi jasno: «Intel nie podchodzi do sprawy na poważnie i będziemy mieli paskudne obejście, które będzie tak kosztowne, że domyślnie będzie wyłączone, ponieważ źle wpływa na testy wydajności».
Zamiast tego próbują zepchnąć ten bałagan na nas. Robią to wyjątkowo niedobrze, nawet z technicznego punktu widzenia.
Jestem pewien, że gdzieś tam prawnicy już stwierdzili: «musimy tak zrobić, żeby nie można nas było pozwać». Jednak prawne powody nie sprawią, że technologia będzie dobra, nie powstanie dzięki nim dobra łatka”.
Wcześniej, David zauważył: „Potrzebujemy mechanizmu IBPB (blokada przewidywania), aby uzupełnić ochronę, jaką nam daje Retpoline, chyba że wolimy odbudować całą przestrzeń użytkownika z wykorzystaniem Retpoline”. Linus odpowiedział:
„BZDURA.
Czy _widziałeś_ łatki, o których mówisz? Powinieneś – kilka z nich nosi twój podpis.
Łatki te wprowadzają śmieciowe wpisy z MSR na wejście/wyjście jądra. To jest szaleństwo. Dają przekaz mówiący: «chcemy ochronić jądro». A w tym miejscu już mamy mniej kosztowne Retpoline.
Ktoś tu więc nie mówi całej prawdy. Ktoś przepycha te śmieci z niezrozumiałych powodów. Przepraszam, ale musiałem o tym wspomnieć.
Jeśli chodziłoby o czyszczenie bufora BTB w czasie przełączania kontekstu pomiędzy użytkownikami, uwierzyłbym w to. Jednak łatki się tym nie zajmują.
W obecnej postaci, łatki te, to ZWYKŁA KUPA ŚMIECI.
To, co robią, to po prostu szaleństwo. Rzeczy, które nie mają sensu. Z tego powodu wszystkie twoje argumenty są wątpliwe i podejrzane. Działanie tych łatek nie jest normalne.
CO TU SIĘ U LICHA WYPRAWIA?
Ignorowana jest znacznie bardziej _groźna_ rzecz: jakiś idiota dosłownie fatalnie zaprojektował cały interfejs sprzętowy.
Fatalny projekt wynika z dwóch głównych rzeczy:
- pierwszym jest to, że interfejs oznacza, że Intel nigdy nie naprawi błędu.
Zobacz różnicę pomiędzy IBRS_ALL, a RDCL_NO. Jedno sugeruje, że Intel coś naprawi. Drugie nie. Czy myślisz, że można takie coś zaakceptować? - drugi powód jest taki, że nie ma wskaźnika wydajności.
Informacje na temat procesora i zmiennych z mikroarchitektury możemy wykorzystać do podjęcia decyzji. Jednak, skoro już wiemy, że narzut z IBRS na istniejącym sprzęcie jest olbrzymi, wszystko to, co się mówi o możliwościach sprzętowych, jest zwykłą kupą śmieci. Nikt normalny nie wykorzysta tych łatek, gdyż koszt jest zbyt duży. Koniec końców i tak będzie trzeba sprawdzać «którą wersję procesora mamy».
Potrzebujemy czegoś lepszego niż te śmieci”.
David w pełni się z tym zgodził. Intel, zamiast opcjonalnej łatki, powinien po prostu naprawić błąd, gdyż pozostawianie otwartych drzwi jest nie do zaakceptowania. Uważa jednak, że w przypadku jądra krótkoterminowe niezbyt piękne rozwiązanie jest w porządku, ponieważ jest tymczasowe.
Zauważył też, że Linus sprawdzał nieodpowiednie rozwiązanie, kiedy narzekał na łatki, gdyż mówił o IBRS, zamiast o IBPB. Linus odpowiedział: „Ech. Dziwaczne szczegóły nazewnictwa Intela”. Dodał: „Jeśli przyjrzysz się tej serii łatek, to zobaczysz, że działają one tak jak opisałem: na wejście/wyjście jądra. To była łatka numer 10, spośród 10 w serii. W sumie to właśnie zmiana, o której pisałem, która zaczęła tworzyć ten bałagan. Nie chcę widzieć takich śmieciowych łatek bezmyślne rozsyłanych dookoła”.
David odpowiedział, w ciekawy i użyteczny sposób, podsumowując całą sytuację. Napisał:
„Myślę, że omówiliśmy techniczną stronę problemu. Nie mówię, że ją lubisz, chyba nikt z nas jej nie *lubi*. Ponieważ jednak zebrała się tu dosyć duża widownia, warto wytłumaczyć to wszystko, ze względu na nią.
Wszystko to dotyczy błędu Spectre w wariancie 2, w którym procesor może zostać oszukany i błędnie przewidzieć rozgałęzienie. Ja sprawdzam, co możemy zrobić na *aktualnym* sprzęcie, gdzie jesteśmy ograniczeni tym, co można dodać do mikrokodu.
Nowy mikrokod od Intela i AMD wprowadza trzy rozwiązania.
Pierwszym jest IBPB, czyli całkowita blokada przewidywania rozgałęzień. Po włączeniu żadne z rozgałęzień poznanych wcześniej nie będzie użyte. Rozwiązanie to jest kosztowne (około 4000 cykli).
Drugie – STIBP chroni wątki współbieżne w technologii Hyper-threading (HT) przed podążaniem za rozgałęzieniami rozpoznanymi w innych wątkach. *Może* to być przydatne, kiedy uruchamiamy niezwiązane ze sobą procesy w przestrzeni użytkownika lub różne maszyny wirtualne z technologią HT.
Trzecim, bardziej skomplikowanym rozwiązaniem, jest IBRS. Zaprojektowano je, aby działało, kiedy wchodzimy w tryb uprzywilejowany (tak jest w przypadku jądra). Zapobiega wykorzystaniu rozgałęzień poznanych w mniej uprzywilejowanych trybach, ZANIM ZOSTAŁO WŁĄCZONE. Nie jest to jednak rozwiązanie typu «ustaw i zapomnij». Posiada składnię przypominającą blokadę i musi być ustawione przy *każdym* wejściu do jądra (z przestrzeni użytkownika lub maszyny wirtualnej). *Również* jest drogie. Paskudne obejście, ale na razie to wszystko, co mamy.
Nawet w przypadku IBRS procesor nie rozróżni procesów przestrzeni użytkownika i różnych maszyn wirtualnych. Dlatego, oprócz IBRS-a, potrzebujemy blokady IBPB przy przełączaniu kontekstu i dla vmexit, oraz dodatkowo, w czasie uruchomienia maszyn wirtualnych, przyda się też pewnie STIBP.
Wtedy pojawił się Paul ze sprytny planem: «Hej, przewidywanie rozgałęzień może być niebezpieczne? A co tam, lepiej w takim razie wywalić *tę opcję*». To właśnie jest Retpoline. Jest to *znacznie* szybsze, niż uruchamianie IBRS dla każdego odwołania do jądra. Wydajność jest znacznie lepsza.
Teraz, *w większości* przypadków nie potrzebujemy IBRS-a. Tworzymy oprogramowanie z wykorzystaniem Retpoline, a IBPB działa przy zmianie kontekstu i przy poleceniu vmexit (jest to pierwsza część tej serii łatek, jeszcze przed dodaniem IBRS-a), a my jesteśmy bezpieczni. Zmieniliśmy nawet serię łatek, tak żeby Retpoline był pierwszy.
Zauważcie, że napisałem *w większości*. Nie każdy posiada kompilator Retpoline. Niestety, osoby takie muszą zaktualizować system.
Jest też jeszcze mikroarchitektura Skylake, czyli cała rodzina rdzeni procesorów. Są one, z dość złożonych powodów, podatne na ataki nie tylko przy przewidywaniu rozgałęzień, ale też w innych przypadkach (jak na przykład kiedy mamy ponad 16 wywołań w technologii deep chain).
Rozwiązanie IBRS, chociaż jest paskudne, to zajmuje się tym problemem. W przeciwieństwie do Retpoline. Istnieją już łatki wykrywające i powstrzymujące powstawanie problemów ze stosem oraz inne zagrożenia w tej architekturze, jednak również i one nie są zbyt piękne. Trzeba *przyznać*, że wydajność IBRS-a na obecnej generacji procesorów nie jest tak zła jak w przypadku starszych generacji. Dlatego może warto *rozważyć* skorzystanie z rozwiązania Intela.
To jest powód, dla którego pierwotnie chciałem, tak jak to zaimplementowano w pakiecie łatek, aby trzymać się IBRS-a na Skylake i wykorzystać Retpoline wszędzie indziej. Dostajemy «śmieciowe łatki», ale nie można mówić, że były «bezmyślnie dookoła rozsyłane». Jeśli chcemy pozbyć się IBRS-a i akceptujemy jego ograniczenia, róbmy to świadomie, wiedząc, jak to będzie wyglądać, a nie tylko po cichu odrzucamy rozwiązania, dlatego że biedny Davey za bardzo się boi, że Linus znowu na niego nakrzyczy. :)
Widziałem *pobieżne* analizy sytuacji ze Skylake, które chociaż nie spędzały mi snu z powiek, to też nie były w stanie poprzeć konkretnymi danymi stwierdzenia, że wszystko jest w porządku.
Jeśli Retpoline uważane jest za optymalizujące wydajność, a tak było na początku przedstawiane, to nie oznacza, że można mówić: «cóż, ono jest tylko *troszkę* niebezpieczne, ale działa szybko i sprawnie, więc tak to zrobimy».
No dobrze, mogę zaakceptować rezygnację z IBRS-a do ochrony jądra. Taka decyzja mnie nie zaskoczy. Nie bez powodu umieściliśmy go na końcu, jako najbardziej kontrowersyjną i zbędną część. Byłbym *szczęśliwszy* ze spójnej analizy pokazującej, że architektura Skylake nie będzie miała problemów, ale cóż, olać Skylake.
Wczesna partia w serii łatek dodaje nowe opcje i wykrywa, kiedy można wyłączyć KPTI na procesorach Intela, które nie są podatne na Meltdown, a także wspiera barierę IBPB, której potrzebujemy, aby uzupełnić Retpoline. Myślę, że tyle właśnie *chcemy* zrobić. Część z nas pracowała już nad tym. Ktoś z nas pewnie opublikuje te zmiany w ciągu kilku dni.
Myślę, że powinniśmy też wprowadzić IBRS dla maszyn wirtualnych, nawet jeśli my z tego nie skorzystamy. Tak jest pod Windowsem (i pod RHEL, hurra!).
Chciałbym, abyśmy przestali na siebie krzyczeć i rozpoczęli rzeczową dyskusję. Powinniśmy określić, kiedy, jeśli w ogóle, wprowadzamy IBPB dla przełączania kontekstu (sugerowane było zarówno ptrace, jak i dumpable) i czy, jeśli w ogóle, włączymy STIPB w przestrzeni użytkownika”.
Luke Kenneth Casson Leighton podziękował Davidowi za wyjaśnienia, mówiąc: „To co robisz, przynosi korzyści, podczas gdy reszta tylko się przygląda”. Powiedział: „Sytuacja jest trudna, gdyż inżynierowie Intela (i AMD) mają zakaz zwracania się bezpośrednio do ciebie, gdyż współtworzą mikrokod... Ignoruje się ich i demoralizuje. Ich menedżerowie nie wyciągają odpowiednich wniosków, pomimo że szef grupy odpowiedzialnej za otwarte oprogramowanie w Intelu od lat próbuje im przekazać, że powinni OPUBLIKOWAĆ MIKROKOD I OPROGRAMOWANIE SPRZĘTOWE NA OTWARTEJ LICENCJI”.
Następnie kontynuował: „Niestety problem spadł na was, na członków zespołu odpowiedzialnego za jądro Linuksa. Musicie czytać między wierszami i dawać jasne deklaracje tu, na LKML, tak, że inżynierowie Intela, którzy NIE MOGĄ się do was odzywać bezpośrednio, będą chociaż mieli jakiekolwiek informacje zwrotne... Dajcie *im* znać, że rozumiecie techniczną stronę problemu, mimo że nie macie dostępu do mikrokodu”.
W międzyczasie do Davida dołączył Ingo Molnar i wielu innych, pracujących nad techniczną stroną tworzenia nowych łatek, w celu rozwiązania różnych kwestii.
Wyraźnie widać, że sprawa rozgoryczyła programistów jądra. Jak w pewnym momencie napisał Pavel Machek: „Ktoś w Intelu wzniecił światowy pożar. Przez pół roku sprzedawali wadliwe procesory, a świat płonął. Wiedzieli, że były wadliwe, a i tak je sprzedawali. Potem Intel mówił, jak to są wspaniali, jak ważne jest dla nich bezpieczeństwo... Umyślnie mieszali Meltdown i Spectre, żeby nie było widać, jak bardzo nawalili. O przeprosinach również zapomnieli”.
Dalej kontynuował: „A teraz Intel chce oszukiwać na testach wydajności, utrudniać pracę w firmach, które dobrze wykonują swoje zadania, i uważa, że wszystko jest w porządku, dlatego że świat płonie? W tym momencie uważam, że owszem, wycofanie produktów powinno nastąpić. Jeśli Intel nie chce załatwić sprawy samodzielnie, to może sądy powinny go zmusić. Może to zaboli, ale myślę, że ci, którzy są odpowiedzialni za sprzedawanie wadliwych procesorów, powinni wylądować za kratkami”.
Dyskusja była jeszcze kontynuowana i omawiano sprawy techniczne.
Poza negatywnymi odczuciami w stosunku do Intela cała sprawa jest fascynująca i pomaga zobrazować podstawowe kwestie w świecie, w którym otwarte oprogramowanie odgrywa dużą rolę. Jak zarządzać relacjami i konfliktami pomiędzy projektami wolnego i komercyjnego oprogramowania? Jak prywatne firmy mogą wyjawiać informacje na temat własnościowego mikrokodu i tym podobnych rzeczy, jednocześnie chroniąc swoje zasoby przed konkurencją? Czy jeśli, jak Linus zgadywał na początku, Intel planuje pozostawić tak poważną wadę na dłużej, to jak programiści i użytkownicy otwartego oprogramowania mogą komunikować się z firmą i być może wywierać na nią presję, aby zmieniła swoje decyzje?
Autor: Zack Brown
Lista dyskusyjna poświęcona rozwojowi jądra jest głównym narzędziem komunikacyjnym programistów jądra. Ruch na nie jest ogromny – dochodzi do dziesięciu tysięcy listów tygodniowo. Pozostawanie ze wszystkim na bieżąco to zadanie bardzo trudne dla zwykłych śmiertelników. Zack Brown jest jedną z niewielu osób, która uważnie śledzą wszystkie dyskusje.
