วิธีคอมไพล์ C ให้เป็น Rust ที่ปลอดภัย

 (arxiv.org)
2 คะแนน โดย GN⁺ 2024-12-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • การคอมไพล์ C ให้เป็น Rust ที่ปลอดภัย

  • แม้ว่า Rust จะได้รับความนิยมเพิ่มขึ้นอย่างรวดเร็ว แต่ฐานโค้ดที่สำคัญจำนวนมากยังคงถูกเขียนด้วย C และการเขียนใหม่ด้วยตนเองไม่สามารถทำได้จริง ดังนั้นการแปลง C เป็น Rust อัตโนมัติจึงกลายเป็นทางเลือกที่น่าสนใจ

  • การวิจัยหลายชิ้นก่อนหน้าได้พัฒนาทางด้านการใช้ความสามารถหลากหลายของ Rust มากขึ้นเรื่อย ๆ (เช่น unsafe) เพื่อจัดการส่วนต่าง ๆ ของ C อย่างต่อเนื่องมากขึ้น แม้แนวโน้มการอัตโนมัติจะน่าดึงดูด แต่การสร้างโค้ดที่พึ่งพา unsafe จะทำให้การรับประกันความปลอดภัยด้านหน่วยความจำที่ Rust มอบให้ออกใช้งานไม่ได้ และดังนั้นประโยชน์หลักของการย้ายฐานโค้ดเดิมไปยังภาษาที่ปลอดภัยด้านหน่วยความจำจึงหายไป

  • เราจึงสำรวจแนวทางทางเลือกสำหรับการแปล C เป็น Rust ที่ปลอดภัย กล่าวคือ การสร้างโค้ดที่ปฏิบัติตามระบบชนิดของ Rust เพื่อให้สามารถรับประกันความปลอดภัยด้านหน่วยความจำได้อย่างง่ายดาย

  • งานของเรามีส่วนร่วมเชิงนวัตกรรมหลายประการ:

    • การแปลเชิงชนิดของบางส่วนของ C เป็น Rust ที่ปลอดภัย
    • การวิเคราะห์เชิงคงที่ใหม่แบบต้นไม้การแบ่ง โดยใช้ slice และการดำเนินการแบ่งของ Rust เพื่อแทนการคำนวณพอยน์เตอร์ของ C
    • การวิเคราะห์ที่สามารถอนุมานได้อย่างแม่นยำว่าการยืมใดควรเป็นแบบเปลี่ยนแปลงได้
    • กลยุทธ์การคอมไพล์สำหรับชนิดโครงสร้างของ C ที่เข้ากันได้กับการแยกแยะการจัดสรรเป็นเจ้าของและไม่เป็นเจ้าของของ Rust

  • เราได้นำแนวทางนี้ไปใช้กับฐานโค้ด C ที่ผ่านการตรวจสอบแบบทางการที่มีอยู่แล้ว ได้แก่ ไลบรารีเข้ารหัส HACL* และตัวแยกวิเคราะห์และตัวทำให้เป็นลำดับแบบไบนารีของ EverParse โดยแสดงให้เห็นว่าชุดย่อยของ C ที่รองรับนั้นเพียงพอสำหรับการแปลแอปพลิเคชันทั้งสองเป็น Rust ที่ปลอดภัย

  • ผลการประเมินพบว่า สำหรับบางส่วนที่ละเมิดข้อกำหนดเรื่อง aliasing ของ Rust สามารถแก้ด้วยการแก้ไขเฉพาะจุดแบบอัตโนมัติได้ และผลกระทบต่อประสิทธิภาพจากการเพิ่มกลยุทธ์สำเนาเชิงกลยุทธ์บางส่วนยังมีน้อยมาก

  • โดยเฉพาะอย่างยิ่ง เมื่อใช้แนวทางนี้กับ HACL* ผลลัพธ์คือไลบรารีการเข้ารหัสที่ผ่านการพิสูจน์แล้ว 80,000 บรรทัด ซึ่งครอบคลุมอัลกอริทึมสมัยใหม่ทั้งหมด ถูกเขียนขึ้นด้วย Rust อย่างบริสุทธิ์ ซึ่งเป็นกรณีแรก

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

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

 
GN⁺ 2024-12-22
ความคิดเห็นของ Hacker News

  • ผมได้ข้อสรุปบางประการขณะพอร์ตโปรเจกต์ไปใช้ Rust

    • การแปลงโปรแกรมภาษา C เป็น Rust ช่วยค้นหา bug ได้เร็วขึ้น เนื่องจากข้อจำกัดที่เข้มงวดของ Rust
    • การแปลงจาก C เป็น Rust อัตโนมัติก็ยังไม่ใช่การแก้ปัญหาที่สมบูรณ์ เนื่องจากการออกแบบของทั้งสองภาษาต่างกันอย่างพื้นฐาน
    • ในบางกรณีการพอร์ตจาก C ไป Rust อาจทำไม่ได้ ซึ่งอาจเกิดจากความไม่ปลอดภัยที่ฝังอยู่ในตัวการออกแบบเอง
    • เครื่องมือที่ดีขึ้นจะช่วยทำให้กระบวนการพอร์ตราบรื่นขึ้น

  • ฐานโค้ด C ที่ผ่านการตรวจสอบอย่างเป็นทางการกับฐานโค้ดระบบ C ทั่วไปนั้นแตกต่างกัน

  • ในปี 2002 มีงานวิจัยเสนอเรื่อง Cyclone ซึ่งเป็น C dialect ที่ปลอดภัย และเมื่อย้ายโค้ดจาก C ไป Cyclone ก็พบ bug ที่เกี่ยวกับความปลอดภัย

    • การแปลงทั้งแบบ manual หรืออัตโนมัติเหล่านี้อาจเพิ่มการยอมรับภาษาที่ปลอดภัย และมีโอกาสค้นพบ bug ที่มีอยู่เดิมได้มากขึ้น

  • การแปลตรง ๆ ไปยัง Rust สามารถสร้างทั้งส่วนที่ปลอดภัยและไม่ปลอดภัยได้ โดยงาน manual จึงอาจโฟกัสไปที่การยืนยันความปลอดภัยของพื้นที่ที่ไม่ปลอดภัย

    • แม้พื้นที่ที่ไม่ปลอดภัยจะมีขนาดใหญ่ก็ยังอาจมีข้อดีได้

  • ความคาดหวังเกี่ยวกับแนวทางที่คอมไพล์เฉพาะส่วนเล็ก ๆ ของ C นั้นไม่สูงมาก

    • เพราะโมเดล ownership ของ Rust แตกต่างจากโปรแกรม C ในโลกจริงมากเกินไป

  • มีคำถามเกี่ยวกับการเปรียบเทียบกับความสามารถในการแปลง C ของ Zig

    • Zig สร้างสภาพแวดล้อมผสมโค้ดใหม่กับโค้ด C เดิมได้อย่างดี และยังใช้งานเป็น C compiler ได้ด้วย
    • อยากรู้ว่าทำไมผู้ดูแล Linux kernel ไม่ถือว่า Zig เป็นทางเลือกแทน C

  • คำถามเรื่องว่า C2Rust สามารถสร้างโค้ดที่ถูกต้องตามหลักการอย่างเป็นทางการได้หรือไม่

    • ไม่เห็นลิงก์ไปยังซอร์สโค้ดที่ใช้ในการสร้าง Rust

  • หากไลบรารี C เดิมยังใช้งานได้ การแปลโดยใช้ unsafe ของ Rust อาจมีคุณค่า

    • Rust โดยทั่วไปค่อนข้างขาด libraries

  • น่าสนใจที่ระดับ optimization สูงไม่ได้ช่วยเพิ่มความเร็วของ Rust มาก

    • คำถามคือการคอมไพล์ C ไป Rust ในรอบเดียวด้วยระดับ O3 จะทำงานได้ดีแค่ไหน