رست أصبح رسميًا في نواة لينكس — وسلامة الذاكرة تتحول إلى سياسة أمنية

أهم تحسين أمني في تاريخ الحوسبة قد لا يكون مخططًا جديدًا للمصادقة، أو جدارًا ناريًا أذكى، أو نظام كشف أفضل. قد يكون تغيير لغة البرمجة التي تُكتب بها أنظمة التشغيل.

ثغرات سلامة الذاكرة — أخطاء الاستخدام بعد التحرير، تجاوزات المخزن المؤقت، إلغاء مرجع المؤشر الفارغ، تجاوزات الأعداد الصحيحة التي تتحول إلى تجاوزات المخزن المؤقت — شكلت حوالي 70% من ثغرات CVE عالية الخطورة في مايكروسوفت لسنوات. جوجل تبلغ عن أرقام مماثلة لكروم وأندرويد. نشرت وكالة الأمن القومي إرشادات تفيد بأن حوالي 70% من جميع ثغرات البرمجيات القابلة للاستغلال هي مشاكل سلامة الذاكرة. ليست هذه حالات هامشية غامضة — إنها الفئة الأكثر شيوعًا من الثغرات القابلة للاستغلال، وكانت شائعة لمدة أربعين عامًا لأن معظم كود نظام التشغيل يُكتب بلغتي C وC++، اللتين تجعلان كتابة كود غير آمن للذاكرة سهلاً وصعوبة اكتشاف الأخطاء حتى يحدث تعطل في الإنتاج.

رست تقضي على الفئة بأكملها. ليس بإضافة جامع قمامة وقت التشغيل — لغة Go ولغة Java تتبعان ذلك النهج، وهذا يكلف أداءً لا تستطيع أنظمة التشغيل تحمله. بدلاً من ذلك، تستخدم رست مدقق اقتراض وقت التجميع الذي يتتبع ملكية وأعمار كل جزء من الذاكرة في وقت البناء. إذا كتبت كودًا قد ينتج خطأ استخدام بعد التحرير، يرفض مترجم رست تجميعه. خطأ الذاكرة لا يحدث وقت التشغيل. يفشل في وقت البناء مع رسالة خطأ تخبرك بالضبط ما المشكلة. لا تعطل، لا CVE، لا دورة تصحيح، لا إصلاح عاجل يُصدر في الساعة 3 صباحًا.

علامة فارقة في نواة لينكس

نواة لينكس هي أساس أندرويد، ومعظم البنية التحتية السحابية، ومجموعة واسعة من الأنظمة المضمنة. وهي مكتوبة بالكامل تقريبًا بلغة C — حوالي 27 مليون سطر من الكود تراكمت على مدى ثلاثين عامًا. إضافة لغة برمجة جديدة إلى قاعدة كود بهذا القدم وبهذه الأهمية هو قرار يتطلب سنوات من التحقق قبل أن يصبح سياسة رسمية.

أول كود رست تم دمجه في نواة لينكس مع إصدار 6.8 في ديسمبر 2023. غطت التطبيقات الأولية برنامج تشغيل GPU Asahi (يدعم أجهزة Mac Apple M1 وM2 التي تعمل بلينكس) وبعض البنية التحتية لبرنامج تشغيل NVMe — وهي مجالات كان يجري فيها تطوير جديد وحيث تم تقليل خطر كسر الوظائف الحالية. كان هذا دليلاً على المفهوم أن رست يمكنها العمل ضمن القيود الصارمة للنواة والتعايش مع قاعدة كود C الموجودة.

في ديسمبر 2025، أعلن مشروع نواة لينكس رسميًا أن رست في النواة لم تعد تجريبية. أصبح تطوير النواة بلغة رست الآن جزءًا رسميًا من عملية تطوير النواة، مع نفس ضمانات الاستقرار ومتطلبات الاختبار ومعايير مراجعة الكود مثل تطوير C. يمكن كتابة أنظمة فرعية جديدة للنواة بلغة رست بثقة أن رست ستبقى لغة نواة مدعومة على المدى الطويل — وهو التزام لم يكن ممكنًا في السابق لأن التصنيف التجريبي كان يعني أن البنية التحتية لرست في النواة يمكن إزالتها إذا لم تنجح.

هذا مهم عمليًا لعدة أسباب. يمكن لمطوري برامج التشغيل كتابة برامج تشغيل جديدة بلغة رست دون عدم يقين بشأن وجود البنية التحتية لرست في النواة في إصدار النواة التالي. يمكن إعادة كتابة المكونات الأمنية الحرجة للنواة — أكوام الشبكة، برامج تشغيل نظام الملفات، الأنظمة الفرعية للتشفير — بشكل منهجي بلغة رست بمرور الوقت، مما يقلل سطح الهجوم للكود الذي يعمل حاليًا بامتيازات ring-0 ويعالج المدخلات الخارجية غير الموثوقة. ويشير ذلك لمجتمع برمجة الأنظمة الأوسع أن رست هي خيار جاد طويل الأمد لأعمال النواة، مما يؤثر على قرارات التوظيف والتدريب واستثمار الأدوات عبر الصناعة.

تبني أندرويد لرست والنتائج

بدأت جوجل إضافة رست إلى أندرويد في عام 2021 وكانت الأكثر شفافية في قياس النتائج. بحلول عام 2024، أبلغت جوجل أن حوالي 77% من كود أندرويد الجديد يُكتب بلغة رست — وهو رقم يعكس الكود الجديد المضاف إلى المنصة، وليس قاعدة كود C وC++ الموجودة التي تظل كما هي إلى حد كبير وتستمر في الصيانة.

التأثير الأمني القابل للقياس كبير. انخفض معدل ثغرات سلامة الذاكرة المكتشفة في أندرويد عامًا بعد عام منذ 2019، وهي نفس الفترة التي بدأ فيها تبني رست. تعزو جوجل ذلك مباشرة لاختيار اللغة: كود رست الذي يعمل في أندرويد لا ينتج ثغرات CVE لسلامة الذاكرة بنفس معدل كود C، لأن المترجم يمنع فئة الأخطاء بأكملها قبل شحن الكود.

تمت إعادة كتابة كومة بلوتوث أندرويد، وأجزاء من كومة الشبكة، ومكونات البنية التحتية لترميز الوسائط بلغة رست. هذه هي بالضبط أسطح الهجوم التي أنتجت تاريخيًا ثغرات عالية الخطورة — فهي تعالج مدخلات خارجية غير موثوقة (حزم إقران بلوتوث، بيانات الشبكة، ملفات فيديو من مصادر غير موثوقة) بمنطق تحليل معقد حيث يمكن أن يتحول خطأ واحد خارج عن الحد إلى ثغرة تنفيذ كود عن بعد قابلة للاستغلال دون تفاعل المستخدم.

نهج مايكروسوفت

تبني مايكروسوفت للغات الآمنة للذاكرة موزع عبر عدة مبادرات بدلاً من توجيه مركزي واحد. فريق نواة ويندوز يقوم بتقييم رست لتطوير برامج تشغيل النواة الجديدة، ومايكروسوفت تساهم بنشاط في مشروع Rust for Windows الذي يوفر روابط رست لواجهات برمجة تطبيقات ويندوز. البنية التحتية لـ Azure تبنت رست في عدة مكونات. مشروع Hyperlight من مايكروسوفت — وهو مشرف افتراضي خفيف الوزن مصمم لتشغيل وظائف بدون خادم على نطاق واسع — تم بناؤه من الصفر بلغة رست.

على نطاق أوسع، التزمت مايكروسوفت بكتابة كود جديد حساس أمنيًا بلغات آمنة للذاكرة (والتي تشمل رست، Go، وC# إلى جانب اللغات الآمنة الأقدم Swift وJava) وإعادة كتابة كود C وC++ الحالي بشكل منهجي ببدائل آمنة للذاكرة حيث يبرر الخطر الأمني التكلفة الهندسية. هذا ليس توجيه "أعد كتابة كل شيء بلغة رست" — إنه نهج يتم فيه تحديد أولويات المخاطر يركز إعادة الكتابة الآمنة للذاكرة على الكود الذي يعالج المدخلات الخارجية ويعمل بامتيازات مرتفعة، وهو بالضبط المكان الذي تتحول فيه أخطاء الذاكرة إلى ثغرات قابلة للاستغلال.

التحديات الحقيقية

تأتي ضمانات سلامة الذاكرة في رست مع مقايضات حقيقية تهم التبني في العالم الحقيقي:

منحنى التعلم حاد. يفرض مدقق الاقتراض قواعد ملكية تبدو غير مألوفة للمطورين القادمين من C أو C++ أو معظم اللغات الأخرى. "محاربة مدقق الاقتراض" هو إحباط شائع للمطورين الجدد في رست. تقدر جوجل أن الأمر يستغرق ستة أشهر إلى عام حتى يصبح مطور C ذو خبرة منتجًا حقًا في رست على قاعدة كود كبيرة. على نطاق واسع، هذا استثمار كبير في التدريب والتوظيف.

التشغيل البيني مع C ضروري ولكنه معقد. أي استراتيجية هجرة واقعية تتضمن استدعاء رست من C واستدعاء C من رست — عبور حدود FFI بين اللغتين. تلك الحدود تتطلب كتل unsafe رست، والتي يمكن أن تقدم نفس أخطاء الذاكرة التي تمنعها رست. الحصول على حدود FFI بشكل صحيح يتطلب هندسة دقيقة، وكل كتلة unsafe تحتاج مراجعة دقيقة.

أوقات التجميع أطول. تحليل مدقق الاقتراض مكلف حسابيًا. قواعد كود رست الكبيرة تتجمع بشكل أبطأ بكثير من قواعد كود C المكافئة، مما يؤثر على سرعة تكرار المطور وأوقات خط أنابيب CI/CD. هذه مشكلة معروفة يعمل عليها فريق رست بنشاط، لكنها تظل تكلفة حقيقية.

قاعدة الكود الحالية لن تختفي بسرعة. نواة لينكس تتكون من 27 مليون سطر من C. نقل هذا تدريجيًا إلى رست سيستغرق سنوات عديدة، وسيستمر كود C الحالي في إنتاج ثغرات سلامة الذاكرة طوال هذا الانتقال. التحول إلى اللغات الآمنة للذاكرة هو هيكلي وجيلي — يمنع الثغرات الجديدة في الكود الجديد، وليس الأخطاء الموجودة في الكود الحالي.

البعد السياسي

أهم تطور حديث ليس علامة فارقة تقنية — بل هو التحول من التوصية الفنية إلى السياسة الأمنية. CISA، NSA، ونظائرها في Five Eyes جميعهم نشروا إرشادات رسمية تنص على أن مطوري البرمجيات يتحملون مسؤولية استخدام لغات آمنة للذاكرة للكود الجديد الحساس أمنيًا. استراتيجية الأمن السيبراني الوطنية للبيت الأبيض تشير إلى سلامة الذاكرة صراحة. هذا الإطار يغير المعادلة للمؤسسات التي تكتب برمجيات تعالج بيانات حساسة أو بنية تحتية حرجة.

لم يعد الأمر مجرد قرار تقني. إنه سؤال ما إذا كانت المؤسسة تستطيع الدفاع عن خياراتها اللغوية أمام المنظمين والمدققين والعملاء. مزيج النضج التقني — أدوات رست، والنظام البيئي، والوثائق تحسنت بشكل كبير منذ 2021 — والضغط السياسي الرسمي يسرع التبني بما يتجاوز ما يمكن أن تدفعه الحالة التقنية وحدها.

سلامة الذاكرة هي مشكلة محلولة في نظرية لغة البرمجة. جعلها الافتراضي العملي في البنية التحتية لنظام التشغيل هو مشروع هندسي جيلي. علامة فارقة نواة لينكس، ومقاييس تبني أندرويد، والتحول السياسي كلها تشير إلى أن ذلك المشروع انتقل من تمرين أكاديمي إلى واقع هندسي — ببطء، مع حواف خشنة، وعلى مقياس زمني يقاس بالعقود بدلاً من دورات المنتج. الاتجاه واضح، والزخم حقيقي.