บันทึกของ djb เกี่ยวกับการใช้งาน Fil-C

 (cr.yp.to)
2 คะแนน โดย GN⁺ 2025-11-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Fil-C คอมไพเลอร์ C/C++ แบบใหม่ที่มี ความปลอดภัยของหน่วยความจำ แสดงให้เห็นถึง ความเข้ากันได้สูง กับโค้ดเดิม โดยไลบรารีและแอปพลิเคชันส่วนใหญ่ทำงานได้โดยไม่ต้องแก้ไข
  • มีขั้นตอนสำหรับ คอมไพล์จากซอร์สและติดตั้ง Fil-C บน Debian 13 พร้อม สคริปต์ติดตั้งอัตโนมัติ สำหรับคอมไพล์ glibc และ binutils ใหม่ด้วย Fil-C
  • ใน ไมโครบेंช์มาร์กซอฟต์แวร์เข้ารหัสราว 9000 รายการ Fil-C ใช้ จำนวน cycle มากกว่า clang 1~4 เท่า
  • มีความพยายาม ผนวกรวมเข้ากับระบบสร้างแพ็กเกจ Debian โดยเพิ่ม ABI ใหม่ (amd64fil0) เพื่อให้สามารถ ติดตั้งแพ็กเกจที่อิงกับ Fil-C ควบคู่กันได้
  • Fil-C มุ่งเป้าไปที่ทั้ง ความปลอดภัยของหน่วยความจำและความเข้ากันได้กับระบบนิเวศเดิม พร้อมแสดงศักยภาพในการขยายสู่ระบบที่อิงกับ Debian

ภาพรวมของ Fil-C และความประทับใจแรกเริ่ม

  • Fil-C เป็น คอมไพเลอร์ C/C++ ที่รับประกันความปลอดภัยของหน่วยความจำ และมี ความเข้ากันได้สูง กับโค้ดเดิม
    • ไลบรารีและแอปพลิเคชันส่วนใหญ่ทำงานได้โดยไม่ต้องแก้ไข
    • แม้บางกรณีจะต้องมีการแก้ไขเพิ่มเติม แต่ก็ไม่ใช่ปัญหาที่ยากจะแก้
  • ผู้เขียนตั้งเป้าที่จะ ย้ายหลายระบบที่ดูแลอยู่ไปใช้โค้ดที่คอมไพล์ด้วย Fil-C เพื่อเพิ่มการป้องกัน
  • สภาพแวดล้อมทดสอบคือ Debian 13, AMD Ryzen 5 7640HS (6 คอร์ 12 เธรด), RAM 12GB, สว็อป 36GB

เอกสารและสคริปต์ที่เกี่ยวข้อง

  • มีการเผยแพร่ สคริปต์ diff สำหรับการตรวจสอบ เพื่อเปรียบเทียบความแตกต่างระหว่าง Fil-C กับซอร์สต้นน้ำระดับบน (เช่น clang, glibc)
  • มีสคริปต์ filian-install-compiler สำหรับดาวน์โหลด คอมไพล์ และติดตั้ง Fil-C, glibc และ binutils บน Debian 13
    • เวลาที่ใช้ทั้งหมด: real 86 นาที, user 477 นาที, system 52 นาที
  • มีสคริปต์ filian-install-packages สำหรับสร้าง Debian source package ด้วย Fil-C
    • ยืนยันแล้วว่าแพ็กเกจบางส่วน (เช่น bzip2) สร้างได้ตามปกติ
  • มีการเผยแพร่ กราฟประสิทธิภาพ Fil-C vs. clang
    • เป็นผลจากไมโครบेंช์มาร์กที่เกี่ยวข้องกับงานเข้ารหัสประมาณ 9000 รายการ
    • โค้ดที่คอมไพล์ด้วย Fil-C ใช้ cycle มากกว่า clang 1~4 เท่า

การติดตั้งและการคอมไพล์ Fil-C

  • หลังติดตั้งแพ็กเกจที่จำเป็นด้วยสิทธิ root แล้ว จะทำการคอมไพล์ด้วยผู้ใช้ที่ไม่มีสิทธิพิเศษชื่อ filc
  • ซอร์สของ Fil-C รวม glibc และไลบรารีกับแอปพลิเคชันระดับสูงอีกหลายรายการ
  • คำสั่ง build: time ./build_all_fast_glibc.sh
    • สามารถเลือกใช้ musl ได้เช่นกัน แต่มี ความไม่เข้ากันได้ กับบางแพ็กเกจ (เช่น attr, elfutils, sed, vim)
  • หากเกิดปัญหาหน่วยความจำไม่พอระหว่าง build แก้ได้ด้วยการขยายพื้นที่สว็อปเป็น 36GB
    • ใช้สว็อปสูงสุดประมาณ 19GB และ RAM 12GB
    • บนเซิร์ฟเวอร์ขนาดใหญ่ (128 คอร์, RAM 512GB) การ build Fil-C ใช้เวลา 8 นาที และ musl ใช้เวลา 6 นาที

การ build ไลบรารีและแอปพลิเคชันเพิ่มเติม

  • Fil-C มี build_all_slow.sh สำหรับ build ไลบรารีและแอปพลิเคชันจำนวนมาก
  • มีการเขียนสคริปต์ build-parallel-20251023.py เพื่อทำงานนี้แบบขนาน
    • แม้เกิดข้อผิดพลาดก็จะไม่หยุด แต่ดำเนินการ build ทั้งหมดต่อไป
    • การ build แบบขนานช่วยลดเวลาได้
  • บนระบบ phoenix สำเร็จ 60 จาก 61 เป้าหมาย (real 101 นาที)
  • มีเพียง libcap ที่ build ไม่สำเร็จ (เกิดข้อผิดพลาดในการโหลด liblto_plugin.so)
  • util-linux ต้องมีการแก้ไขที่เกี่ยวข้องกับ syscall
  • แพ็กเกจหลักอื่น ๆ ที่เหลือ (เช่น attr, bash, curl, openssl, vim) build สำเร็จโดยไม่มีปัญหา

ไลบรารีและแอปพลิเคชันเพิ่มเติมที่ทดสอบแล้ว

  • boost 1.89.0: ส่วนใหญ่ทำงานได้ตามปกติ แต่ต้องแก้ไขบางส่วนที่เกี่ยวข้องกับ vfork
  • cdb-20251021: ทำงานได้ตามปกติ โดยมีความแตกต่างของข้อความผิดพลาดในการทดสอบ OOM แบบจงใจ
  • libcpucycles, libgc (ใช้แทน gshim), libntruprime, lpeg, luv เป็นต้น build และทดสอบผ่าน
  • ยืนยันว่าแอปพลิเคชัน CLI หลักอย่าง mutt, tig, w3m ก็ทำงานได้ตามปกติ

การผนวกรวมกับ Debian (Filian)

  • ใช้โครงสร้าง multi-architecture ของ Debian เพื่อเพิ่ม ABI สำหรับ Fil-C โดยเฉพาะ (amd64fil0)
    • ตัวอย่างเช่น สามารถติดตั้งเวอร์ชันที่คอมไพล์ด้วย Fil-C ได้ด้วย apt install bash:amd64fil0
  • Fil-C ใช้ไดเรกทอรีของตัวเองแทน /usr/include จึงเกิด ปัญหาเส้นทางไฟล์ header ไม่ตรงกัน
    • สคริปต์ filian-install-compiler ปรับสิ่งนี้ให้สอดคล้องกับเส้นทางมาตรฐานของ Debian
  • มีการเพิ่มการรับรู้สถาปัตยกรรม Fil-C ให้กับเครื่องมือ build ของ Debian (เช่น dpdk-buildpackage, sbuild)
    • มีการแก้ไข /usr/share/dpkg/cputable, config.sub เป็นต้น
  • วาง Fil-C และ standard library ไว้ในเส้นทาง /usr/libexec/fil/amd64
    • ทำให้สามารถใช้คำสั่ง filcc, fil++ ได้ทั่วทั้งระบบ

ตัวอย่างการ build แพ็กเกจ Debian

  • มีสคริปต์ช่วยเหลือ fillet สำหรับปรับ symbol และเส้นทางติดตั้งของ Debian source package
  • ผลการ build แพ็กเกจ tinycdb ด้วย Fil-C คือ สร้างแพ็กเกจ .deb สำหรับ amd64fil0 โดยเฉพาะ 3 รายการ
    • หลังติดตั้ง สามารถตรวจสอบ symbol ของ Fil-C (pizlonated_) และเส้นทางไลบรารีได้ด้วยคำสั่ง nm, ldd
    • เมื่อรันจะยืนยันได้ว่าฟังก์ชันป้องกัน runtime ของ Fil-C ทำงานจริง (แสดงข้อความบล็อกการละเมิด “memory safety”)

การ build แพ็กเกจ Debian เพิ่มเติม

  • libc-dev: สร้างแพ็กเกจจำลองเพื่อแก้ปัญหา dependency
  • ncurses: build ด้วย Fil-C แล้วติดตั้งได้
  • libmd: ต้องคอมไพล์ใหม่เนื่องจากเวอร์ชันไม่ตรงกันระหว่างสถาปัตยกรรม
  • readline: ต้องมี symbolic link สำหรับเส้นทาง header
  • lua5.4: ทำงานได้ตามปกติหลังแก้ dependency ของ readline

บทสรุป

  • Fil-C เป็นความพยายามที่จะทำให้เกิดทั้ง การเสริมความปลอดภัยของหน่วยความจำและความเข้ากันได้กับระบบนิเวศ C/C++ เดิม พร้อมกัน
  • ได้พิสูจน์แล้วว่ามี ความเป็นไปได้ในการ build และผนวกรวมแพ็กเกจบนสภาพแวดล้อม Debian
  • แม้จะยังต้องปรับสคริปต์ build และเส้นทาง header บางส่วน แต่ก็ รองรับแพ็กเกจโอเพนซอร์สหลักส่วนใหญ่ได้แล้ว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-11-03
ความคิดเห็นจาก Hacker News
  • เมื่อดูเบนช์มาร์กที่ลิงก์ไว้ จะเห็นว่าบางกรณี Fil-C ดูเหมือนจะเร็วกว่า C
    คิดว่าน่าจะเป็นเพราะ ความแปรปรวนของไมโครเบนช์มาร์ก แต่บางผลลัพธ์ก็ดูเร็วเกินไปจนทำให้อยากรู้ว่ามี ปัญหาด้านความถูกต้อง หรือไม่
  • ผู้เขียนประทับใจ Fil-C มากจนกำลังพยายามรีบิลด์ทั้งระบบ Debian ด้วย Fil-C
    เพื่อการนี้จึงได้สร้างและแบ่งปัน ไลบรารี GC shim และสคริปต์สำหรับการบิลด์
  • บนเซิร์ฟเวอร์มี swap แค่ 12GB จึงต้องรีสตาร์ตหลายครั้งระหว่างคอมไพล์ Fil-C เพราะหน่วยความจำไม่พอ
    พอเพิ่ม swap เป็น 36GB ก็สามารถบิลด์ได้ตามปกติ และใช้สูงสุดถึง 19GB swap + 12GB RAM
    บนเซิร์ฟเวอร์ 128 คอร์, RAM 512GB ใช้เวลา 8 นาทีในการบิลด์ Fil-C และ 6 นาทีสำหรับ musl
    ดูเหมือนว่า Fil-C จะทำ การวิเคราะห์แบบสถิต ค่อนข้างมาก
    • นั่นอาจเป็นกระบวนการบิลด์ LLVM+Clang เองมากกว่า
  • น่าสนใจที่ cdb เวอร์ชัน 64 บิตที่เพิ่งเปิดตัวรองรับฐานข้อมูลระดับเอกซะไบต์
    ตรวจสอบได้ที่ cdb.cr.yp.to และมีการกล่าวถึงว่าซับโดเมน cdb ใหม่ใช้ pqconnect
    • ที่จริงแล้ว cdb.cr.yp.to ไม่มี NS record ดังนั้นจึงเป็นโครงสร้างที่ DNSCurve ทำงานอยู่
      pqconnect ใช้ในขั้นตอนการเชื่อมต่อ HTTP(S) และทั้งสองอย่างต่างก็ เข้ารหัสกุญแจสาธารณะไว้ใน DNS แต่มีบทบาทต่างกัน
      pqconnect ใส่ กุญแจสาธารณะไว้ใน CNAME แบบเดียวกับ CurveCP
    • ตาม RFC1034 นั้น cdb.cr.yp.to สามารถมองได้ว่าเป็น ซับโดเมน(subdomain) ของ cr.yp.to และ yp.to
      อย่างไรก็ตาม ส่วน pq1 ไม่ใช่กุญแจสาธารณะ แต่เป็นแฮชของกุญแจสาธารณะระยะยาวของเซิร์ฟเวอร์
    • มีการใช้ pqconnect มาตั้งแต่ก่อนหน้านี้แล้ว แต่ CNAME ของ cdb.cr.yp.to ดูเหมือนจะเป็น ของที่เพิ่งเพิ่มเข้ามาราววันที่ 21 ตุลาคม
      โน้ตเกี่ยวกับ Fil-C ถูกส่งเมื่อ 3 วันก่อน
      เธรดที่เกี่ยวข้อง
    • อ้างอิงเพิ่มเติม มีการพูดคุยที่เกี่ยวข้องเมื่อ 11 วันก่อนด้วย
      ลิงก์การสนทนาก่อนหน้า
  • คิดว่าเป็นโปรเจ็กต์ที่ยอดเยี่ยม
    เป้าหมายน่าจะเป็นการทำให้โปรแกรม C/C++ ส่วนใหญ่สามารถรันได้อย่างปลอดภัย โดยไม่ต้องเขียนใหม่เป็น Rust
    และก็สงสัยด้วยว่า Epic Games เข้ามาเกี่ยวข้องอย่างไร
    • Fil-C เป็น ภาษาแบบอิง garbage collection จึงช้ากว่า C มาก
      แทนที่จะใช้เขียนโค้ดใหม่ น่าจะเหมาะกับการใช้ครอบโค้ดเดิมให้ปลอดภัยแบบ WASM sandboxing มากกว่า
      แต่ Fil-C ก็สามารถจับ แครชได้แม่นยำกว่า
  • ดีใจที่งานของ Phil ดูเหมือนจะได้รับ การยอมรับอย่างเหมาะสมเสียที
    น่าจะมีจุดที่ Rust โหมด unsafe เอาไปอ้างอิงได้เช่นกัน
    โดยเฉพาะวิธี ลิงก์แบบสแตติก กับดีเพนเดนซีที่คอมไพล์ด้วย Fil-C นั้นน่าสนใจ
    • แต่ตอนนี้ Fil-C ยัง ไม่รองรับ FFI
      เพราะ Fil-C ต้องควบคุมทั้งโปรแกรมเพื่อการติดตามพอยน์เตอร์ ดังนั้น FFI จึงไม่สอดคล้องกับสถาปัตยกรรมนี้
  • มีการรวบรวมเธรดสำคัญเกี่ยวกับ Fil-C ไว้
    เช่น Fil-C: A memory-safe C implementation,
    Safepoints and Fil-C,
    Fil’s Unbelievable Garbage Collector เป็นต้น
    การถกเถียงเรื่อง ความปลอดภัยของหน่วยความจำ ดำเนินต่อเนื่องตลอดช่วงปี 2024~2025
  • สำหรับคนที่ยังไม่รู้ว่า Fil-C คืออะไร มีการสรุปไว้ว่า
    Fil-C คือ อิมพลีเมนเทชันที่ปลอดภัยด้านหน่วยความจำและเข้ากันได้กับ C/C++ โดยโค้ดส่วนใหญ่คอมไพล์ได้แทบไม่ต้องแก้ไข
    ข้อผิดพลาดด้านหน่วยความจำทั้งหมดจะถูก ตรวจจับเป็น panic และรับประกันความปลอดภัยด้วย GC แบบ concurrent และ InvisiCaps
    ดูคำอธิบายเพิ่มเติมได้ที่ เว็บไซต์ทางการ
    • การใช้ Fil-C หมายความว่าต้อง ยอมรับการมี Garbage Collector ในรันไทม์
  • น่าแปลกใจที่สคริปต์ build_all_fast_glibc.sh ต้องใช้หน่วยความจำถึง 31GB
    อยากรู้เหตุผล และอยากลองใช้ Fil-C ด้วยตัวเอง
    • นั่นเป็นเพราะ ขั้นตอนบิลด์และลิงก์ของ LLVM หนักมาก
  • น่าสนใจที่ได้เห็นนักเข้ารหัสลับชื่อดังใช้ bash กับ curl