نماذج LLM تعجز عن كتابة Rust غير الآمن: ستة أشهر من الاختبار تكشف أخطاء حرجة

كلّف المؤلف نماذج LLM بكتابة شيفرة unsafe Rust في مشاريع فعلية على مدى ستة أشهر، وفحص كل كتلة منها باستخدام Miri وأدوات sanitizer. وجاءت النتيجة مخيّبة للآمال: ترتكب النماذج الأخطاء نفسها بشكل متوقع وثابت.

سبع فئات من أخطاء LLM في unsafe Rust

تقع النماذج باستمرار في الأخطاء ذاتها وفي المواضع ذاتها:

• Aliasing — انتهاك القاعدة التي تمنع تداخل المراجع
• Provenance — محاولة استخدام مؤشرات تم الحصول عليها بطريقة غير صحيحة
• Layout عند alloc/dealloc — عدم تطابق الحجم أو المحاذاة بين التخصيص والتحرير
• ManuallyDrop — نسيان استدعاء drop، أو التعامل مع الكائن بعد drop
• سباقات البيانات في استدعاءات FFI المرتدة — حالات race condition عند استدعاء دوال C من خيوط متعددة
• Send/Sync اليدوية — تطبيق خاطئ للسمات (traits) المسؤولة عن سلامة الخيوط
• الذاكرة غير المهيّأة (Uninit) — التعامل مع بيانات غير مهيّأة كما لو كانت مهيّأة

لماذا كشف Miri هذه المشكلات

Miri هو مفسّر للغة Rust يتتبّع السلوك غير المعرَّف (undefined behavior). عندما تولّد LLM شيفرة تحتوي على انتهاكات لا تظهر للوهلة الأولى، مثل مؤشر مؤقت ذي provenance غير صحيح، يتجاوزها المترجم العادي بينما يلتقطها Miri. أما تحت أدوات sanitizer (AddressSanitizer وThreadSanitizer) فقد ظهرت سباقات البيانات وحالات use-after-free، وهي مشكلات قد لا تظهر في الاختبارات العادية.

«تأتي كل فئة مع مثال أدنى وإصلاح» — يوضح المؤلف بذلك أن هذه ليست مجرد

ملاحظات، بل أنماط أخطاء يمكن إعادة إنتاجها.

ماذا يعني ذلك

نماذج LLM ليست جاهزة بعد لكتابة unsafe Rust دون رقابة بشرية. فهي تولّد البنية النحوية والمنطق العام بكفاءة، لكنها تخطئ بشكل منهجي في العمل مع الذاكرة والبرمجة متعددة الخيوط. وفي الشيفرة الحرجة (البرمجيات الأساسية للأنظمة ومكتباتها) يجب فحص أي unsafe Rust تنتجه النماذج تحت Miri بصورة إلزامية.