Fil-C का सरलीकृत मॉडल

 (corsix.org)
2 पॉइंट द्वारा GN⁺ 2026-04-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • C/C++ pointers के साथ AllocationRecord metadata जोड़कर उन्हें ट्रैक करने और dereference के समय memory boundary checks करने वाली संरचना
  • pointer assignment, arithmetic, function argument passing, return, और malloc·free calls तक मूल pointer value के साथ संबंधित metadata को भी साथ ले जाना, या उन्हें Fil-C-विशिष्ट calls में बदलने का तरीका
  • heap memory के भीतर pointers का metadata invisible_bytes में अलग से स्टोर किया जाता है, और pointer load·store के समय value और metadata दोनों को साथ पढ़ा-लिखा जाता है, साथ ही alignment checks भी लागू होते हैं
  • filc_free केवल visible_bytes और invisible_bytes को free करता है, AllocationRecord स्वयं बना रहता है, और बाद की सफाई garbage collector संभालता है; जिन local variables के address के escape होने की संभावना हो उन्हें heap promotion किया जाता है
  • threads, function pointers, memory·performance optimizations जैसी वास्तविक implementation complexities अभी भी बची हैं, लेकिन बड़े C/C++ codebases की memory safety verification या pointer provenance के ठोस system example के रूप में इसका उपयोग संभव है

Fil-C का सरलीकृत मॉडल

  • Fil-C C/C++ code को memory-safe तरीके से संभालने के लिए pointers के साथ AllocationRecord* metadata ट्रैक करने वाली संरचना का उपयोग करता है
    • वास्तविक implementation LLVM IR rewriting पर आधारित है, लेकिन यह simplified model C/C++ source code को automatic transformation के रूप में दिखाता है
    • हर function के pointer-type local variable के लिए एक corresponding AllocationRecord* local variable जोड़ा जाता है
    • उदाहरण के लिए T1* p1 के लिए AllocationRecord* p1ar = NULL जोड़ा जाता है
  • pointer local variables पर simple assignment और calculation में मूल pointer value के साथ AllocationRecord* भी साथ चलता है
    • p1 = p2 को p1 = p2, p1ar = p2ar में बदला जाता है
    • p1 = p2 + 10 में भी p1ar = p2ar साथ आता है
    • integer से pointer में cast करने पर metadata को NULL सेट किया जाता है
    • pointer को integer में बदलने वाला cast ज्यों का त्यों रहता है
  • function argument passing और return में भी pointer के साथ अतिरिक्त AllocationRecord* पास किया जाता है, और कुछ standard library calls को Fil-C-विशिष्ट functions से बदला जाता है
    • malloc और free calls को क्रमशः filc_malloc, filc_free में बदला जाता है
    • उदाहरण के लिए p1 = malloc(x); free(p1); को {p1, p1ar} = filc_malloc(x); filc_free(p1, p1ar); में बदला जाता है
  • filc_malloc केवल requested memory allocate नहीं करता, बल्कि तीन allocations करता है
    • AllocationRecord object allocation
    • वास्तविक data के लिए visible_bytes allocation
    • अदृश्य metadata storage के लिए invisible_bytes को calloc से allocate करना
    • AllocationRecord में visible_bytes, invisible_bytes, length fields होते हैं

Dereference और boundary checks

  • pointer dereference के समय साथ मौजूद AllocationRecord* का उपयोग करके boundary checks किए जाते हैं
    • जाँचा जाता है कि pointer metadata NULL न हो
    • वर्तमान pointer position और visible_bytes के starting address का अंतर निकाला जाता है
    • देखा जाता है कि offset कुल length से छोटा है या नहीं
    • बची हुई length dereference target के size के लिए पर्याप्त है या नहीं
  • read और write दोनों पर यही checking process लागू होती है
    • x = *p1 से पहले भी check किया जाता है
    • *p2 = x से पहले भी यही check लागू होता है
  • इस संरचना से pointer जिस target को दिखा रहा है, उस पर allocation range के बाहर access रोकी जाती है

Heap के अंदर pointers और invisible_bytes

  • heap memory में stored pointers को compiler local variables की तरह सीधे अलग variables से manage नहीं कर सकता, इसलिए invisible_bytes का उपयोग होता है
    • अगर visible_bytes + i location पर pointer है, तो उसका corresponding AllocationRecord* invisible_bytes + i location पर store किया जाता है
    • यानी invisible_bytes ऐसा व्यवहार करता है मानो वह AllocationRecord* element type वाला array हो
  • memory से pointer value पढ़ते या लिखते समय सामान्य boundary check के अलावा alignment check भी जोड़ा जाता है
    • offset i का sizeof(AllocationRecord*) का multiple होना जाँचा जाता है
    • तभी invisible_bytes को AllocationRecord** array की तरह सुरक्षित रूप से access किया जा सकता है
  • pointer load के समय data pointer के साथ metadata भी साथ load होता है
    • p2 = *p1 में p2 = *p1 के बाद p2ar = *(AllocationRecord**)(p1ar->invisible_bytes + i) जोड़ा जाता है
  • pointer store के समय pointer value के साथ उसका corresponding metadata भी store किया जाता है
    • *p1 = p2 में वास्तविक data store करने के बाद *(AllocationRecord**)(p1ar->invisible_bytes + i) = p2ar किया जाता है

filc_free और garbage collector

  • filc_free pointer के NULL न होने पर AllocationRecord के साथ consistency check के बाद केवल दो memory regions free करता है
    • par != NULL की जाँच
    • p == par->visible_bytes की जाँच
    • visible_bytes और invisible_bytes को free करना
    • इसके बाद visible_bytes, invisible_bytes को NULL और length को 0 में बदलना
  • filc_malloc तीन allocations करता है, लेकिन filc_free AllocationRecord object को स्वयं free नहीं करता
    • इस अंतर को garbage collector संभालता है
  • इस simplified model में stop-the-world GC पर्याप्त है, जबकि वास्तविक Fil-C parallel concurrent incremental collector का उपयोग करता है
    • GC AllocationRecord objects को follow करते हुए tracing करता है
    • unreachable AllocationRecord को free के लिए target बनाता है
  • GC अतिरिक्त रूप से दो और काम करता है
    • unreachable AllocationRecord को free करते समय filc_free call करना
    • length 0 वाले AllocationRecord को point करने वाले सभी pointers को length 0 वाले एक single canonical AllocationRecord में बदलना
  • इस व्यवहार से free न बुलाने पर भी memory leak नहीं होती
    • GC automatic free करता है
    • हालांकि free call करने से GC से पहले memory को जल्दी release करना संभव होता है
  • free के बाद संबंधित AllocationRecord अंततः unreachable हो जाता है और बाद में साफ किया जा सकता है

Local variable address escape और heap promotion

  • GC मौजूद होने पर local variables के addresses को सुरक्षित रूप से संभालने की सीमा बढ़ जाती है
    • यदि किसी local variable का address लिया गया है और compiler यह साबित नहीं कर सकता कि वह address variable की lifetime के बाहर escape नहीं करेगा, तो उसे heap allocation में promote किया जाता है
  • ऐसे local variables stack के बजाय malloc के जरिए allocate होते हैं
    • उनके लिए अलग से free insert करने की जरूरत नहीं होती
    • GC उनकी सफाई संभालता है

Fil-C version का memmove

  • C standard library का memmove arbitrary memory को संभालता है, इसलिए compiler को उसके भीतर pointers हैं या नहीं, यह पता नहीं होता
  • इसके लिए heuristic लागू की जाती है
    • arbitrary memory के भीतर pointer पूरी तरह उसी memory range के अंदर पूर्ण रूप से शामिल होना चाहिए
    • pointer सही तरह aligned होना चाहिए
  • इसी नियम की वजह से समान 8-byte move में भी व्यवहार अलग हो सकता है
    • aligned 8 bytes को एक बार में memmove करने पर संबंधित range के invisible_bytes भी साथ move होते हैं
    • अगर 1 byte करके 8 बार memmove किया जाए, तो invisible_bytes move नहीं होते

वास्तविक implementation में जुड़ने वाली अतिरिक्त जटिलताएँ

  • Threads

    • concurrency, GC complexity बढ़ाने वाला तत्व है
    • filc_free तुरंत memory free नहीं कर सकता
      • क्योंकि free करने वाला thread और उसी memory को access करने वाला दूसरा thread race condition में हो सकते हैं
    • pointers पर atomic operations के लिए भी अतिरिक्त handling चाहिए
      • मूल rewriting pointer load/store को दो load/store में बदल देती है, जिससे atomicity टूट जाती है

  • Function pointers

    • AllocationRecord के अतिरिक्त metadata से यह चिह्नित किया जाता है कि visible_bytes सामान्य data नहीं बल्कि executable code pointer है
    • function pointer p1 के जरिए call करते समय p1 == p1ar->visible_bytes की जाँच और साथ ही यह verify किया जाता है कि p1ar function pointer को represent करता है
    • function pointer पर type confusion attacks को रोकने के लिए calling ABI में भी type signature verification चाहिए
    • एक तरीका यह है कि सभी functions की type signature समान बना दी जाए
      • जैसे सभी arguments को struct में रखकर memory के जरिए pass किया जाए
      • ABI boundary पर हर function उस struct से संबंधित केवल एक AllocationRecord प्राप्त करे

  • Memory usage optimization

    • यह विचार किया जा सकता है कि filc_malloc invisible_bytes को तुरंत allocate न करे, बल्कि जरूरत पड़ने पर lazy allocation करे
    • AllocationRecord और visible_bytes को एक ही allocation में साथ रखने का तरीका भी संभव है
    • यदि underlying malloc हर allocation के सामने metadata जोड़ता है, तो उस metadata को AllocationRecord में रखने पर भी विचार किया जा सकता है

  • Performance optimization

    • Fil-C की memory safety के साथ performance cost जुड़ा हुआ है
    • खोई हुई performance को आंशिक रूप से वापस पाने के लिए कई techniques लागू की जा सकती हैं

Fil-C के उपयोग के अवसर

  • बड़े C/C++ codebases जो ऊपर से चलते हुए दिखते हैं, लेकिन जिनमें memory safety verification नहीं है, और memory safety के लिए GC तथा बड़े performance overhead को स्वीकार किया जा सकता है, वहाँ इसका उपयोग संभव है
    • Java, Go, Rust में rewrite करने से पहले इसे एक अस्थायी उपाय के रूप में देखा जा सकता है
  • ASan की तरह memory bug detection के उद्देश्य से भी Fil-C चलाया जा सकता है
    • C/C++ code को Fil-C के नीचे चलाकर memory bugs देखे जा सकते हैं
  • जिन भाषाओं में compile-time language और runtime language समान हों और compile-time safety मजबूत हो, वहाँ safe compile-time evaluation के लिए इसका उपयोग संभव है
    • उदाहरण के रूप में Zig का उल्लेख है
    • भले runtime evaluation safe न हो, compile-time evaluation में Fil-C जैसी संरचना उपयोगी हो सकती है
  • pointer provenance को संभालने वाले एक ठोस system case के रूप में भी इसका महत्व है
    • जब p1 और p2 का type समान हो, तो if (p1 == p2) { f(p1); } को if (p1 == p2) { f(p2); } में बदलने जैसी optimization संभव है या नहीं, यह प्रश्न उठता है
    • Fil-C में f को pass किया जाने वाला AllocationRecord* अलग हो सकता है, इसलिए उत्तर स्पष्ट रूप से नहीं है
    • इस अर्थ में Fil-C pointer provenance वाले एक ठोस system example की भूमिका निभाता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-04-20
Hacker News टिप्पणियाँ
  • chibicc या slimcc जैसी किसी चीज़ में invisicaps जोड़कर देखना काफ़ी दिलचस्प प्रयोग हो सकता है
    reference counting या invisible capability system के किसी variant को भी आज़माने की गुंजाइश है, और थोड़ा indirect reference cost लेकर memory बचाई जा सकती है, ऐसा लगता है
  • मैंने filc-bazel-template बनाया है और उसे Bazel target के रूप में पैकेज किया है
    उम्मीद है कि जो लोग इन दोनों को साथ इस्तेमाल करके hermetic builds बनाना चाहते हैं, उनके लिए यह मददगार होगा
  • मुझे इस वाक्य का मतलब ठीक से समझ नहीं आ रहा
    Upon freeing an unreachable AllocationRecord, call filc_free on it.
    मेरी समझ से इसका आशय शायद यह है कि किसी unreachable AR को free करने से पहले, visible_bytes और invisible_bytes fields जिन memory blocks की ओर इशारा करती हैं, उन्हें पहले free किया जाए
  • मुझे लगता है कि Fil-C अब तक देखे गए प्रोजेक्ट्स में सबसे कम आंका गया प्रोजेक्ट्स में से एक है
    सुरक्षा के लिए “rewrite it in Rust” कहने से ज़्यादा दिलचस्प यह लगता है कि मौजूदा C programs को पूरी तरह memory-safe तरीके से compile किया जा सकता है
    • मेरी नज़र में यहाँ कुछ बातें साथ में देखनी चाहिए
      पहली, Fil-C ज़्यादा धीमा है और आकार में बड़ा है. अगर यह स्वीकार्य होता, तो पिछले 10 सालों में Rust की जगह पहले Java या C# की ओर जाना चाहिए था, यह भी कहा जा सकता है
      दूसरी, आप अब भी C ही इस्तेमाल कर रहे हैं. मौजूदा codebase को maintain करने के लिए यह ठीक हो सकता है, लेकिन अगर नया code बहुत लिखना हो तो मुझे Rust काफ़ी ज़्यादा सुखद लगता है
      तीसरी, Fil-C runtime safety देता है, जबकि Rust कुछ चीज़ों को compile time पर व्यक्त कर सकता है. इससे भी आगे WUFFS जैसी भाषाएँ runtime checks के बिना compile चरण में ही safety prove करने की कोशिश करती हैं, इसलिए code तार्किक रूप से गलत हो सकता है, लेकिन crash या arbitrary code execution को रोकने की दिशा अलग है
    • मुझे नहीं लगता कि इसे यहाँ कम आंका गया है. इस पर पहले ही काफ़ी चर्चा हो चुकी है
      Fil-Qt: A Qt Base build with Fil-C experience, Linux Sandboxes and Fil-C, Ported freetype, fontconfig, harfbuzz, and graphite to Fil-C, A Note on Fil-C, Notes by djb on using Fil-C, Fil-C: A memory-safe C implementation, Fil's Unbelievable Garbage Collector जैसे threads रहे हैं
    • मेरी नज़र में Fil-C की मुख्य सीमा यह है कि यह runtime memory safety है
      आप अब भी memory-unsafe code लिख सकते हैं, बस अब उसका नतीजा vulnerability की जगह निश्चित crash बन जाता है
      अगर आप untrusted input लेने वाला web API जैसी कोई चीज़ बना रहे हैं, तो ऐसी समस्या आख़िरकार denial-of-service तक जा सकती है, इसलिए यह बेहतर तो है, लेकिन इसे काफ़ी अच्छा कहना मुश्किल है
      मैं Fil-C के काम को कमतर नहीं बता रहा, बस runtime approach की साफ़ सीमाएँ हैं
    • रुचि लेने के लिए धन्यवाद
      लेकिन निष्पक्ष होकर कहें तो Fil-C Rust से काफ़ी धीमा है, और memory भी ज़्यादा इस्तेमाल करता है
      दूसरी ओर Fil-C safe dynamic linking को support करता है, और कुछ मायनों में यह कहा जा सकता है कि यह Rust से भी ज़्यादा सख़्ती से safe है
      आख़िरकार यह trade-off है, इसलिए हर कोई अपनी परिस्थिति के हिसाब से चुन सकता है
    • मेरी भावना है कि जब C/C++ programmers से कहा जाए कि वे अपने program में garbage collector जोड़ सकते हैं, तो बहुत कम लोगों की आँखें चमकती हैं
      इसलिए यह विचार तकनीकी रूप से दिलचस्प होते हुए भी भावनात्मक स्तर पर आसानी से नहीं जंचता
  • मेरी समझ में Fil-C data race की स्थिति में memory-safe नहीं है
    capability और pointer values assignment के दौरान torn हो सकती हैं, इसलिए अगर thread interleaving खराब हुआ तो गलत pointer से object access होकर arbitrary misbehavior हो सकता है
    इस सीमा को स्वीकार किया जा सकता है, लेकिन जो लोग इस समस्या की ओर इशारा करते हैं, उनके ख़िलाफ़ समर्थकों का भी काफ़ी आक्रामक हो जाना थोड़ा निराशाजनक लगता है
    • जहाँ तक मुझे पता है, उस हिस्से को atomic ops से संभाला जा रहा है
      दुर्भाग्य से वही overhead के बड़े कारणों में से एक भी है
  • मेरी नज़र में यह आखिरकार fat pointers परिवार की तकनीकों का एक और variant है
    इस तरह के तरीके कई बार लागू किए गए और फिर इसलिए छोड़ दिए गए कि या तो security guarantees काफ़ी नहीं थीं, या non-fat ABI boundaries को पार करना मुश्किल था, या overhead बहुत ज़्यादा था
    • लेकिन आजकल फिर से ऐसा रुझान दिख रहा है कि fat pointers को hardware सीधे support करे, इसलिए शायद इसे बहुत जल्दी ख़ारिज करना ठीक नहीं होगा
      और फिर भी, मुझे नहीं लगता कि filc को सिर्फ़ साधारण fat pointer से पूरी तरह समझाया जा सकता है
    • मुझे लगता है कि यह बात भी साथ देखनी चाहिए कि कई platforms पर पहले से hardware memory tagging उपलब्ध है