Nyligen Linux Kernel Development Leader Linus Torvalds föreslog att man skulle se över mekanismen för att aktivera STIBP-patchar (Single Thread Indirect Branch Predictors), som erbjuder ytterligare skydd mot Spectre v2.
Dessa korrigeringar har nyligen inkluderats i Linux-kärngrenen 4.20 under utveckling och har exporterats till den stabila versionen av Linux-kärnan 4.19.2.
Genom att använda STIBP i sin nuvarande form, användare märkte en signifikant minskning av prestandan för vissa applikationer när du använder denna samtidiga multithreading-teknik (SMT eller Hyper-Threading).
Med tanke på att resultatfallet kan nå 50%, med Linus Torvalds själv, att använda STIBP i sin nuvarande form är meningslösteftersom det är lättare och mer tillförlitligt att inaktivera SMT / Hyper-Threading helt, vilket säkerhetsmedvetna människor ofta gör.
Den största avmattningen orsakad av den nya Linux 4.20-kärnan beror på en minskning av Spectre variant 2 som Linux-grundaren Linus Torvalds nu vill begränsa.
Det är då frågan uppstår om det är nödvändigt att aktivera STIBP som standard, när SMT / Hyper-Threading redan är inaktiverat för dem som verkligen bryr sig om säkerhet.
Medan, För normala användare är 50% prestandaförlust en viktig faktor som kan representera vissa problem och Det är tveksamt om dessa teoretiska sårbarheter är värda att blockera.
Torvalds kräver att STIBP inte längre är aktiverat som standard
Samtidigt Linus Torvalds anser att det är osannolikt att praktiska attacker baserade på Spectre v2 kommer fram som på normala användarsystem.
Linus Torvalds hävdar att webbläsare är det huvudsakliga målet för attacker, som redan har lagt skydd till sin nivå (hotet är för isolerade JIT-processer för vilka en selektiv skyddsmetod kan utvecklas).
Se föreslår att man endast använder Spectre-skyddsmetoderna som standard, vilket inte leder till ett stort minskat prestanda utan istället använder ytterligare metoder selektivt eller som ett alternativ.
Så varför saktar STIBP som standard när människor som * verkligen * bryr sig redan inaktiverar SMT?
Jag tycker att vi borde använda samma logik som för L1TF - som standard kan vi inte ta bort prestanda. Ge ett meddelande en gång om det och låt de galna folket säga "Jag skulle hellre ha 50% framgång än att oroa mig för ett teoretiskt problem." Linus torvalds
Standardanvändningen av STIBP bör återställas
Vidare, Intels Arjan van de Ven sa att Intel och AMD inte rekommenderar användning av STIBP som standard att denna funktionalitet kan jämföras med en mycket tung hammare, eftersom den inte används i det dagliga arbetet, men är nödvändig under vissa omständigheter.
Han argumenterar för det STIBP-mekanismen som föreslås i mikrokoduppdateringen låter dig styra avstängningen av processorcacher genom att ställa in en speciell bit i CR0-registret, som inte ska göras överallt utan bara i särskilt kritiska situationer.
Intels Tim Chen föreslog att selektiv blockering av sandlådeattacker endast skulle inkludera STIBP när det uttryckligen begärs via prctl eller för processer som förbjuder skapandet av kärndumpar (PR_SET_DUMPABLE), såsom sshd.
När det gäller prestandafallet när du använder STIBP-patchar på Linux Kernel 4.20 beror resultatet till stor del på typen av belastning.
Exempelvis har tester som genomförts visat att SpecInt Rate 2006-paketet visar en prestationsminskning på 21%, medan Phoronix-testerna visar en prestandaförsämring på 3% till 20%.
Ingo Molnar, en välkänd Linux Kernel-utvecklare och författare till CFS Task Scheduler, kommenterade situationen, föreslog att man skulle lägga till listan över ändringar av prestandatestet när lösningar på problem läggs till.