![\"Kees](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>En optimal l\u00f6sning skulle vara att endast \u00f6verf\u00f6ra de mest kritiska bugfixarna och s\u00e5rbarheterna, men den stora utmaningen ligger i att identifiera s\u00e5dana fel fr\u00e5n den \u00f6vergripande str\u00f6mmen. Det st\u00f6rsta antalet pl\u00f6tsliga problem uppst\u00e5r p\u00e5 grund av anv\u00e4ndningen av spr\u00e5ket C, som kr\u00e4ver stor noggrannhet n\u00e4r det g\u00e4ller minne och pekare. Situationens sv\u00e5righetsgrad \u00f6kar av att m\u00e5nga potentiella s\u00e5rbarhetsfixar inte f\u00e5r CVE-ID:n eller f\u00e5r s\u00e5dana identifierare f\u00f6rst efter en tid efter att fixen publicerats. Under dessa omst\u00e4ndigheter \u00e4r det mycket sv\u00e5rt f\u00f6r tillverkare att skilja mellan sekund\u00e4ra fixar och viktiga s\u00e4kerhetsproblem. Statistiskt sett \u00e5tg\u00e4rdas mer \u00e4n 40% av s\u00e5rbarheterna innan de tilldelas en CVE och den genomsnittliga f\u00f6rdr\u00f6jningen mellan utgivningen av fixen och tilldelningen av CVE \u00e4r tre m\u00e5nader (d.v.s. initialt uppfattas fixen som ett vanligt fel, men efter n\u00e5gra m\u00e5nader blir det klart att det handlade om en \u00e5tg\u00e4rdad s\u00e5rbarhet).<\/p>\nI slut\u00e4ndan, utan en separat gren f\u00f6r att \u00e5tg\u00e4rda s\u00e5rbarheter och utan att f\u00e5 information om f\u00f6rh\u00e5llandet till s\u00e4kerheten under vissa problem, m\u00e5ste tillverkare av produkter baserade p\u00e5 Linux-k\u00e4rnan kontinuerligt \u00f6verf\u00f6ra alla fixar fr\u00e5n de senaste stabila grenarna. Men detta arbete kr\u00e4ver stora arbetsinsatser och m\u00f6ter motst\u00e5nd i f\u00f6retagen p\u00e5 grund av oro f\u00f6r regressiva f\u00f6r\u00e4ndringar som kan p\u00e5verka produktens normala funktion.<\/p>\n
L\u00e5t oss p\u00e5minna om att enligt Linus Torvalds \u00e4r alla fel viktiga och s\u00e5rbarheter b\u00f6r inte separeras fr\u00e5n andra typer av fel och ges en s\u00e4rskilt prioriterad kategori. Denna \u00e5sikt f\u00f6rklaras av att det f\u00f6r en vanlig utvecklare, som inte specialiserar sig p\u00e5 s\u00e4kerhetsfr\u00e5gor, inte \u00e4r uppenbart hur en fix l\u00e4nkar till en potentiell s\u00e5rbarhet (f\u00f6r m\u00e5nga fixar kr\u00e4ver endast en separat granskning f\u00f6r att f\u00f6rst\u00e5 att de r\u00f6r s\u00e4kerhet). Enligt Linus b\u00f6r s\u00e4kerhetsspecialister i team som ansvarar f\u00f6r k\u00e4rnpaketst\u00f6d i Linux-distributioner arbeta med att identifiera potentiella s\u00e5rbarheter bland den allm\u00e4nna str\u00f6mmen av fixar.<\/p>\n
Kees Cook anserar att den enda l\u00f6sningen f\u00f6r att bibeh\u00e5lla k\u00e4rns\u00e4kerheten med rimliga l\u00e5ngsiktiga kostnader \u00e4r att f\u00f6retag omdirigerar ingenj\u00f6rer som arbetar med att portera patchar till lokala k\u00e4rnbyggnader till ett samordnat arbete f\u00f6r att underh\u00e5lla patchar och s\u00e5rbarheter i upstream-k\u00e4rnan. I sin nuvarande form anv\u00e4nder m\u00e5nga tillverkare inte de nyaste versionerna av k\u00e4rnan i sina produkter och backportar patchar p\u00e5 egen hand, vilket inneb\u00e4r att ingenj\u00f6rer p\u00e5 olika f\u00f6retag duplicerar sitt arbete f\u00f6r att l\u00f6sa samma problem.<\/p>\n
Till exempel, om 10 f\u00f6retag, d\u00e4r varje f\u00f6retag har en ingenj\u00f6r som backportar samma patchar, omdirigerar dessa ingenj\u00f6rer till att \u00e5tg\u00e4rda fel i upstream, skulle de ist\u00e4llet f\u00f6r att portera en patch kunna \u00e5tg\u00e4rda 10 olika fel till allas f\u00f6rdel eller delta i granskningen av f\u00f6reslagna f\u00f6r\u00e4ndringar f\u00f6r att f\u00f6rhindra att felaktig kod inkluderas i k\u00e4rnan. Resurser skulle ocks\u00e5 kunna riktas mot att skapa nya verktyg f\u00f6r testning och kodanalys som skulle kunna identifiera typiska felformer automatiskt i ett tidigt skede.<\/p>\n
Kees Cook f\u00f6resl\u00e5r ocks\u00e5 att man mer aktivt anv\u00e4nder automatiserad och fuzzing-testning direkt under utvecklingen av k\u00e4rnan, till\u00e4mpar system f\u00f6r kontinuerlig integration och avst\u00e5r fr\u00e5n archaisk e-posthantering vid utveckling. F\u00f6r n\u00e4rvarande hindras effektiv testning av det faktum att de huvudsakliga testprocesserna \u00e4r separerade fr\u00e5n utvecklingen och sker f\u00f6rst efter att releaserna har skapats. Kees rekommenderade ocks\u00e5 att anv\u00e4nda programmeringsspr\u00e5k som ger mer en h\u00f6g s\u00e4kerhetsniv\u00e5<\/a>, s\u00e5som Rust.<\/p>\n