mycket utvecklarna av LLVM-projektet föreslog ett antal förändringar i syfte att stärka säkerheten av projekten C + + verksamhetskritiska och tillhandahålla ett sätt att eliminera fel orsakade av buffertöverskridanden.
Som sådant fokuserar förslaget de släppte på arbete inom framför allt två områden: tillhandahålla en utvecklingsmodell som gör det möjligt att arbeta säkert med buffertar och att arbeta för att stärka säkerheten för standardfunktionsbiblioteket libc++.
Det nämns att den föreslagna säkra programmeringsmodellen för C++ «är att använda klasserna som tillhandahålls av standardbiblioteket när man arbetar med buffertar istället för att manipulera råpekare». Till exempel föreslås det att använda klasserna std::array, std::vector och std::span, som kommer att läggas till med en runtime check för out-of-bounds allokerat minne.
Vårt mål är att förbättra säkerheten för kritiska C++-kodbaser. För detta planerar vi att arbeta med två idéer.
Härdat C++ standardbibliotek
C++ Safe Buffer Programmeringsmodell och Adoptionsverktyg
Hardened libc++ är tänkt att göra C++ standardbiblioteksgränssnitt säkrare i allmänhet.C++:s säkra buffertprogrammeringsmodell tillsammans med förstärkt libc++ ger runtime-reducering av out-of-bounds minnesåtkomst. Adoptionsverktyg kommer att automatisera migreringen av kod till denna nya programmeringsmodell.
Utöver detta nämns det också för att bekämpa "farliga" programmeringsmetoder i klang, om föreslår att kompilatorvarningar ska utfärdas för alla aritmetiska pekaroperationer, som liknar clang-tyy linter-varningar när du använder flaggan "cppcoreguidelines-pro-bounds-pointer-arithmetic", vilket stöd kommer att visas i LLVM 16. För att aktivera sådana varningar kommer en separat flagga att läggas till clang, inaktiv som standard .
Det är planerat att implementera ett valfritt skyddsläge i libc++, som, när den är aktiverad, kommer att upptäcka vissa situationer som leder till odefinierat beteende vid körning. Till exempel i klasser std::span och std::vektor, kommer en out-of-bound-åtkomst att övervakas, i vilket fall programmet kommer att misslyckas.
Dessa ytterligare körtidskontroller kommer att grupperas i flera kategorier som kan kontrolleras separat. Avsikten är att en leverantör som skickar libc++ på sin plattform kan bestämma vilka kontroller som ska aktiveras i fraktbiblioteket (om några), beroende på vilken säkerhetsnivå som önskas.
Utvecklarna tror att om man lägger till sådana ändringar kommer libc++ att hållas kompatibel med C++-standarder, eftersom valet av hur man hanterar fall av odefinierat beteende ligger hos biblioteksutvecklarna, som bland annat kan behandla odefinierat beteende som ett lås som kräver att programmet utgång.
den körtidskontroller i libc++ är planerade att delas in i kategorier som kan inkluderas individuellt. Några av de föreslagna kontrollerna som inte resulterar i mer komplexa operationer eller ABI-ändringar är redan implementerade i libc++s säkra läge (säkert läge).
För att upprepa, det slutliga målet är att det levererade biblioteket ska möjliggöra dessa kontroller i produktionen; detta är inte en "endast felsökning"-funktion, även om den så småningom kommer att ersätta det länge trasiga "felsökningsläget".
Dessutom, det är planerat att förbereda en uppsättning kodkorrigeringsverktyg vilket kommer att tillåta att variabler ersätts med råpekare i behållare och att använda alternativa hanterare i situationer där behållaren inte direkt kan ersätta pekaren (till exempel kan "if(array_pointer)"-konstruktionen konverteras till "if(span.data ( )»).Inställningar kan tillämpas inte bara på lokala variabler, utan även på typparametrar med pekare.
Det nämns också att överväger en "clang static analyzer checker" ruttkänslig som varnar om std::span är konstruerad av en behållare som är mindre än den storlek som anges i spannets konstruktor. Den nämnda checkern är fristående och användbar i sig, om allt går bra kommer den att aktiveras som standard för alla användare
Slutligen om du är intresserad av att veta mer om detkan du kontrollera detaljerna i följande länk.