- หลังจาก Android เริ่มนำ Rust มาใช้ สัดส่วนช่องโหว่ด้านความปลอดภัยของหน่วยความจำบนแพลตฟอร์มลดลงเหลือต่ำกว่า 20% ของทั้งหมด ช่วยยกระดับทั้งความปลอดภัยและประสิทธิภาพการพัฒนา
- โค้ด Rust มี ความหนาแน่นของช่องโหว่ด้านความปลอดภัยของหน่วยความจำต่ำกว่า C/C++ ถึง 1000 เท่า, อัตราการ rollback ลดลง 4 เท่า, และ เวลาทำ code review สั้นลง 25%
- การขยายการใช้ Rust ครอบคลุมถึง เคอร์เนล, เฟิร์มแวร์, แอป 1st-party และช่วยยกระดับ ระดับความปลอดภัยพื้นฐาน ของทั้งระบบ
- จากกรณี เกือบเกิดช่องโหว่ด้านความปลอดภัยของหน่วยความจำครั้งแรกบน Rust ที่พบใน CrabbyAVIF ยืนยันความสำคัญของตัวจัดสรรหน่วยความจำ Scudo และการอบรมเรื่อง unsafe code อย่างปลอดภัย
- การเปลี่ยนผ่านสู่ Rust ถูกประเมินว่าเป็น กระบวนทัศน์ใหม่ของการพัฒนาซอฟต์แวร์ ที่ทำได้ทั้งเสริมความปลอดภัยและเพิ่มความเร็วในการพัฒนา
ผลของการนำ Rust มาใช้และข้อมูลปี 2025
- ในปี 2025 สัดส่วนช่องโหว่ด้านความปลอดภัยของหน่วยความจำบน Android ลดลงต่ำกว่า 20% พิสูจน์ว่ากลยุทธ์ความปลอดภัยที่ยึด Rust เป็นศูนย์กลางได้ผล
- Rust มี ความหนาแน่นของช่องโหว่ด้านความปลอดภัยของหน่วยความจำลดลง 1000 เท่าเมื่อเทียบกับ C/C++, อัตรา rollback ต่ำกว่า 4 เท่า, และ เวลาทำ code review สั้นลง 25%
- การนำ Rust มาใช้ไม่ได้เป็นเพียงการปรับปรุงด้านความปลอดภัย แต่ยังนำไปสู่ การส่งมอบซอฟต์แวร์ได้เร็วขึ้น
- ข้อมูลครอบคลุมการเปลี่ยนแปลงโค้ดทั้ง 1st-party และ 3rd-party บนแพลตฟอร์ม Android ในภาษา C, C++, Java, Kotlin, Rust
การเปลี่ยนภาษาระบบและผลิตภาพของการพัฒนา
- Android เลือกใช้ Rust เป็นทางเลือกแทน C/C++ สำหรับภาษาระบบ โดยยังคงให้ระดับการควบคุมที่ใกล้เคียงกันแต่ลดความเสี่ยงลง
- หากดูเฉพาะโค้ด 1st-party การเติบโตของโค้ด Rust แซง C++ แล้ว ทำให้สามารถเปรียบเทียบตัวชี้วัดการพัฒนาระหว่างสองภาษาได้
- ใช้กรอบ DORA เพื่อวัด Throughput (ความเร็วในการส่งมอบ) และ Stability (ความเสถียร)
- ทำการเปรียบเทียบโดยควบคุมขนาดโค้ด กลุ่มนักพัฒนา และแนวโน้มด้านเวลา ระหว่าง Rust กับ C++
Throughput: เพิ่มประสิทธิภาพของ code review
- โค้ด Rust ต้องการ revision น้อยกว่า C++ 20% และ เวลาทำ code review สั้นลง 25%
- ระหว่างปี 2023~2024 ประสิทธิภาพการรีวิวดีขึ้นอย่างมากจากความเชี่ยวชาญด้าน Rust ที่เพิ่มขึ้น
- การลดจำนวนการรีวิวและงานแก้ซ้ำช่วยเพิ่มผลิตภาพ โดย การปรับปรุงด้านความเสถียร เป็นปัจจัยที่ให้ผลมากที่สุด
Stability: ลดอัตรา rollback และยกระดับคุณภาพ
- ตามเกณฑ์ของ DORA อัตรา rollback ของ Rust ต่ำกว่า C++ ราว 4 เท่า โดยเด่นชัดเป็นพิเศษในงานเปลี่ยนแปลงขนาดกลางถึงใหญ่
- อัตรา rollback ที่ต่ำลงช่วยเพิ่มผลิตภาพโดยตรง และลดต้นทุนแฝง เช่น การ build ใหม่ งาน postmortem และการบล็อกทีม
- แบบสำรวจวิศวกร Google ในปี 2022 ยังประเมินว่า Rust รีวิวได้ง่ายและมีความแม่นยำสูง
- ข้อมูลที่ได้ช่วยยืนยันการรับรู้นี้ในเชิงประจักษ์
ความปลอดภัยและผลิตภาพที่ดีขึ้นพร้อมกัน
- ในอดีต การเพิ่มความปลอดภัยมักทำให้ประสิทธิภาพลดลงหรือการพัฒนาช้าลง แต่ การเปลี่ยนมาใช้ Rust ทำให้ทั้งความปลอดภัยและประสิทธิภาพดีขึ้นพร้อมกัน
- การนำ Rust มาใช้สร้างโครงสร้างที่ช่วยยกระดับทั้ง ความปลอดภัย, ประสิทธิภาพการพัฒนา, และเสถียรภาพของผลิตภัณฑ์
ขอบเขตการขยายตัวของ Rust
- เคอร์เนล: Android 6.12 Linux kernel รองรับ Rust และมีการนำไดรเวอร์ Rust ตัวแรกมาใช้
- กำลังพัฒนา ไดรเวอร์ GPU บน Rust ร่วมกับ Arm และ Collabora
- เฟิร์มแวร์: การใช้ Rust ช่วย เสริมความปลอดภัยในสภาพแวดล้อมที่มีสิทธิ์สูงและข้อจำกัดมาก พร้อมเผยแพร่ บทสอน การอบรม และโค้ดที่เกี่ยวข้อง
- กำลังดำเนินโครงการ Rusted Firmware-A ร่วมกับ Arm
- แอป 1st-party:
- Nearby Presence: โปรโตคอลค้นหาอุปกรณ์ผ่าน Bluetooth ที่พัฒนาด้วย Rust และทำงานใน Google Play Services
- MLS: โปรโตคอลความปลอดภัยสำหรับข้อความ RCS ที่พัฒนาด้วย Rust และมีแผนจะรวมเข้าในแอป Google Messages ในอนาคต
- Chromium: เปลี่ยน parser สำหรับ PNG, JSON และเว็บฟอนต์ไปเป็น Rust ทำให้ปฏิบัติตาม Rule of 2 ได้ง่ายขึ้น
กรณี “เกือบเกิด” ช่องโหว่ด้านความปลอดภัยของหน่วยความจำครั้งแรกบน Rust
- พบ ช่องโหว่ buffer overflow (CVE-2025-48530) ใน CrabbyAVIF ก่อนปล่อยใช้งานจริง และแก้ไขเสร็จก่อนเปิดเผยสู่สาธารณะ
- Scudo hardened allocator ทำให้ช่องโหว่นี้อยู่ในสถานะ ไม่สามารถนำไปใช้โจมตีได้ (non-exploitable) จากการมี guard page
- ปัจจุบัน Scudo ถูกใช้เป็นค่าเริ่มต้นบนอุปกรณ์อย่าง Pixel และกำลัง ผลักดันให้เป็นข้อบังคับกับพาร์ตเนอร์
- การปรับปรุงระบบรายงานแครชช่วยให้ สัญญาณตรวจจับ overflow ชัดเจนขึ้น
การจัดการ unsafe code และการเสริมการอบรม
- ในการพัฒนา OS ยังจำเป็นต้องมี unsafe code (C/C++ หรือ unsafe Rust) อย่างหลีกเลี่ยงไม่ได้
- Google ได้ เพิ่มโมดูลเชิงลึกเรื่อง unsafe code ในหลักสูตร Comprehensive Rust
- ครอบคลุมเรื่อง soundness ของ unsafe code, พฤติกรรมที่ไม่ถูกกำหนดไว้, safety annotation และเทคนิคการสร้าง safe abstraction
- ความเข้าใจใน unsafe Rust ที่ดีขึ้นจะนำไปสู่ การยกระดับคุณภาพโค้ดของ Android และระบบนิเวศโอเพนซอร์สโดยรวม
การเปรียบเทียบความหนาแน่นของช่องโหว่
- จากโค้ด Rust บน Android ราว 5 ล้านบรรทัด พบช่องโหว่ที่อาจเป็นไปได้ 1 รายการ → ความหนาแน่นของช่องโหว่ Rust อยู่ที่ 0.2/MLOC
- ค่าเฉลี่ยในอดีตของ C/C++ คือ 1,000/MLOC หรือกล่าวได้ว่าลดลง มากกว่า 1000 เท่า
- การลดลงของความหนาแน่นช่องโหว่ด้านความปลอดภัยของหน่วยความจำช่วย เสริมประสิทธิผลของสถาปัตยกรรมความปลอดภัยโดยรวม
- แม้โค้ด Rust ราว 4% จะอยู่ในบล็อก
unsafe{} แต่จากข้อมูลพบว่า ยังมีโอกาสเกิดบั๊กต่ำกว่า C/C++
- ปัจจัยที่เป็นไปได้ ได้แก่ การคงการตรวจสอบด้านความปลอดภัย, การห่อหุ้ม, และการทบทวนเพิ่มเติมที่เข้มงวดขึ้น
บทสรุป
- ในอดีต การรักษาความปลอดภัยต้องอาศัยมาตรการต้นทุนสูงอย่าง การวิเคราะห์แบบสถิต, sandboxing, การออกแพตช์
- การเปลี่ยนผ่านสู่ Rust คือ แนวทางใหม่ที่ได้ทั้งความปลอดภัยและประสิทธิภาพในเวลาเดียวกัน
- ตอนนี้ไม่ใช่ยุคของการ “พัฒนาให้เร็ว แล้วค่อยมาแก้ทีหลัง” อีกต่อไป แต่เป็นขั้นของ “พัฒนาให้เร็ว พร้อมแก้ไปด้วยในเวลาเดียวกัน”
- ยิ่งความปลอดภัยแข็งแกร่งขึ้น โอกาสในการฟื้นคืนประสิทธิภาพและผลิตภาพก็ยิ่งสูงขึ้น
ขอบคุณ
- มีการกล่าวถึงผู้มีส่วนร่วมจำนวนมากในด้านการวิเคราะห์ CVE-2025-48530, การปรับปรุง Scudo, การพัฒนาการอบรม unsafe Rust และการให้ข้อมูลเกี่ยวกับการใช้งาน Rust
- แสดงความขอบคุณต่อความพยายามของทีม Android Rust และทั้งองค์กร Android ในการ ยกระดับคุณภาพอย่างต่อเนื่อง
3 ความคิดเห็น
Rust จงเจริญ!
พอลองแตะการพัฒนาเฟิร์มแวร์ด้วย Embassy ดูนิดหน่อย
ความปลอดภัยในระดับภาษาก็ดีอยู่แล้ว.... แต่พอเครื่องมือดีมากขนาดนี้ เมื่อเทียบกับตอนที่ใช้ c/c++ แล้ว ผลิตภาพเหนือกว่าแบบทิ้งห่างเลยครับ
ความคิดเห็นบน Hacker News
พบช่องโหว่ด้านความปลอดภัยของหน่วยความจำเพียงจุดเดียวใน โค้ด Rust 5 ล้านบรรทัด
หรือก็คือ Rust มีอัตราช่องโหว่ 0.2 กรณีต่อหนึ่งล้านบรรทัด
ขณะที่ C/C++ อยู่ที่ระดับ 1,000 กรณีต่อหนึ่งล้านบรรทัด จึงต่างกันแบบทิ้งห่างมาก
แต่เมื่อมี ข้อมูลที่ชัดเจน แบบนี้ ก็ยากจะเข้าใจว่าทำไมยังเมินกันอยู่
ตัวฉันเองยังไม่เคยใช้ Rust แต่คิดว่าสักวันต้องลองเรียนแน่
ความปลอดภัยก็สำคัญ แต่ การ deploy โดยไม่ต้อง rollback นี่แหละคือสิ่งที่นักพัฒนาอยากได้จริงๆ
ถ้าเขียนด้วย Rust ก็จะมีความมั่นใจแบบนั้น
นวัตกรรมระดับนี้ในวิทยาการคอมพิวเตอร์ไม่ได้มีบ่อยจริงๆ
ในปี 2025 เหตุผลที่จะใช้ C++ แทบไม่เหลือ นอกจากดูแล codebase เดิม
ของใหม่ควรไป Rust ทั้งหมด
โครงการใหม่ย่อมเริ่มพร้อมระบบทดสอบสมัยใหม่และเป้าหมายที่ชัดเจนกว่า
ถึงอย่างนั้นก็ปฏิเสธไม่ได้ว่า Rust เป็น ภาษาที่ดีต่อสุขภาพจิตกว่า C++
การเรียน Rust นั้น ทรมานมากจริงๆ ซับซ้อนกว่าภาษาอื่นมาก
แต่พอสู้กับ compiler ไปได้สักพัก ก็จะเริ่มมั่นใจว่าเมื่อโค้ดรันได้แล้ว แทบจะไม่มีปัญหาอะไร
จากที่เคยใช้ Ruby, JS/TS, Python พอมา Rust แล้วจะรู้สึกว่า “ถ้าคอมไพล์ผ่านก็เสร็จไป 80~90% แล้ว”
แถมยังเร็วอีกด้วย
กระบวนการที่เหมือนกำลังสู้กับ compiler จริงๆ แล้วคือการแก้บั๊กที่ซ่อนอยู่ล่วงหน้า
วิธีคิดแบบ Rust จะเริ่มครอบงำอยู่ในหัว
เป็นมุกว่ามันเป็นภาษาที่ลืมง่ายและกลับมาเรียนใหม่ก็ง่ายเหมือนกัน
ถ้าเป็น Ruby, JS, Python ก็เห็นด้วย แต่ TS ผมว่าต่างออกไปนิดหน่อย
Google ยัง ไม่รองรับ Rust อย่างเป็นทางการใน Android userspace
NDK และ Android Studio ก็ยังรองรับแค่ C/C++
ถ้าจะใช้ Rust ชุมชนต้องทำเครื่องมือกันเอง
หากไม่มีโค้ดฝั่ง JVM ก็ทำแอปได้ยาก
ABI ของ Android ไม่ได้ขึ้นกับภาษา ขอแค่ทำตามกติกาให้ถูกต้อง
นี่เหมือนเป็น ระเบิดที่ทำให้ C++ จมได้ เลย
จากนี้ข้อแก้ตัวอย่าง “Rust ก็ unsafe เหมือนกัน” หรือ “C++ ถ้าใช้ดีๆ ก็ปลอดภัย” จะพูดยากขึ้น
การเขียนโค้ดให้ปลอดภัยอาจน่ารำคาญ แต่พอผ่านไปได้แล้วก็จะมั่นใจมากขึ้นแม้ในสภาพแวดล้อมแบบ multithread
อยากทำแอป Android ด้วย Rust เหมือนกัน
แค่ดีใจที่มีตัวเลือกเพิ่มขึ้นสำหรับการทำ เครื่องมือระบบที่ปลอดภัย
มาตรฐานอุตสาหกรรมยังคงมี C/C++ เป็นศูนย์กลาง จึงยากที่ Rust จะมาแทนทั้งหมดได้
การที่อัตรา rollback ต่างกันถึง 4 เท่านี่น่าตกใจมาก
ตัวเลขส่วนใหญ่เป็นสิ่งที่พอคาดได้อยู่แล้ว แต่นี่ถือว่าใหม่
ไม่ใช่ว่า Rust สมบูรณ์แบบเป็นพิเศษ แต่หมายความว่าโค้ดเดิมมีบั๊กเยอะขนาดนั้นต่างหาก
การได้ข้อมูลแบบนี้จาก codebase ขนาดใหญ่ถือว่าน่าประทับใจ
ถ้าสร้าง ระบบ acceptance test ระดับโมดูลตั้งแต่แรก ก็อาจใช้การทดสอบแทนการตรวจสอบที่ Rust ทำให้ได้
ไม่ใช่แค่ memory leak แต่ยังเฝ้าระวัง performance regression ได้ด้วย
มันก็อาจเป็นแค่ความต่างของ ความเสี่ยงในโค้ดเก่า ก็ได้
เพื่อนคนหนึ่งได้โปรเจกต์ rewrite เป็น Rust
แล้วก็พูดติดตลกว่า “งานนี้เงินเดือนไปได้อีก 3 ปี”
เป็นกลยุทธ์ขำๆ แบบ rewrite → ทำให้ memory-safe → วนลูปเงินเดือนที่มั่นคง
ระหว่างที่ Rust compiler คอมไพล์ช้าๆ ก็สามารถนั่งอ่านโค้ดเก่าไปสบายๆ ได้
ข้อมูลชุดนี้ ไม่ได้ควบคุมตัวแปรกวน
ปกติแล้วสิ่งที่ถูกเลือกมา rewrite มักเป็นโค้ดที่เข้าใจดีอยู่แล้ว จึง review เร็วและ rollback น้อย
ตรงข้ามกับโค้ด legacy ที่ซับซ้อนซึ่งมัก review นานและ rollback บ่อย
ถ้า rewrite เฉพาะโค้ดที่ง่ายจริง อัตรา ช่องโหว่ด้าน memory safety ก็น่าจะออกมาอีกแบบ
ในความเป็นจริงกลับมีแนวโน้มว่าโค้ดที่มีปัญหาเยอะจะถูกเขียนใหม่ด้วย Rust มากกว่า
มันไม่ใช่การทดลองที่สมบูรณ์แบบ แต่การมองว่าเป็น ผลลัพธ์จริงที่เกิดขึ้น น่าจะสมเหตุสมผลกว่า
ถ้าวิเคราะห์ขนาดการ rewrite จากจำนวนบรรทัดที่ลบออกก็น่าจะน่าสนใจยิ่งขึ้น
กลับยิ่งเป็น สภาพแวดล้อมที่ rewrite ได้ง่ายกว่า
ฉันเชื่อในข้อดีของ Rust แต่ก็มองว่านี่เป็น หลักฐานเชิงประสบการณ์ที่หนักแน่น มากกว่าจะเป็นหลักฐานทางวิทยาศาสตร์
ต่อไปก็น่าสนใจว่า การนำ Rust มาใช้จะส่งผลต่อ บั๊กที่ไม่ใช่ memory safety อย่างไรบ้าง
ฉันใช้ Rust กับ การพัฒนาเกม (ไม่ใช่ Bevy)
ด้วยความเสถียรและ throughput ที่ได้ เลยไม่คิดจะกลับไปภาษาอื่นแล้ว
อยากรู้ว่าใช้ ชุด crate และสถาปัตยกรรมแบบไหน
ฉันเองก็ทำเกมเป็นงานอดิเรกและรู้สึกว่า Bevy ค่อนข้างใหญ่เกินไปนิด
ตอนนี้รู้สึกว่า Rust ได้ ปักหลักในโค้ดระบบแกนหลัก มากพอแล้ว
ไม่ใช่การฝ่ากระแสแบบ uphill battle อีกต่อไป
การบอกว่า “rewrite ด้วย Rust” ไม่ได้เป็นแค่มุกมีม แต่เริ่มมีหลักฐานรองรับจริงแล้ว
จะเห็นว่าคอมเมนต์ 80% ยังเป็นพวก เกลียด Rust อยู่เลย
มีแต่ข้ออ้างเดิมๆ อย่าง “C++ ก็ปลอดภัยถ้าใช้ดีๆ”, “Rust ก็มีบั๊กได้”
เป็นคำวิจารณ์ที่เกิดจากความไม่รู้ แต่ตอนนี้ชวนเศร้ามากกว่าขำแล้ว
แต่จะบอกให้ใช้ทุกที่ก็มากเกินไป
ownership model ของ Rust ทำให้ความเร็วในการพัฒนาช้าลง และตัวภาษาก็ยังพัฒนาไม่หยุด
ถ้าเป็นบริการที่มี network latency สูง Python หรือ Node อาจมีประสิทธิภาพกว่าด้วยซ้ำ
สรุปคือ Rust ยอดเยี่ยมมาก แต่ ไม่ใช่คำตอบของทุกปัญหา