Po pierwsze nie psuj: dla twórcy Linuksa ludzie od bezpieczeństwa to cholerni idioci

Linus Torvalds znów zadbał o swój wizerunek człowieka, którynie przebiera w słowach, i któremu nikt nie może podskoczyć nalinuksowej arenie – nawet gdy w grę wchodzi kwestia bezpieczeństwasystemu operacyjnego. Nowy kernel 4.15 pozostanie wolny od pomysłówKeesa Cooka z Google, który utwardziłmechanizm kopiowania pamięci z przestrzeni kernela do przestrzeniużytkownika do tego stopnia, że mówiąc w przenośni,oprogramowanie mogłoby sobie na nim połamać zęby.

Kees Cook z zespołu bezpieczeństwa smartfonu Google Pixel jużwcześniej miał swoje przejścia z Linusem – w lipcu tego rokuwskazał on na błąd w obsłudze wycieków pamięci przez linuksowykernel. W odpowiedzi dowiedziałsię, że to jego rozwiązanie jest (delikatnie mówiąc) doniczego, a on sam wymyśla na swoje usprawiedliwienie kompletnebzdury – i ma zaprzestać tych idiotyzmów.

Niezrażony programista Google’a tym razem przyszedł zezmianami do mechanizmu kopiowania pamięci, które miały znaczącoograniczyć obszary pamięci kernela dostępne kopiowaniu do i zprzestrzeni użytkownika. Służyć temu miała biała listadopuszczonych regionów, póki co z trybem awaryjnym by niczego niezepsuć, ale najdalej po dwóch wydaniach kernela tryb awaryjnymiałby zniknąć.

Linus zareagowałpoczątkowo całkiem spokojnie. Stwierdził, że takie żądaniazawsze czekają na końcu – ponieważ budzą lęk, ponieważ im nieufa, ponieważ czuje, że musi spędzić nad nimi trochę czasu. Akiedy ma dużo innych żądań, gdy zamyka się okienko wydania, topo prostu nie ma na takie rzeczy czasu.

Ale co takiego jest strasznego w mechanizmie białych listkopiowania pamięci? No cóż, Linus jak to Linus, powiedziałco myśli o ludziach takich jak Cook. Specjalistom od bezpieczeństwapo prostu nie można zaufać, przynoszą zmiany dotykające samegordzenia systemu, i to metodą faktów dokonanych, z całą masąjakichś arbitralnych zasad.

Tymczasem Linux długo miał problemy z pierwszym utwardzeniemmechanizmu kopiowania pamięci, wciąż ma poważne problemy zuszkodzeniami pamięci wskutek randomizacji jej struktur, a tewszystkie dalsze utwardzenia to zdaniem Linusa tylko źródłoprzypadkowych błędów, wynikających z niedostatecznego testowaniai niechlujności. Dla ludzi od bezpieczeństwa nic pozabezpieczeństwem się po prostu nie liczy! Z tego właśnie powoduodmawia wprowadzenia zmian, proponując w zamian Cookowiprzygotowanie mniejszego pull requestu, który po prostu wprowadziniezbędną infrastrukturę, a niczego psuć nie będzie.

Swoje dwa grosze na korzyść Cooka dołożyłtymczasem Paolo Bonzini, opiekun hiperwizora kvm, zachwalając że toniezłe rozwiązanie, bez żadnych zależności konfiguracyjnych,które poradzi sobie nawet jeśli programista zapomni o łatkach –i daleko mniej straszne niż wtyczki do kompilatora GCC. JeśliLinus nie chce tego pull requestu, to niech go teraz nie robi, aleniech przynajmniej weźmie jego podzbiór, łatwo jest zastąpićbiałe listy czarnymi listami. Cook zaś zaczął zachwalaćswój mechanizm awaryjny, dzięki któremu wprowadzone zmiany niczegoby nie popsuły.

Te odpowiedzi podziałały naLinusa jak płachta na byka. *Ci ludzie od bezpieczeństwato cholerni idioci *– pisze wswojej odpowiedzi,ostatecznie zamykającej kwestię dalszego utwardzania kopiowaniapamięci. Jest niedopuszczalne, by jacyś ludzie od bezpieczeństwaustanawiali nowe magiczne zasady, a następnie wywoływali panikękernela, gdy zasady te zostają naruszone, deklaruje twórca Linuksa,grzmiąc, że sama konieczność wprowadzenia trybu awaryjnegopokazuje, jak bardzo do niczego jest to rozwiązanie.

Ludzie od bezpieczeństwa powinniwbić sobie do głowy, że problemy z bezpieczeństwem to po prostubugi, które trzeba naprawić, a nie wprowadzać jakieś„utwardzenia”, sprowadzające się do ubijania procesów, któreniepoprawnie się zachowywały. Jak ktoś nie potrafi zrozumieć, żegłównym zadaniem ludzi od bezpieczeństwa jest debugowanieoprogramowania, to niech się lepiej do Linuksa nie pcha –stwierdził Linus. Podejście najpierw strzelaj, a potemzadawaj pytania jest po prostunie do przyjęcia.

Tako rzecze człowiek pogryzionyprzez pingwina. A Kees Cook? Ten położył uszy po sobie,stwierdzając,że jego głównym błędem było myślenie, że takie zmiany możnawprowadzić w jednym cyklu rozwojowym. Zajmie się dalszymipoprawkami i spróbuje szczęścia z kernelem 4.16.