Az LLVM egy keretrendszer a fordítók fejlesztéséhez, valamint új programozási nyelvek létrehozásához és a meglévő nyelvek fejlesztéséhez.
sok Az LLVM projekt fejlesztői számos változtatást javasoltak a biztonság erősítésére a projektek közül C + + kritikus feladat, és lehetőséget biztosítanak a puffertúllépések okozta hibák kiküszöbölésére.
Mint ilyen, az általuk kiadott javaslat két területre összpontosít: egy olyan fejlesztési modell létrehozására, amely lehetővé teszi a pufferek biztonságos használatát, valamint a libc++ szabványos függvénykönyvtár biztonságának megerősítésén.
Megemlítik, hogy a javasolt biztonságos programozási modell a C++ számára «pufferekkel végzett munka során a szabványos könyvtár által biztosított osztályokat használja a nyers mutatók manipulálása helyett». Javasoljuk például az std::array, std::vector és std::span osztályok használatát, amelyek a határokon kívül lefoglalt memória futásidejű ellenőrzésével egészülnek ki.
Célunk a kritikus C++ kódbázisok biztonságának javítása. Ennek érdekében két ötleten dolgozunk.
Keményített C++ Standard Library
C++ Safe Buffer programozási modell és átvételi eszközök
A keményített libc++ célja, hogy általánosságban biztonságosabbá tegye a C++ szabványos könyvtári felületeket.A C++ biztonságos puffer programozási modellje a keményített libc++-szal együtt futásidejű mérséklést biztosít a határokon kívüli memória-hozzáféréshez. Az átvételi eszközök automatizálják a kód áttelepítését erre az új programozási modellre.
Ezen kívül azt is megemlíti a "veszélyes" programozási gyakorlatok leküzdésére csörömpölve, ha javasolja a fordítói figyelmeztetések kiadását minden mutató aritmetikai művelethez, hasonlóan a „cppcoreguidelines-pro-bounds-pointer-aritmetic” jelző használatakor a csilingelő figyelmeztetésekhez, amelyek támogatása az LLVM 16-ban jelenik meg. Az ilyen figyelmeztetések engedélyezéséhez külön jelző kerül hozzáadásra a clang-hoz, amely alapértelmezés szerint inaktív .
A tervek szerint opcionális védelmi módot implementálnak a libc++-ban, amely engedélyezve észlel bizonyos helyzeteket, amelyek futás közben definiálatlan viselkedéshez vezetnek. Például az órákon std::span és std::vector, a rendszer a határokon kívüli hozzáférést figyeli, ebben az esetben a program meghiúsul.
Ezek a további futásidejű ellenőrzések több kategóriába vannak csoportosítva, amelyek külön vezérelhetők. A cél az, hogy a libc++-t a platformjukon szállító szállító eldönthesse, mely ellenőrzéseket engedélyezze a szállítási könyvtárban (ha van ilyen), a kívánt biztonsági szinttől függően.
A fejlesztők úgy vélik, hogy az ilyen változtatások hozzáadásával a libc++ továbbra is kompatibilis lesz a C++ szabványokkal, mivel a nem definiált viselkedések kezelésének módja a könyvtár fejlesztőitől függ, akik többek között a meghatározatlan viselkedést zárolásként kezelhetik, amely megköveteli a programtól kijárat.
az A libc++ futásidejű ellenőrzéseit a tervek szerint kategóriákra osztják amelyek egyenként is beépíthetők. A javasolt ellenőrzések némelyike, amelyek nem eredményeznek bonyolultabb műveleteket vagy ABI-módosításokat, már a libc++ csökkentett módjában (csökkentett mód) vannak megvalósítva.
Ismétlem, a végső cél az, hogy a szállított könyvtár lehetővé tegye ezeket az ellenőrzéseket a termelésben; ez nem egy "csak hibakeresés" funkció, bár végül felváltja a régóta hibás "debug mode"-t.
Ezen túlmenően, a tervek szerint kódjavító eszközkészletet készítenek amely lehetővé teszi a változók nyers mutatókkal való helyettesítését a tárolókban, és alternatív kezelők alkalmazását olyan helyzetekben, amikor a tároló nem tudja közvetlenül helyettesíteni a mutatót (például az "if(array_pointer)" konstrukció átalakítható "if(span.data ( )»).A beállítások nem csak helyi változókra, hanem mutatókkal történő típusparaméterekre is alkalmazhatók.
Azt is megemlítik "csengő statikus analizátor-ellenőrzőt" fontolgatnak útvonalérzékeny, amely figyelmeztet, ha std::span olyan tárolóból készült, amely kisebb, mint a span konstruktorában megadott méret. Az említett ellenőrző önálló és önmagában is hasznos, ha minden jól megy, alapértelmezés szerint minden felhasználó számára engedélyezve lesz
Végül ha érdekel, hogy többet tudjon meg róla, ellenőrizheti a részleteket a következő link.