Nowości

Wywołanie systemowe printk() to dla jądra sposób na produkowanie dzienników i innych komunikatów. Jądro nie korzysta z żadnej standardowej biblioteki funkcji, takich jak printf(), więc musi sobie jakoś radzić. Jednak jakby na to nie patrzeć, printk() jest mocno nieuporządkowane.

Sergey Senozhatsky próbował ostatnio coś z tym zrobić, starając się jednocześnie uniknąć potencjalnych konfliktów w systemie. Pojawia się bowiem bardzo dużo blokad systemu powodowanych przez prinkt() odwołujące się do siebie samego, a celem Sergeya nie było rozwiązywanie tego problemu. Powiedział jednak, że jest też wiele przypadków, kiedy blokady mają inny powód, i tu należy znaleźć rozwiązanie.

Konkretniej mówiąc, pojawiły się blokady systemu na wyjściu konsoli, wywoływane przez printk() próbujące pisać na tę konsolę. Aby je naprawić, Sergey chciał wprowadzić funkcje pomocnicze dla TTY (wykorzystywanego do implementacji konsoli) i kodu UART (służącego do asynchronicznej komunikacji z konsolą).

Niestety, wymagałoby to aktualizowania każdego sterownika szeregowego. Dodatkowo rozwiązywałoby to jedynie problem konkretnego typu blokad jądra. Jednak Sergey stwierdził, że to przynajmniej częściowo rozwiąże problem, a od czegoś trzeba zacząć.

Alan Cox nie był zachwycony propozycją Sergeya. Stwierdził, że łatki dodałyby niepotrzebny kod do części jądra, która powinna być tak szybka, jak to tylko możliwe. Dodał, że „printk jest już dzisiaj mało wiarygodne, a to przez wszystkie zmiany związane z wydajnością”. Uważa więc, że lepiej by było po prostu opóźnić wyprodukowanie wyjścia na konsolę, do czasu aż będzie to możliwe.

Sergey nie zgodził się, gdyż pomysł Alana nie rozwiązuje blokad systemu raportowanych ostatnio przez użytkowników.

W międzyczasie Peter Zijlstra powiedział, że Alan nie rozumie powagi problemów związanych z printk(). Stwierdził: „printk to kupa @#$#@; określenie go jako mało wiarygodnego do zbyt duże niedomówienie”.

Petr Mladek, pracujący z Sergeyem nad łatkami, wyjaśnił:

„Nasz zestaw łatek dodaje kolejne API dla spin_lock. Zachowuje się ono dokładnie jak spin_lock_irqsafe()/spin_unlock_irqrestore(), ale dodatkowo ustawia printk_context.

W tym wypadku printk_context definiuje, jaka implementacja printk jest bezpieczna. Mamy cztery możliwości:

1. Normal (przechowywana w logbuf; próbuje obsłużyć konsolę).

2. Deffered (przechowywana w logbuf; wstrzymuje konsolę).

3. Safe (przechowywana w buforze odpowiadającym procesorowi wstrzymuje wszystko).

4. safe_nmi (przechowywana w kolejnym buforze odpowiadającym procesorowi wstrzymuje wszystko).

Ten zestaw łatek wymusza bezpieczny kontekst blokad TTY i UART. W zasadzie kontekst realizujący wstrzymanie jest wystarczający do powstrzymania wszystkich wspomnianych blokad systemu”.

Jednak Linus Torvalds wyraził się negatywnie na temat tego pomysłu. Powiedział:

„Zasada jest prosta: PO PROSTU TEGO NIE RÓB.

Nie robimy rekursywnych blokad. Nie tworzymy losowych, skomplikowanych rozwiązań. Nie robimy nic, co może nas zaboleć.

Nie ma żadnego sensownego powodu, aby sterownik UART wykorzystywał printk() w krytycznym momencie, kiedy konsola jest blokowana.

Po prostu przesuńmy te wywołania printk; dodawanie nowych szalonych blokad nie jest rozwiązaniem.

Jeśli mamy blokadę typu spinlock, która blokuje system, ponieważ występuje w regionie, który jest już tak blokowany, powiemy, że to jest błędne.

Tu sytuacja wygląda podobnie. Nie próbujmy ominąć śmieciowego rozwiązania. Naprawiajmy je, usuwając problematyczne wywołanie printk”.

Biorąc powyższe pod uwagę, Steven Rostedt zauważył: „Może powinniśmy zweryfikować sterowniki konsoli i usunąć z nich wszystkie wywołania printk, pr_*, WARN* oraz BUG*”.

Sergey nie zgodził się z tym, mówiąc, że nie jest to tylko kwestia usuwania z kodu niechcianych printk(). Powiedział: „To nie UART sam w sobie wywołuje printk(), to byłoby banalne do rozwiązania. Problem tkwi we wszystkich podsystemach, do których sterownik konsoli się odwołuje”.

Dodał: „Na przykład workqueue.c w jądrze – w różnych przypadkach może wywołać WARN_ON/printk i jest to w porządku. Oprócz jednej sytuacji: workqueue można wywołać ze sterownika konsoli, co sprawia, że staje się to nielegalne, gdyż może powodować blokady systemu. Konsola może też odnieść się do WQ. Nie bezpośrednio, ale przez kod TTY”.

Powiedział też: „Innymi słowy, pojawia się kontekst, który można nazwać «wywołany ze sterwonika konsoli», który jest trudny do wyśledzenia, ale w tym wypadku może pomóc printk_safe”.

Jednak Linus odpowiedział: „Mamy już cały model PRINTK_SAFE_CONTEXT_MASK dodawany do bufora pomocniczego, jeśli mamy rekursję. Czemu nie jest to uruchamiane? Tu tkwi błąd. Kategorycznie *nie* chcę żadnych szalonych zmian w sterownikach tty. Nie, nie, nie”.

Wtedy Sergey odparł, że to jest dokładnie to, co jego kod robi. Ulepsza printk_safe tak, że obsługuje nowe sytuacje.

Wątek zakończył się bez żadnych wniosków. Jednak chęć ulepszenia printk() ciągle pozostaje. Wszyscy są za, jednak trzeba znaleźć odpowiedni sposób na zrobienie tego.

Czasami dyskusja na jakiś konkretny temat pojawia się znikąd. Ostatnio David Howells opublikował przykładowy kod dla interfejsu jednej z nowych bibliotek w jądrze. Pavel Machek zauważył, że kod będzie zwracać informacje o błędach w języku angielskim i stwierdził: „Nie jestem pewien, czy to ma sens, ponieważ może sprawiać problemy przy tłumaczeniach”. David stwierdził, że podanie jedynie kodu błędu jest niewystarczające, ponieważ dzienniki są domyślnie wyświetlane przez printk() i powinny być możliwe do odczytania przez człowieka.

Pavel odpowiedział: „Błędy powinny mieć numery, a katalog wyjaśnia, co one oznaczają. W ten sposób przestrzeń użytkownika może być tłumaczona i tak robimy w przypadku errno. Myślę, że liczby są najlepsze. Jeśli ich nie lubisz, możesz użyć ciągów znaków, pod warunkiem że potrafisz wymienić je w dokumentacji (jednak będzie to wyglądało dziwnie). Obawiam się, że wszystko inne jest nie na miejscu”.

David nie zgodził się z tym, mówiąc, że na błędy składa się wiele elementów, które trzeba obliczyć osobno i wykorzystać jako parametry, aby zwrócić ujednoliconą informację. Pavel jednak nalegał, że mimo to ważne jest, aby kod użytkownika mógł też przetwarzać kody błędów. Podał przykład: „Można zwrócić zdanie (‘za mało magicznego pyłu (%d za małe) w urządzeniu %s w %s’, 123, ‘fuu’, ‘szaffa’). Jednak jeśli przekażemy to jako ciąg znaków, staje się trudne lub niemożliwe do analizy (na przykład jeśli urządzenie nazywa się fuu w barze)”.

W tym momencie do dyskusji włączył się Linus Torvalds i nakreślił sposób postępowania w takich przypadkach. Częściowo zgodził się z Davidem, że kod użytkownika nie powinien analizować treści błędu, a częściowo z Pavlem, gdyż błędy powinny posiadać kody numeryczne, zamiast być tekstem. Powiedział:

„Nie tworzymy wielojęzykowych ciągów znaków w jądrze. Nigdy tego nie robiliśmy. Owszem, byli tacy, którzy próbowali tworzyć bazy komunikatów w celu późniejszego ich tłumaczenia, ale nie chcę, aby było to częścią procesu rozwoju jądra. Jest to uciążliwe.

Dla niektórych projektów GUI internacjonalizacja może być czymś ważnym, czymś, na czym się opierają. Dla jądra tak nie jest. Interesuje nas technologia, a nie język.

Dlatego w dalszym ciągu chcemy podawać numery błędów, kiedy one występują. A jeśli ludzie potrzebują więcej informacji o tym, co spowodowało dany błąd, dostępne są angielskie opisy. Można je cytować i wyszukiwać, nawet ich nie rozumiejąc. Tak to działa.

Spójrzmy prawdzie w oczy, opcje montowania są już teraz (skróconymi) słowami z języka angielskiego. Mowa o mtime i create.

Są miejsca gdzie tłumaczenie się przydaje. Jądro *nie* jest jednym z nich”.

Wtedy Matthew Wilcox zauważył, że narzędzie gettext „korzysta z języka angielskiego do wyszukiwania fraz i zamienia wszystko na zlokalizowane ciągi znaków. To powszechnie stosowany sposób!”

Pavel zgodził się z tym, że język angielski w jądrze nie jest problemem. Ciągle jednak jest zdania, że to numery błędów pozwalają programom użytkowników na odczytywanie komunikatów z jądra i zwracanie zlokalizowanych informacji. Powiedział: „Przestrzeń użytkownika doskonale sobie radzi z tłumaczeniem błędów i dobrze by było utrzymać ten stan rzeczy”.

Linus zauważył, że nawet gettext nie jest idealny. Natomiast na temat czytelności komunikatów o błędach powiedział: „Jeśli zmieniasz opcje montowania i tym podobne rzeczy, lepiej przygotuj się na wyszukiwanie niezrozumiałych słów. Większość z nich taka będzie, nawet jeśli to twój ojczysty język”.

W oddzielnej wiadomości dodał, że błędy jądra mogą być wyspecjalizowane i automatycznie generowane przez kod jądra, tak aby pasowały do konkretnych okoliczności. Powiedział: „Kiedy ciąg znaków zostanie wygenerowany, może zawierać tysiące różnych wyrazów i nie da się ich sprawdzić w tabeli błędów […] Składają się na nie różne losowe słowa kluczowe i tym podobne rzeczy”.

Co do tłumaczenia komunikatów, przynajmniej w przypadku jądra, Linus stwierdził:

„Wydaje mi się, że najlepszą opcją jest «zignorować problem». Wywołania systemowe w dalszym ciągu będą zwracać podstawowe numery błędów (EINVAL itp.), a rozszerzone komunikaty o błędach będą dokładnie tym, na co wskazuje nazwa: rozszerzonymi komunikatami. Jeśli ktoś ich nie rozumie, niech je zignoruje.

Biorąc to wszystko pod uwagę, trzeba zauważyć, że ludzie zawsze chcieli rozszerzonych komunikatów o błędach, a nie dodawaliśmy ich, ponieważ więcej z tym kłopotu niż potencjalnych zysków”.

Theodore Ts’o również stwierdził, że nie jest to problem, którym warto się zajmować. Nawet bardzo złożone komunikaty o błędach jądra najlepiej, jak stwierdził, obsługiwać, przekazując je do przestrzeni użytkownika, gdzie będą wyjaśniane i tłumaczone na dowolny język.

Pavel raczej zgadzał się z tym wszystkim, ale skoro kod Davida był czymś nowym, a nie przeróbką już istniejącego rozwiązania, stwierdził: „Mamy okazję zrobić to odpowiednio przy minimalnym koszcie (ponieważ interfejs jest nowy, nie potrzebujemy kompatybilności)”.

Jednak Theodore podkreślił swój punkt widzenia, mówiąc: „Myślę, że propozycja Davida, czyli zwracanie błędu w postaci słowa Error: i tekstu w języku angielskim jest w porządku, a rozwijanie tego to już przesada. Zaletą dmesg jest to, że powszechnie wiadomo, iż jest to tekst angielski skierowany do ekspertów. Kiedy odejdziemy od dmesg, pojawi się grupa od I18N (skrót od internacjonalizacji) i będzie chciała czegoś bardziej skomplikowanego. A jeśli jedynym wyborem będzie albo złożone, straszne rozwiązanie w idei I18N, realizowane przez wywołanie systemowe, albo pozostawienie angielskiego tekstu komunikatu w dmesg, ja zdecydowanie głosuję za dmesg”.

Dyskusja trwała jeszcze przez jakiś czas. Kilku programistów rzucało argumenty za i przeciw różnym technikom tłumaczenia i wyjaśniało problemy z nimi związane. Następnie Linus stwierdził: „Serio. Żadnych tłumaczeń. Żadnych rozwiązań dla tłumaczeń. To ślepy zaułek, utrudnienie dla każdego”.

Dodał: „Wolę interfejsy z prostym językiem angielskim. Jeśli ktoś ma z tym problem, nie powinien ich używać. Koniec dyskusji. Korzystajcie z numerów błędów, jeśli chcecie internacjonalizacji i pogódźcie się z faktem, że numery są dość ograniczoną informacją. To najprostsze rozwiązanie”.

David odpisał: „zgadzam się” i to zakończyło dyskusję.

Naprawdę dziwnym i jednocześnie ciekawym aspektem związanym z tym tematem jest to, że korporacje związane z Internetem skupiają się aktualnie na dostępności, zarówno dla niepełnosprawnych, jak i grup mówiących innymi językami. Istnieje presja polityczna, aby to robić ze względu na wrażliwość społeczną, oraz presja ekonomiczna, gdyż umożliwia to wejście na nowe rynki. Firma internetowa nie osiągnie wielkiego sukcesu bez zinternacjonalizowanych interfejsów.

Jądro Linuksa obecne jest już na całym świecie. Działa praktycznie wszędzie, sprawiając, że nawet ci, którym wydaje się, że korzystają jedynie z Windowsa, są od niego zależni, a mimo to internacjonalizacja jest w nim pomijana.

Możliwe, że jest tak, ponieważ otwarte projekty mają możliwość przerzucenia części swojej pracy na inne projekty, które albo już istnieją, albo powstaną, jeśli będzie taka potrzeba. Projekty korporacyjne nie mogą zakładać, że pojawi się ktoś obcy, kto pomoże w ich rozwoju.

W świecie Linuksa ciągle powraca dyskusja na temat firm próbujących powstrzymać użytkowników danego systemu przed uzyskaniem nad nim pełnej kontroli. Technicznie składa się na to kwestia bezpieczeństwa, gdyż chodzi o kontrolę dostępu. Stawką są duże pieniądze, gdyż korporacje medialne oferują użytkownikom dostęp do swoich produktów, ale pod warunkiem że te produkty mogą być zabezpieczone przed naruszeniem praw autorskich. Jednak programiści jądra odmawiają implementacji i zaakceptowania takich opcji, ponieważ uważają, że właściciel urządzenia posiada bezwzględne prawo kontrolowania własnego systemu.

Dyskusje na ten temat bywają zawiłe. Korporacje medialne często nie chcą przyznać, że łatka, którą zgłaszają, tak naprawdę ma odebrać użytkownikowi kontrolę nad urządzeniem. Wiedzą, że wtedy nie zostałaby zaakceptowana. Równie często programiści jądra nie chcą, żeby wychodziło na to, że odrzucają łatki z powodów, które nie mają nic wspólnego z tym, co twierdzi strona zgłaszająca. W rezultacie mamy dziwny taniec pomiędzy obiema stronami, w którym programiści jądra próbują skłonić zgłaszającego do określenia prawdziwego celu łatki, a zgłaszający próbuje zaprezentować ją jako coś, co poprawia bezpieczeństwo, czego efektem ubocznym może być odebranie właścicielowi kontroli nad urządzeniem.

Ostatnio Chen Yu z Intela chciał dodać do jądra funkcję szyfrowania uruchomionego obrazu jądra, kiedy użytkownik wybiera hibernację systemu. Konieczne w tym przypadku byłoby zainstalowanie modułu jądra generującego klucz z frazy szyfrującej dostarczonej od użytkownika, szyfrującego obraz jądra i deszyfrującego, kiedy system jest przywracany z hibernacji.

Pavel Machek zauważył, że uswsusp (zawieszenie oprogramowania z przestrzeni użytkownika) już teraz ma funkcję szyfrującą. Poprosił Chena o wyjaśnienie, w przypadku jakich ataków jego system szyfrowania oparty na przestrzeni jądra będzie lepszy niż rozwiązanie z zastosowaniem uswsusp.

Chen odniósł się do dziennika łatki, w którym jest napisane: „Główną zaletą jest to, że użytkownik nie musi szyfrować całej partycji swap, tak jak w innych narzędziach. W końcu najlepiej jest, gdy moduł jądra jest szyfrowany przez samo jądro”. Jednak Pavel nie był z tej odpowiedzi zadowolony i odpowiedział, że wyjaśnienie Chena nie odnosi się do konkretnych ataków i rodzajów ochrony, które byłyby lepsze od uswsusp. Dodał też: „Zauważmy też, że [Chun-Yi Lee] zgłosił serię łatek, które szyfrują zarówno w jądrze, jak i przy hibernacji. Jego celem jest bezpieczny rozruch. Jak to się ma do tej propozycji?”

Chen odpowiedział, że lepiej, jeśli jądro szyfruje uruchomiony system aniżeli przestrzeń użytkownika. Dzięki temu unikamy transferu pamięci jądra w postaci czystego tekstu z przestrzeni jądra do przestrzeni użytkownika. Poza tym brak konieczności kopiowania danych oszczędza czas. Pozostając w przestrzeni jądra, nie musimy obarczać użytkownika problemem błędów przestrzeni użytkownika, które narażają bezpieczeństwo. Dodał, że w przypadku tej łatki współpracował z Chun-Yi.

Chun-Yi również zabrał głos, wyjaśniając:

„Zaletą mojego rozwiązania jest to, że podpisana/zaszyfrowana migawka systemu może być przechowywana w dowolnym miejscu: w jądrze i przestrzeni użytkownika.

Łatka Yu szyfruje bufor stron przed wysłaniem do warstwy wejścia/wyjścia w celu zapisania na swap. Główna logika tego rozwiązania dotyczy swap.c. Jest to przeciwne do rozwiązania umieszczającego swap w jądrze.

Zaletą rozwiązania Yu jest to, że szyfruje skompresowane dane z obrazu. Ze względu więc na pamięć, wydajność jest lepsza.

Yu zakłada wykorzystanie sysfs do przełączania pomiędzy różnymi rodzajami szyfrowania/podpisywania. Dodatkowo udostępnimy pomocnika szyfrowania/podpisu oraz menedżer kluczy dla obu rozwiązań”.

Pavel pozostał nieprzekonany. Odpowiedział: „W odpowiedzi na błędy w przestrzeni użytkownika nie należy przenosić kodu z przestrzeni użytkownika do jądra”.

Zapytał także: „A więc waszym celem jest hibernacja kompatybilna z blokadą jądra? Czy ta łatka zapewnia wystarczające zabezpieczenia, aby hibernacja była możliwa razem z blokadą jądra?” Oliver Neukum poprosił o wyjaśnienie, pisząc: „Czy jeśli klucz pochodzi z przestrzeni użytkownika, to będzie to wystarczające?”. Pavel odpowiedział: „Tak, wydaje się, że to jeden z problemów zestawu łatek Yu Chena”.

Pavel wyjaśnił, że osobiście jest przeciwny szyfrowaniu hibernacji w jądrze, ponieważ mogłoby to być (a nawet już jest) realizowane w przestrzeni użytkownika. Dodał jednak: „Istnieje dziwny twór, który nazywamy bezpiecznym rozruchem, i wydaje się, że niektórzy by tego chcieli. Możemy więc potrzebować szyfrowania w jądrze. Jednak chciałbym czegoś, co współpracuje też z uswsusp. Poza tym traktujemy jako obowiązkowe określenie, jakie gwarancje bezpieczeństwa daje łatka i przeciwko jakim atakom”.

W odpowiedzi na pytanie Olivera o klucz pochodzący z przestrzeni użytkownika Chen odpowiedział: „Próbowaliśmy już generować klucz w jądrze, ale były sugestie, aby tworzyć go w przestrzeni użytkownika i przekazać do jądra, a tak właśnie działa ecryptfs. Wydaje się więc, że będzie to bezpieczny sposób szyfrowania w jądrze”.

Chen zaoferował też, że podsumuje różnice pomiędzy jego łatką a łatką Chun-Yi. Powiedział: „Jedyna różnica pomiędzy szyfrowaniem hibernacji w rozwiązaniu Chun-Yi a naszym jest to, że jego rozwiązanie szyfruje migawkę w całości, a nasze szyfruje każdą stronę, zanim trafi do urządzenia blokowego. Zaletą w jego przypadku jest to, że migawka może być zaszyfrowana najpierw w jądrze, dzięki czemu uswsusp może odczytać ją w przestrzeni użytkownika, nawet jeśli jądro jest zablokowane. Dyskutowałem z Chun-Yi o tym, że możemy wykorzystać migawkę, aby uswsusp był tu użyteczny. Wymieniliśmy się kodem i teraz Chun-Yi może wykorzystać klucz użytkownika do utworzenia podpisu. Z tego punktu widzenia nasze rozwiązania są takie same, oprócz tego, że możemy pomóc mu wyczyścić trochę kod i ulepszyć proces szyfrowania”.

W odpowiedzi na wypowiedź Pavla o bezpiecznym rozruchu Oliver napisał: „Może powinniśmy jasno stwierdzić, że celem tego zestawu łatek jest umożliwienie współistnienia bezpiecznego rozruchu i STD. Wszystko inne to ciekawy efekt uboczny, a nie główny cel, prawda? Zgadzamy się też, że bezpieczny rozruch wymaga szyfrowania w przestrzeni jądra, czyż nie? Poza tym, według mnie, klucz też powinien być generowany przez zaufany kod, czyli przestrzeń jądra. Yu Chen, nie rozumiem jak symetryczne szyfrowanie ze znanym kluczem może być bezpieczne”.

Pavel dodał: „Nie wydaje mi się, żeby generowanie klucza w przestrzeni użytkownika było wystarczająco dobre do zagwarantowania bezpiecznego rozruchu”.

Pavel dalej też pytał o konkretne zagrożenia bezpieczeństwa i jak ten kod mógłby na nie odpowiadać. Oliver postanowił wyjaśnić:

„Niepodpisany kod nie może posiadać uprawnień podpisanego kodu. Dlatego:

1. Niepodpisany kod nie może czytać wrażliwych części przestrzeni pamięci podpisanego kodu.

2. Niepodpisany kod nie może być w stanie zmieniać przestrzeni pamięci podpisanego kodu – migawki, które są zmienione, nie mogą być przywracane”.

Jednak zapytał jeszcze, dlaczego generowanie kluczy w przestrzeni użytkownika nie będzie bezpieczne, na co Pavel odparł: „Ponieważ wtedy przestrzeń użytkownika będzie w posiadaniu zarówno klucza (teraz), jak i zaszyfrowanego obrazu (po restarcie), więc może odszyfrować, zmienić i zaszyfrować ponownie...”.

Dyskusja była kontynuowana, a nowe wersje łatek pojawiały się i uzyskiwały kolejne komentarze. W pewnym momencie Yu Chen powiedział: „Ciągle jestem trochę zdezorientowany, jeśli chodzi o fazę «przywracania». nawróćmy na przykład uwagę na szyfrowanie (nie podpis). Celem wykonywania szyfrowania hibernacji jest zapobieganie wykradania informacji innych użytkowników z RAM-u. Powiedzmy, że użytkownik A wykorzystuje frazę szyfrującą do wygenerowania klucza i zaszyfrowania migawki wykorzystanej w hibernacji oraz przechowania jej na dysku. Wtedy, użytkownik B chciałby przywrócić system z hibernacji do stanu, w jakim zostawił go użytkownik A. B musi podać frazę szyfrującą A. Jeśli dobrze rozumiem, klucz jest zapisywany w nagłówku i przechowywany na dysku. Oznacza to, że odczytując nagłówek z dysku, można uzyskać klucz i odszyfrować obraz, co nie jest bezpieczne”.

Jednak Pavel odpowiedział, wykładając karty na stół:

„Nie, nie wydaje mi się, żeby o to chodziło.

Celem w tym wypadku jest ewidentnie powstrzymanie użytkownika przed czytaniem/modyfikowaniem pamięci jądra na urządzeniu, którego jest właścicielem.

Może to się wydawać dziwne, ale to jest to, czego «bezpieczny» rozruch wymaga (i czego chce Disney)”.

Yu Chen, również wykładając karty na stół, powiedział: „Ok, rozumiem takie wymagania, ale interesuje mnie też, jak podzielić użytkowników, aby nie widzieli swoich danych”.

W pewnym momencie Oliver stwierdził: „Jeśli system działa i fs jest zamontowany, twoje dane są równie bezpieczne co dostęp do konta root na urządzeniu, prawda? Szyfrujemy dysk głównie po to, żeby danych nie dało się uzyskać (i zmienić) w czasie, kiedy system nie działa. Bezpieczny rozruch nie ufa rootowi. Istnieje hierarchia zaufania w kryptografii, a przestrzeń użytkownika do niej nie należy”.

Ostatecznie ta dyskusja nie ma rozwiązania i dodatkowo jest bardzo dziwna. Za każdym razem, kiedy Pavel pytał o to, jakie niebezpieczeństwa adresuje łatka, wydawało się, że chciał, aby programiści przyznali, że zamiast łatać istotne dla użytkownika dziury w bezpieczeństwie, próbowali odseparować użytkownika od jego własnego systemu. Z tego samego powodu programiści wydawali się unikać opisywania zagrożeń, o których Pavel chciał usłyszeć.

Jednocześnie, jak stwierdził Pavel, bezpieczny rozruch jest już faktem. Pojawia się coraz więcej łatek go wspierających. Disney i inne korporacje stopniowo starają się odciąć użytkowników od ich własnych systemów. 

Autor

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.