![\"Kees](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>Optymalne rozwi\u0105zanie stanowi\u0142oby przeniesienie tylko najwa\u017cniejszych poprawek i luk, jednak problemem jest wydzielenie takich b\u0142\u0119d\u00f3w z og\u00f3lnego strumienia. Najwi\u0119cej problem\u00f3w wynika z u\u017cycia j\u0119zyka C, kt\u00f3ry wymaga du\u017cej precyzji w pracy z pami\u0119ci\u0105 i wska\u017anikami. Dodatkowo, wiele potencjalnych poprawek luk nie ma przypisanych identyfikator\u00f3w CVE lub otrzymuje taki identyfikator dopiero po pewnym czasie od opublikowania poprawki. W takich warunkach producentom niezwykle trudno jest rozr\u00f3\u017cni\u0107 drugorz\u0119dne poprawki od istotnych problem\u00f3w wp\u0142ywaj\u0105cych na bezpiecze\u0144stwo. Statystyki pokazuj\u0105, \u017ce ponad 40% luk jest usuwanych przed przypisaniem CVE, a \u015bredni czas op\u00f3\u017anienia mi\u0119dzy wydaniem poprawki a przypisaniem CVE wynosi trzy miesi\u0105ce (tzn. na pocz\u0105tku poprawka jest traktowana jak zwyk\u0142y b\u0142\u0105d, ale dopiero po kilku miesi\u0105cach staje si\u0119 jasne, \u017ce nast\u0105pi\u0142o usuni\u0119cie luki).<\/p>\nW zwi\u0105zku z tym, nie maj\u0105c oddzielnej ga\u0142\u0119zi z poprawkami luk oraz nie otrzymuj\u0105c informacji o powi\u0105zaniu konkretnego problemu z bezpiecze\u0144stwem, producenci oprogramowania opartego na j\u0105drze Linux s\u0105 zmuszeni nieustannie przenosi\u0107 wszystkie poprawki z najnowszych stabilnych ga\u0142\u0119zi. Praca ta wymaga jednak znacznych zasob\u00f3w i w firmach napotyka op\u00f3r z powodu obaw o wyst\u0105pienie regresji, kt\u00f3re mog\u0105 zak\u0142\u00f3ci\u0107 normalne dzia\u0142anie produktu.<\/p>\n
Przypomnijmy, \u017ce zdaniem Linusa Torvaldsa, wszystkie b\u0142\u0119dy s\u0105 wa\u017cne i luki nie powinny by\u0107 oddzielane od innych rodzaj\u00f3w b\u0142\u0119d\u00f3w oraz wyr\u00f3\u017cniane w osobn\u0105, wy\u017cej priorytetow\u0105 kategori\u0119. Takie zdanie uzasadnione jest tym, \u017ce dla przeci\u0119tnego programisty, kt\u00f3ry nie specjalizuje si\u0119 w zagadnieniach bezpiecze\u0144stwa, zwi\u0105zek poprawki z potencjaln\u0105 luk\u0105 nie jest oczywisty (w przypadku wielu poprawek jedynie przeprowadzenie oddzielnego audytu pozwala zrozumie\u0107, \u017ce dotycz\u0105 one bezpiecze\u0144stwa). Wed\u0142ug Linusa, kwestie wydzielenia potencjalnych luk z og\u00f3lnego strumienia poprawek powinny by\u0107 zaj\u0119ciem specjalist\u00f3w bezpiecze\u0144stwa z zespo\u0142\u00f3w odpowiedzialnych za wsparcie pakiet\u00f3w z j\u0105drem w dystrybucjach Linux.<\/p>\n
Kees Cook uwa\u017ca, \u017ce jedynym rozwi\u0105zaniem dla zachowania bezpiecze\u0144stwa j\u0105dra przy rozs\u0105dnych d\u0142ugoterminowych kosztach jest przesuni\u0119cie in\u017cynier\u00f3w zajmuj\u0105cych si\u0119 przenoszeniem poprawek do lokalnych wersji j\u0105dra do wsp\u00f3lnej, skoordynowanej pracy nad utrzymywaniem poprawek i luk w zabezpieczeniach w g\u0142\u00f3wnym j\u0105drze (upstream). W obecnej formie wielu producent\u00f3w u\u017cywa w swoich produktach starszych wersji j\u0105dra i w\u0142asnor\u0119cznie wprowadza poprawki, co prowadzi do tego, \u017ce in\u017cynierowie w r\u00f3\u017cnych firmach powielaj\u0105 swoj\u0105 prac\u0119, rozwi\u0105zuj\u0105c ten sam problem.<\/p>\n
Na przyk\u0142ad, je\u015bli 10 firm, w ka\u017cdej z kt\u00f3rych jeden in\u017cynier zajmuje si\u0119 wprowadzaniem tych samych poprawek, przestawi tych in\u017cynier\u00f3w na napraw\u0119 b\u0142\u0119d\u00f3w w upstream, to zamiast przenosi\u0107 jedn\u0105 poprawk\u0119 mog\u0105 naprawi\u0107 10 r\u00f3\u017cnych b\u0142\u0119d\u00f3w dla og\u00f3lnej korzy\u015bci lub do\u0142\u0105czy\u0107 do przegl\u0105du proponowanych zmian, unikaj\u0105c wprowadzenia b\u0142\u0119dnego kodu do j\u0105dra. Zasoby mo\u017cna r\u00f3wnie\u017c przekierowa\u0107 na tworzenie nowych narz\u0119dzi do testowania i analizy kodu, kt\u00f3re pozwoli\u0142yby na wczesnym etapie automatycznie identyfikowa\u0107 typowe klasy b\u0142\u0119d\u00f3w, kt\u00f3re pojawiaj\u0105 si\u0119 wielokrotnie.<\/p>\n
Kees Cook proponuje r\u00f3wnie\u017c bardziej aktywne wykorzystanie automatyzacji i test\u00f3w fuzzingowych bezpo\u015brednio w procesie rozwoju j\u0105dra, stosowanie system\u00f3w ci\u0105g\u0142ej integracji oraz rezygnacj\u0119 z archaicznego zarz\u0105dzania rozwojem poprzez e-mail. Obecnie skutecznemu testowaniu przeszkadza fakt, \u017ce g\u0142\u00f3wne procesy testowania s\u0105 oddzielone od rozwoju i odbywaj\u0105 si\u0119 dopiero po sformowaniu wersji. Kees zaleci\u0142 tak\u017ce stosowanie j\u0119zyk\u00f3w programowania, kt\u00f3re zapewniaj\u0105 wi\u0119ksz\u0105 wysoki poziom bezpiecze\u0144stwa<\/a>, takie jak Rust.<\/p>\n