Tijdens het proces van ontwikkelaar discussie van de linux-kernel over enl thema van een set van patches om kwetsbaarheden op te lossen van Spectre in de code om met gekoppelde lijsten te werken, het werd duidelijk voor veel ontwikkelaars dat het probleem zou gemakkelijker kunnen worden opgelost als: was toegestaan in de kernelcode C que voldoet aan een nieuwere versie van de standaard.
En het is dat momenteel de code die aan de Linux-kernel wordt toegevoegd, moet voldoen aan de ANSI C (C89) -specificatie, die in 1989 werd gevormd.
Dit is waarom het probleem met betrekking tot Spectre in de code was omdat se bleef een iterator gebruiken afzonderlijk gedefinieerd na de lus.
Ondanks het over het algemeen snelle karakter, vertrouwt het kernelproject op een aantal oudere tools. Hoewel critici zich graag concentreren op het uitgebreide gebruik van e-mail door de gemeenschap, is een mogelijk belangrijker anachronisme het gebruik van de 1989-versie van de C-taalstandaard voor kernelcode, een standaard die werd gecodificeerd voordat het kernelproject meer dan 30 jaar geleden begon. Het lijkt erop dat aan die langdurige praktijk een einde zou kunnen komen zodra kernel 5.18, die in mei van dit jaar wordt verwacht, zal eindigen.
Er wordt gezegd dat een macro wordt gebruikt om de elementen van de gekoppelde lijst te herhalen, en aangezien de lus-iterator aan deze macro wordt doorgegeven, wordt deze buiten de lus zelf gedefinieerd en blijft deze beschikbaar na de lus. Door de C99-standaard te gebruiken, kunnen ontwikkelaars variabelen definiëren voor de lus in het for()-blok, wat het probleem zou oplossen zonder tijdelijke oplossingen te bedenken.
Helaas zijn er meerdere locaties in de kernel waar de lijst
iterator wordt gebruikt na de lus die breekt bij een dergelijke wijziging. gelukkig
er is het script use_after_iter.cocci dat kan worden gebruikt om dergelijke te identificeren
locaties coderen. Ik moest het script een beetje aanpassen omdat het false vermindert
positieven in de oorspronkelijke use-case, maar die zijn relevant voor deze patch.Een grote verscheidenheid aan gerapporteerde codelocaties gebruikt de lijst-iterator pas na
de cyclus als er een vroege exit was (break/goto) en daarom zijn ze dat niet
relevant.
Van haar kant, Linus Torvalds was het eens met het idee om ondersteuning voor de nieuwere specificaties te kunnen implementeren en stelde verder voor om over te gaan op kernel 5.18 om de C11-standaard te gebruiken, uitgebracht in 2011.
Daarna, tijdens de voorlopige verificatie, verliep de montage op GCC en Clang in de nieuwe modus zonder afwijking. Tenzij zich onvoorziene problemen voordoen als gevolg van uitgebreidere tests, zullen de 5.18 kernel-buildscripts de optie '–std=gnu89' wijzigen in '–std=gnu11 -Wno-shift-negative-value'.
Linus Torvalds vond de patch niet erg leuk en zag niet in hoe deze zich verhield tot speculatieve uitvoeringskwetsbaarheden. Echter, nadat Koschel de situatie verder had uitgelegd, was Torvalds het ermee eens dat "dit gewoon een normale bug is, duidelijk en simpel" en zei dat het opgelost zou moeten worden, ongeacht de grotere serie. Maar toen dook hij in de echte bron van het probleem: dat de iterator die wordt doorgegeven aan de macro's voor het doorlopen van de lijst, moet worden gedeclareerd in een bereik buiten de lus zelf:
De belangrijkste reden waarom dit soort niet-speculatieve fouten kan optreden, is dat we in het verleden geen C99-achtige "variabelen declareren in lussen" hadden. Dus list_for_each_entry() - en alle anderen - filteren in principe altijd de laatste HEAD-invoer uit de lus, simpelweg omdat we de iteratorvariabele niet in de lus zelf konden declareren.
Het is ook de moeite waard om dat te vermelden de mogelijkheid om de C17-standaard te gebruiken werd overwogen, maar in dit geval zou het nodig zijn om de minimaal ondersteunde versie van GCC te verhogen, aangezien de opname van ondersteuning voor C11 voldoet aan de huidige vereisten voor de GCC-versie (5.1).
Eindelijk als u er meer over wilt wetenkunt u de details in het volgende link.