masse udviklere af LLVM-projektet foreslog en række ændringer med henblik på at styrke sikkerheden af projekterne C + + missionskritisk og giver et middel til at eliminere fejl forårsaget af bufferoverskridelser.
Som sådan fokuserer det forslag, de udgav, på arbejde inden for især to områder: at levere en udviklingsmodel, der gør det muligt at arbejde sikkert med buffere, og arbejde for at styrke sikkerheden i libc++ standardfunktionsbiblioteket.
Det nævnes, at den foreslåede sikker programmeringsmodel for C++ «er at bruge klasserne leveret af standardbiblioteket, når du arbejder med buffere i stedet for at manipulere rå pointere». For eksempel foreslås det at bruge klasserne std::array, std::vector og std::span, som vil blive tilføjet med en runtime check for out-of-bounds allokeret hukommelse.
Vores mål er at forbedre sikkerheden for kritiske C++-kodebaser. Til dette planlægger vi at arbejde på to ideer.
Hærdet C++ Standardbibliotek
C++ Safe Buffer Programmeringsmodel og Adoptionsværktøjer
Hardened libc++ er beregnet til at gøre C++ standard biblioteksgrænseflader mere sikre generelt.C++'s sikre buffer programmeringsmodel sammen med hærdet libc++ giver runtime reduktion af out-of-bounds hukommelsesadgang. Adoptionsværktøjer vil automatisere migreringen af kode til denne nye programmeringsmodel.
Ud over dette nævnes det også at bekæmpe "farlig" programmeringspraksis i klang, hvis foreslår at udstede kompileringsadvarsler for alle pointer-aritmetiske operationer, svarende til klang-ryddelige linter-advarsler ved brug af flaget "cppcoreguidelines-pro-bounds-pointer-arithmetic", hvilket understøttes i LLVM 16. For at aktivere sådanne advarsler vil der blive tilføjet et separat flag til clang, inaktivt som standard .
Det er planlagt at implementere en valgfri beskyttelsestilstand i libc++, som, når den er aktiveret, vil opdage nogle situationer, der fører til udefineret adfærd under kørsel. For eksempel i klasser std::span og std::vektor, vil en out-of-bound-adgang blive overvåget, i hvilket tilfælde programmet mislykkes.
Disse yderligere runtime-tjek vil blive grupperet i flere kategorier, der kan kontrolleres separat. Hensigten er, at en leverandør, der sender libc++ på deres platform, kan bestemme, hvilke kontroller der skal aktiveres i forsendelsesbiblioteket (hvis nogen), afhængigt af det ønskede sikkerhedsniveau.
Udviklerne mener, at tilføjelse af sådanne ændringer vil holde libc++ kompatibel med C++-standarder, da valget af, hvordan man håndterer tilfælde af udefineret adfærd, ligger hos biblioteksudviklerne, som blandt andet kan behandle udefineret adfærd som en lås, der kræver, at programmet skal Afslut.
den Runtime-tjek i libc++ er planlagt opdelt i kategorier der kan indgå individuelt. Nogle af de foreslåede kontroller, der ikke resulterer i mere komplekse operationer eller ABI-ændringer, er allerede implementeret i libc++'s sikker tilstand (sikker tilstand).
For at gentage, er det endelige mål, at det afsendte bibliotek muliggør disse kontroller i produktionen; dette er ikke en "kun debug"-funktion, selvom den i sidste ende vil erstatte den længe brudte "debug mode".
Derudover det er planlagt at udarbejde et sæt kodekorrektionsværktøjer som vil tillade variabler at blive erstattet med rå pointere i containere og at anvende alternative behandlere i situationer, hvor containeren ikke direkte kan erstatte pointeren (f.eks. kan "if(array_pointer)"-konstruktionen konverteres til "if(span.data ( )»).Indstillinger kan anvendes ikke kun på lokale variabler, men også på typeparametre med pointere.
Det nævnes også overvejer en "clang static analyzer checker" rutefølsom, der advarer hvis std::span er konstrueret af en beholder, der er mindre end den størrelse, der er angivet i spændviddens konstruktør. Det nævnte tjek er selvstændigt og nyttigt i sig selv, hvis alt går vel vil det være aktiveret som standard for alle brugere
Endelig hvis du er interesseret i at vide mere om det, kan du kontrollere detaljerne i følgende link.