ชุมชนภาษาโปรแกรมมิ่ง Fil-C กำลังหารือกันอย่างกระตือรือร้นเกี่ยวกับความท้าทายสองประการหลักในการพัฒนาที่อาจส่งผลกระทบอย่างมีนัยสำคัญต่อการนำภาษานี้ไปใช้ในสภาพแวดล้อมการผลิต การหารือเหล่านี้มุ่งเน้นไปที่การสนับสนุนการเรียกระบบ vfork() เพื่อการสร้างกระบวนการที่เร็วขึ้น และการเปิดใช้งานโค้ดแอสเซมบลีเข้ารหัสแบบเวลาคงที่
ภาวะที่กลืนไม่เข้าคายไม่ออกของประสิทธิภาพ vfork()
การถกเถียงที่ร้อนแรงได้เกิดขึ้นรอบการพัฒนาการสนับสนุน vfork() ใน Fil-C แตกต่างจากการเรียกระบบ fork() แบบดั้งเดิม vfork() นำเสนอการสร้างกระบวนการที่เร็วกว่ามากโดยการแชร์หน่วยความจำระหว่างกระบวนการแม่และลูกจนกว่าลูกจะเรียก exec() หรือ exit() ข้อได้เปรียบด้านประสิทธิภาพนี้กลายเป็นสิ่งสำคัญสำหรับแอปพลิเคชันที่มีการใช้หน่วยความจำขนาดใหญ่ เช่น ตัวจัดการทรัพยากรและตัวเปิดใช้งานแบบขนาน ที่ต้องการสร้างกระบวนการหลายสิบหรือหลายร้อยกระบวนการ
ความท้าทายอยู่ที่ข้อกำหนดด้านความปลอดภัยที่เข้มงวดของ vfork() กระบวนการลูกสามารถดำเนินการได้เฉพาะการทำงานที่ปลอดภัยต่อสัญญาณแบบอะซิงโครนัสเท่านั้น และการละเมิดกฎเหล่านี้อาจทำให้สถานะหน่วยความจำของแม่เสียหายได้ ผู้สร้าง Fil-C ยอมรับความซับซ้อนนี้ โดยระบุว่าการพัฒนาการตรวจสอบความปลอดภัยที่เหมาะสมจะต้องมีการปรับเปลี่ยนอย่างกว้างขวางตลอดระบบรันไทม์ ความเสี่ยงของการนำบั๊กด้านเสถียรภาพและความปลอดภัยเข้ามาทำให้สิ่งนี้เป็นฟีเจอร์ที่มีต้นทุนสูงและความเสี่ยงสูง แม้จะมีประโยชน์ด้านประสิทธิภาพที่ชัดเจน
หมายเหตุ: vfork() เป็นการเรียกระบบ Unix ที่สร้างกระบวนการใหม่โดยไม่คัดลอกหน่วยความจำของแม่ ทำให้เร็วกว่าแต่มีข้อจำกัดมากกว่า fork()
ความท้าทายทางเทคนิคที่สำคัญ:
- การใช้งาน vfork(): ต้องการการตรวจสอบความปลอดภัยขณะรันไทม์อย่างครอบคลุมและมีความเสี่ยงของการเสียหายของหน่วยความจำ
- การรวม Assembly: ต้องการการพัฒนา FFI สำหรับ calling conventions ที่เป็นเอกลักษณ์ของ Fil-C
- การสนับสนุนการเข้ารหัส: จำเป็นสำหรับแอปพลิเคชันความปลอดภัยในการผลิตที่ต้องการการดำเนินการแบบ constant-time
- ผลกระทบต่อประสิทธิภาพ: vfork() ให้การเร่งความเร็วที่สำคัญสำหรับแอปพลิเคชันที่ใช้ process มาก
- การรับประกันความปลอดภัย: ฟีเจอร์ทั้งสองต้องรักษาคำมั่นสัญญาด้านความปลอดภัยของหน่วยความจำของ Fil-C
การรวมโค้ดแอสเซมบลีเข้ารหัส
การหารือที่สำคัญอีกประการหนึ่งมุ่งเน้นไปที่การสนับสนุนโค้ดแอสเซมบลีที่ปรับแต่งด้วยมือ โดยเฉพาะอย่างยิ่งสำหรับการทำงานเข้ารหัสที่ต้องการการดำเนินการแบบเวลาคงที่ ความสามารถนี้มีความจำเป็นสำหรับแอปพลิเคชันความปลอดภัยในการผลิต เนื่องจากการเปลี่ยนแปลงของเวลาในโค้ดเข้ารหัสสามารถรั่วไหลข้อมูลที่ละเอียดอ่อนเกี่ยวกับคีย์หรือข้อมูลข้อความต้นฉบับ
ชุมชนมองเห็นสิ่งนี้เป็นอุปสรรคสำคัญต่อการนำไปใช้ นักพัฒนาหลายคนแสดงความเห็นว่าพวกเขาจะไม่พิจารณาใช้ Fil-C ในการผลิตหากไม่มีความสามารถในการรันการพัฒนาแอสเซมบลีแบบเวลาคงที่ของ OpenSSL ความท้าทายเกี่ยวข้องกับการสร้างอินเทอร์เฟซฟังก์ชันต่างประเทศ (FFI) ที่อนุญาตให้โค้ดแอสเซมบลีทำงานกับการเรียกใช้แบบเฉพาะและระบบจัดการหน่วยความจำของ Fil-C ในขณะที่รักษาการรับประกันความปลอดภัย
ผมอยากจะสามารถรัน OpenSSH โดยใช้ Fil-C และผมไม่อยากต้องกังวลเกี่ยวกับการเข้ารหัสที่เขียนด้วย C ที่ไม่ใช่แบบเวลาคงที่
โซลูชันทางเทคนิคและวิธีแก้ไขชั่วคราว
โซลูชันที่เป็นไปได้หลายแบบได้รับการเสนอสำหรับทั้งสองความท้าทาย สำหรับ vfork() ทางเลือกอื่นเช่น posix_spawn() สามารถให้ประโยชน์ด้านประสิทธิภาพที่คล้ายกันพร้อมการรับประกันความปลอดภัยที่ดีกว่า สำหรับโค้ดเข้ารหัส นักพัฒนาเสนอแนะการใส่ฟังก์ชันแอสเซมบลีไว้ในวงเล็บด้วยการเรียกออก/เข้าพิเศษ คล้ายกับวิธีที่ Fil-C จัดการการเรียกระบบ
แนวทางที่มีแนวโน้มดีที่สุดสำหรับการสนับสนุนแอสเซมบลีเกี่ยวข้องกับการแปลงโค้ดแอสเซมบลีที่มีอยู่เพื่อแทรกคำสั่งความปลอดภัยเพิ่มเติมโดยไม่เปลี่ยนพฤติกรรมอัลกอริทึมหลัก สิ่งนี้จะรักษาคุณสมบัติเวลาคงที่ในขณะที่รับประกันความปลอดภัยของหน่วยความจำภายใต้กฎของ Fil-C
วิธีแก้ไขชั่วคราวและทางเลือกในปัจจุบัน:
- สำหรับ vfork(): ใช้ posix_spawn() หรือปรับปรุงการใช้งาน fork() ที่มีอยู่ให้เหมาะสม
- สำหรับ Assembly: รองรับ static inline assembly แล้ว, out-of-line assembly ต้องใช้ FFI
- สำหรับ Crypto: แปลงโค้ด assembly ด้วยคำสั่งความปลอดภัยเพิ่มเติม
- ลำดับความสำคัญในการพัฒนา: จัดประเภทเป็นฟีเจอร์ที่มีความเร่งด่วนระดับกลาง แต่มีความเสี่ยงสูง
ความกังวลเรื่องความพร้อมสำหรับการผลิต
การหารือเหล่านี้เน้นย้ำช่องว่างระหว่างความสามารถปัจจุบันของ Fil-C และข้อกำหนดการผลิต ในขณะที่ภาษานี้แสดงให้เห็นแนวโน้มที่ดีสำหรับการเขียนโปรแกรมระบบที่ปลอดภัยต่อหน่วยความจำ การขาดฟีเจอร์เหล่านี้จำกัดการใช้งานในสภาพแวดล้อมที่มีความสำคัญด้านความปลอดภัยซึ่งทั้งประสิทธิภาพและการเข้ารหัสแบบเวลาคงที่เป็นสิ่งจำเป็น
ทีมพัฒนายอมรับข้อจำกัดเหล่านี้แต่จัดลำดับความสำคัญให้เป็นรายการที่มีความเร่งด่วนปานกลางเมื่อเปรียบเทียบกับฟีเจอร์หลักอื่นๆ ของภาษา ความซับซ้อนของการพัฒนาฟีเจอร์เหล่านี้อย่างปลอดภัยหมายความว่าพวกมันอาจไม่มาถึงในระยะใกล้ ซึ่งอาจทำให้การนำไปใช้ในองค์กรของทางเลือก C ที่ปลอดภัยต่อหน่วยความจำที่นวัตกรรมนี้ช้าลง
หมายเหตุ: การเข้ารหัสแบบเวลาคงที่หมายถึงการพัฒนาที่ใช้เวลาเท่ากันโดยไม่คำนึงถึงค่าอินพุต เพื่อป้องกันการโจมตีที่อิงเวลา
อ้างอิง: Safepoints and Fil-C