Rust اکنون در هسته لینوکس رسمی شد؛ ایمنی حافظه به سیاست امنیتی تبدیل می‌شود

شاید مهم‌ترین بهبود امنیتی در تاریخ محاسبات، یک طرح احراز هویت جدید، یک فایروال هوشمندتر یا یک سیستم تشخیص بهتر نباشد. ممکن است تغییر زبان برنامه‌نویسی‌ای باشد که سیستم‌عامل‌ها با آن نوشته می‌شوند.

آسیب‌پذیری‌های ایمنی حافظه — باگ‌های استفاده پس از آزادسازی، سرریز بافر، رفرنس‌دهی پوینتر تهی، سرریز عدد صحیح که به سرریز بافر تبدیل می‌شود — سال‌هاست که حدود ۷۰٪ از CVEهای با شدت بالای مایکروسافت را تشکیل می‌دهند. گوگل نیز ارقام مشابهی برای کروم و اندروید گزارش می‌کند. NSA راهنمایی منتشر کرده که می‌گوید حدود ۷۰٪ از تمام آسیب‌پذیری‌های نرم‌افزاری قابل بهره‌برداری، مسائل ایمنی حافظه هستند. این‌ها موارد حاشیه‌ای نادر نیستند — آنها رایج‌ترین کلاس آسیب‌پذیری قابل بهره‌برداری هستند و چهل سال است که رایج بوده‌اند، زیرا بیشتر کد سیستم‌عامل به زبان‌های C و C++ نوشته می‌شود؛ زبان‌هایی که نوشتن کد ناایمن از نظر حافظه را آسان و تشخیص باگ‌ها را تا زمان کرش در تولید دشوار می‌کنند.

Rust کل این دسته را حذف می‌کند. نه با افزودن یک زباله‌گیر زمان اجرا — Go و Java این رویکرد را دارند و هزینه‌ای به عملکرد تحمیل می‌کنند که سیستم‌عامل‌ها نمی‌توانند بپردازند. در عوض، Rust از یک borrow checker زمان کامپایل استفاده می‌کند که مالکیت و طول عمر هر قطعه حافظه را در زمان ساخت ردیابی می‌کند. اگر کدی بنویسید که می‌تواند یک باگ استفاده پس از آزادسازی ایجاد کند، کامپایلر Rust از کامپایل آن خودداری می‌کند. خطای حافظه در زمان اجرا رخ نمی‌دهد. در زمان ساخت با یک پیام خطا که دقیقاً مشکل را توضیح می‌دهد، شکست می‌خورد. بدون کرش، بدون CVE، بدون چرخه وصله، بدون hotfix اضطراری که ساعت ۳ صبح منتشر شود.

نقطه عطف هسته لینوکس

هسته لینوکس پایه‌ی اندروید، بیشتر زیرساخت‌های ابری و طیف وسیعی از سیستم‌های تعبیه‌شده است. همچنین تقریباً به طور کامل به زبان C نوشته شده است — حدود ۲۷ میلیون خط کد که طی سی سال انباشته شده است. افزودن یک زبان برنامه‌نویسی جدید به چنین پایگاه کد قدیمی و بحرانی، تصمیمی است که قبل از تبدیل شدن به سیاست رسمی، سال‌ها اعتبارسنجی نیاز دارد.

اولین کد Rust با انتشار نسخه ۶٫۸ در دسامبر ۲۰۲۳ در هسته لینوکس ادغام شد. پیاده‌سازی‌های اولیه شامل درایور GPU Asahi (که از مک‌های Apple M1 و M2 تحت لینوکس پشتیبانی می‌کند) و برخی زیرساخت‌های درایور NVMe بود — حوزه‌هایی که توسعه جدید در آنها انجام می‌شد و خطر شکستن عملکرد موجود به حداقل رسیده بود. این یک اثبات مفهوم بود که Rust می‌تواند در محدودیت‌های سختگیرانه هسته کار کند و با پایگاه کد C موجود همزیستی داشته باشد.

در دسامبر ۲۰۲۵، پروژه هسته لینوکس به طور رسمی اعلام کرد که Rust در هسته دیگر آزمایشی نیست. توسعه هسته با Rust اکنون بخش رسمی از فرآیند توسعه هسته است، با همان تضمین‌های پایداری، الزامات آزمایش و استانداردهای بازبینی کد که توسعه C دارد. زیرسیستم‌های جدید هسته را می‌توان با اطمینان به Rust نوشت که Rust برای بلندمدت یک زبان پشتیبانی‌شده در هسته باقی خواهد ماند — تعهدی که قبلاً نمی‌شد داد، زیرا تعیین‌شده به عنوان آزمایشی به این معنی بود که زیرساخت Rust هسته در صورت عدم موفقیت می‌توانست حذف شود.

این موضوع به دلایل متعددی اهمیت عملی دارد. توسعه‌دهندگان درایور می‌توانند درایورهای جدید را در Rust بنویسند بدون اینکه نگران وجود زیرساخت Rust هسته در نسخه بعدی هسته باشند. اجزای حیاتی امنیتی هسته — پشته‌های شبکه، درایورهای سیستم فایل، زیرسیستم‌های رمزنگاری — می‌توانند به تدریج در Rust بازنویسی شوند و سطح حمله کدی را کاهش دهند که در حال حاضر با امتیازات ring-0 اجرا می‌شود و ورودی خارجی غیرقابل اعتماد را پردازش می‌کند. و این به جامعه گسترده‌تر برنامه‌نویسی سیستم سیگنال می‌دهد که Rust یک انتخاب جدی بلندمدت برای کارهای هسته است، که بر تصمیمات استخدام، آموزش و سرمایه‌گذاری ابزاری در سراسر صنعت تأثیر می‌گذارد.

پذیرش Rust در اندروید و نتایج آن

گوگل افزودن Rust به اندروید را در سال ۲۰۲۱ آغاز کرد و در اندازه‌گیری نتایج شفاف‌ترین بوده است. تا سال ۲۰۲۴، گوگل گزارش داد که حدود ۷۷٪ از کدهای جدید اندروید به Rust نوشته می‌شود — رقمی که نشان‌دهنده کد جدید اضافه‌شده به پلتفرم است، نه پایگاه کد C و C++ موجود که عمدتاً به همان صورت باقی مانده و همچنان نگهداری می‌شود.

تأثیر امنیتی قابل اندازه‌گیری قابل توجه است. نرخ آسیب‌پذیری‌های ایمنی حافظه کشف‌شده در اندروید از سال ۲۰۱۹ به بعد سال به سال کاهش یافته است، همان دوره‌ای که پذیرش Rust آغاز شد. گوگل این را مستقیماً به انتخاب زبان نسبت می‌دهد: کد Rust که در اندروید اجرا می‌شود، CVEهای ایمنی حافظه را با همان نرخ کد C تولید نمی‌کند، زیرا کامپایلر از بروز تمام کلاس باگ‌ها قبل از عرضه کد جلوگیری می‌کند.

پشته بلوتوث اندروید، بخش‌هایی از پشته شبکه و اجزای زیرساخت کدک رسانه به Rust بازنویسی شده‌اند. اینها دقیقاً سطوح حمله‌ای هستند که از نظر تاریخی آسیب‌پذیری‌های با شدت بالا تولید کرده‌اند — آنها ورودی خارجی غیرقابل اعتماد (بسته‌های جفت‌سازی بلوتوث، داده‌های شبکه، فایل‌های ویدئویی از منابع غیرقابل اعتماد) را با منطق تجزیه پیچیده پردازش می‌کنند، جایی که یک خطای یک واحد جابجایی می‌تواند به یک آسیب‌پذیری اجرای کد از راه دور تبدیل شود که بدون تعامل کاربر قابل بهره‌برداری است.

رویکرد مایکروسافت

پذیرش زبان‌های ایمن از نظر حافظه توسط مایکروسافت در چندین ابتکار توزیع شده است تا یک دستور متمرکز واحد. تیم هسته ویندوز در حال ارزیابی Rust برای توسعه درایورهای جدید هسته است و مایکروسافت به طور فعال در پروژه Rust for Windows که اتصالات Rust به APIهای ویندوز ارائه می‌دهد، مشارکت می‌کند. زیرساخت Azure نیز Rust را در چندین جزء پذیرفته است. پروژه Hyperlight مایکروسافت — یک ابرمجازی‌ساز سبک وزن برای اجرای توابع بدون سرور در مقیاس — از ابتدا در Rust ساخته شده است.

به طور گسترده‌تر، مایکروسافت متعهد شده است که کدهای جدید حیاتی امنیتی را در زبان‌های ایمن از نظر حافظه (که شامل Rust، Go و C# در کنار زبان‌های قدیمی‌تر ایمن Swift و Java می‌شود) بنویسد و به طور سیستماتیک کدهای C و C++ موجود را در جایگزین‌های ایمن از نظر حافظه بازنویسی کند، جایی که ریسک امنیتی هزینه مهندسی را توجیه می‌کند. این یک دستور "همه چیز را در Rust بازنویسی کنید" نیست — یک رویکرد اولویت‌بندی ریسک است که بازنویسی‌های ایمن از نظر حافظه را بر روی کدی متمرکز می‌کند که ورودی خارجی را پردازش می‌کند و با امتیازات بالا اجرا می‌شود، که دقیقاً جایی است که باگ‌های حافظه به آسیب‌پذیری‌های قابل بهره‌برداری تبدیل می‌شوند.

چالش‌های واقعی

تضمین‌های ایمنی حافظه Rust با مبادلات واقعی همراه است که برای پذیرش در دنیای واقعی مهم هستند:

منحنی یادگیری تند است. borrow checker قوانین مالکیتی را اعمال می‌کند که برای توسعه‌دهندگان تازه‌وارد از C، C++ یا بیشتر زبان‌های دیگر ناآشنا به نظر می‌رسد. "مبارزه با borrow checker" یک ناامیدی رایج برای توسعه‌دهندگان تازه‌وارد Rust است. گوگل تخمین می‌زند که شش ماه تا یک سال طول می‌کشد تا یک توسعه‌دهنده با تجربه C در یک پایگاه کد بزرگ به طور واقعی در Rust مولد شود. در مقیاس، این یک سرمایه‌گذاری آموزشی و استخدامی قابل توجه است.

قابلیت همکاری با C ضروری اما پیچیده است. هر استراتژی مهاجرت واقعی شامل فراخوانی Rust از C و فراخوانی C از Rust است — عبور از مرز FFI بین دو زبان. آن مرز نیاز به بلوک‌های unsafe Rust دارد که می‌توانند همان باگ‌های حافظه‌ای را که Rust از آنها جلوگیری می‌کند، معرفی کنند. درست کردن مرزهای FFI نیاز به مهندسی دقیق دارد و هر بلوک unsafe نیاز به بازبینی دقیق دارد.

زمان کامپایل طولانی‌تر است. تحلیل borrow checker از نظر محاسباتی پرهزینه است. پایگاه‌های کد بزرگ Rust به طور قابل توجهی کندتر از پایگاه‌های کد C معادل کامپایل می‌شوند، که بر سرعت تکرار توسعه‌دهنده و زمان خطوط لوله CI/CD تأثیر می‌گذارد. این یک مشکل شناخته شده است که تیم Rust فعالانه روی آن کار می‌کند، اما همچنان یک هزینه واقعی است.

پایگاه کد موجود به سرعت جایی نمی‌رود. هسته لینوکس ۲۷ میلیون خط C است. انتقال تدریجی این به Rust سال‌ها طول خواهد کشید و کد C موجود در طول این انتقال به تولید آسیب‌پذیری‌های ایمنی حافظه ادامه خواهد داد. تغییر به زبان‌های ایمن از نظر حافظه ساختاری و نسلی است — از آسیب‌پذیری‌های جدید در کد جدید جلوگیری می‌کند، نه باگ‌های موجود در کد موجود.

بعد سیاستی

مهم‌ترین تحول اخیر یک نقطه عطف فنی نیست — بلکه تغییر از توصیه فنی به سیاست امنیتی است. CISA، NSA و همتایان Five Eyes همگی راهنمایی رسمی منتشر کرده‌اند که بیان می‌دارد توسعه‌دهندگان نرم‌افزار مسئولیت استفاده از زبان‌های ایمن از نظر حافظه برای کدهای جدید حیاتی امنیتی را دارند. راهبرد ملی امنیت سایبری کاخ سفید به صراحت به ایمنی حافظه اشاره می‌کند. این چارچوب معادله را برای سازمان‌هایی که نرم‌افزاری می‌نویسند که داده‌های حساس یا زیرساخت حیاتی را پردازش می‌کند، تغییر می‌دهد.

این دیگر صرفاً یک تصمیم فنی نیست. این یک سوال است که آیا یک سازمان می‌تواند از انتخاب زبان خود در برابر تنظیم‌کنندگان، حسابرسان و مشتریان دفاع کند. ترکیب بلوغ فنی — ابزارها، اکوسیستم و مستندات Rust از سال ۲۰۲۱ به طور چشمگیری بهبود یافته است — و فشار رسمی سیاستی، پذیرش را فراتر از آنچه صرفاً مورد فنی به تنهایی ایجاد می‌کند، تسریع می‌کند.

ایمنی حافظه در تئوری زبان برنامه‌نویسی یک مسئله حل شده است. تبدیل آن به پیش‌فرض عملی در زیرساخت سیستم‌عامل یک پروژه مهندسی نسلی است. نقطه عطف هسته لینوکس، معیارهای پذیرش اندروید و تغییر سیاست همه نشان می‌دهد که آن پروژه از تمرین آکادمیک به واقعیت مهندسی منتقل شده است — به آرامی، با لبه‌های ناهموار و در مقیاس زمانی اندازه‌گیری‌شده در دهه‌ها به جای چرخه‌های محصول. جهت روشن است و حرکت واقعی است.