اجبار Rust در Ladybird: بلوغ صنعتی به سمت ایمنی حافظه

در دنیایی که مرورگرهای وب پایه‌ای‌ترین نرم‌افزار روی هر دستگاه متصل به اینترنت هستند، سابقه امنیتی Chrome و Firefox یک واقعیت تلخ را نشان می‌دهد: بیش از ۷۰ درصد آسیب‌پذیری‌های بحرانی آن‌ها ناشی از مشکلات ایمنی حافظه است. پروژه Ladybird با یک تصمیم جسورانه — اجباری‌کردن Rust برای تمام کدهای جدید موتور مرورگر — می‌خواهد این معادله را تغییر دهد.

۱. Ladybird چیست و چرا اهمیت دارد

Ladybird یک پروژه مرورگر وب کاملاً مستقل است که در ۲۰۲۲ توسط Andreas Kling آغاز شد. Kling پیش از این معمار اصلی سیستم‌عامل SerenityOS بود — پروژه‌ای که هدفش ساختن یک سیستم‌عامل یکپارچه با رابط کاربری زیبا از پایه بود. Ladybird در ابتدا مرورگر داخلی SerenityOS بود، اما با گذشت زمان به یک پروژه مستقل تبدیل شد با هدف بلندپروازانه: یک موتور مرورگر کاملاً جدید، مستقل از Chromium/Blink/WebKit/Gecko.

اهمیت این پروژه در وضعیت فعلی اکوسیستم مرورگر نهفته است. امروز تقریباً تمام مرورگرهای مهم از Blink (Chrome، Edge، Brave، Opera) یا WebKit (Safari) استفاده می‌کنند. Firefox با موتور Gecko تنها اپوزیسیون جدی است، اما سهم بازار آن به زیر ۴ درصد رسیده. این یعنی تنوع واقعی در موتورهای مرورگر از بین رفته است.

Ladybird با تامین مالی جمعی بیش از ۱۰ میلیون دلار (از جمله کمک‌های بزرگ از افرادی مانند Chris Wanstrath، هم‌بنیان‌گذار GitHub)، از یک پروژه تفریحی به یک تلاش جدی تبدیل شده. تیم هسته‌ای آن اکنون شامل ۲۰+ مهندس تمام‌وقت است.

«هدف ما ساختن یک مرورگر نیست که فقط کار کند. هدف ما ساختن مرورگری است که از پایه ایمن باشد.» — Andreas Kling، بنیان‌گذار Ladybird

۲. اجبار Rust: مشخصات سیاست جدید

در اوایل ۲۰۲۵، تیم Ladybird تصمیم تاریخی خود را اعلام کرد: تمام کدهای جدید موتور مرورگر باید به Rust نوشته شوند. این تصمیم دارای سه جنبه مهم است:

• کدهای جدید: هر component جدید، هر ماژول جدید، هر feature جدید — فقط Rust. بدون استثنا.
• کدهای موجود C++: در جای خود باقی می‌مانند اما مهاجرت تدریجی به Rust برنامه‌ریزی شده. اولویت با بخش‌هایی است که سابقه CVE دارند.
• مرز تعامل: FFI (Foreign Function Interface) بین Rust و C++ با قراردادهای مشخص تعریف می‌شود تا سطح تماس کاهش یابد.

این سیاست از نظر اجرایی با چالش‌هایی همراه است. تعداد مهندسانی که هم systems programming را در سطح موتور مرورگر بلدند و هم Rust می‌دانند، محدود است. اما Kling در مصاحبه‌ها گفته که این چالش را می‌شناسد و ترجیح می‌دهد کندتر پیش برود اما با معماری درستی.

۳. آمار CVE: چرا ایمنی حافظه اینقدر مهم است

اعداد صحبت می‌کنند. تیم امنیتی Google Chrome در گزارش ۲۰۲۳ خود اعلام کرد که ۷۰ درصد تمام باگ‌های High Severity در Chrome ناشی از مشکلات ایمنی حافظه هستند. Mozilla در تحلیل مشابهی برای Firefox به نتیجه مشابهی رسید: ۷۲ درصد CVE‌های critical، memory safety bugs هستند.

این مشکلات معمولاً در چند دسته جای می‌گیرند:

• Use-after-free: استفاده از اشاره‌گری که به حافظه آزادشده اشاره می‌کند. رایج‌ترین نوع CVE در مرورگرها.
• Buffer overflow: نوشتن فراتر از مرز آرایه یا بافر. در parser‌های HTML، CSS، و JavaScript بسیار شایع است.
• Double-free: آزادکردن دوباره حافظه‌ای که قبلاً آزاد شده — معمولاً منجر به heap corruption می‌شود.
• Null pointer dereference: استفاده از اشاره‌گر null که در C++ رفتار تعریف‌نشده ایجاد می‌کند.

نکته تلخ اینجاست: این باگ‌ها در C++ اغلب در code review هم دیده نمی‌شوند. کامپایلر C++ هیچ تضمینی در مورد صحت استفاده از حافظه نمی‌دهد — این مسئولیت کاملاً بر عهده برنامه‌نویس است. در یک پروژه با میلیون‌ها خط کد و صدها contributor، حفظ این مسئولیت‌پذیری عملاً غیرممکن است.

۴. مدل مالکیت Rust: چطور این مشکل را حل می‌کند

Rust با یک رویکرد اساساً متفاوت طراحی شده. سیستم مالکیت (Ownership System) Rust قوانینی را اعمال می‌کند که کامپایلر در زمان کامپایل بررسی می‌کند، نه در زمان اجرا:

• قانون مالکیت: هر مقدار یک مالک دارد. وقتی مالک از scope خارج می‌شود، حافظه آزاد می‌شود — خودکار و قطعی.
• Borrow Checker: در هر لحظه می‌توانید یا یک mutable reference داشته باشید یا چند immutable reference — هر دو به‌طور همزمان ممکن نیست. این به‌طور خودکار data race در concurrent code را حذف می‌کند.
• Lifetime‌ها: کامپایلر Rust اطمینان می‌دهد که reference‌ها هرگز از داده‌ای که به آن اشاره می‌کنند عمر بیشتری ندارند. Use-after-free در زمان کامپایل تشخیص داده می‌شود.

نتیجه عملی این است که اگر کد Rust کامپایل شود (خارج از بلوک‌های unsafe)، کلاس‌های کاملی از آسیب‌پذیری‌های حافظه به‌صورت ریاضی ممکن نیستند. این یک تضمین قوی‌تر از هر fuzzer یا code review است.

«اگر کد Rust کامپایل می‌شود، ۷۰٪ از CVE‌هایی که ما در Chrome می‌بینیم به‌صورت ذاتی ممکن نخواهند بود.» — Alex Gaynor، مهندس امنیت سابق Firefox و Python

۵. روند صنعتی: گوگل، اپل، و سیاست‌های ایمنی حافظه

Ladybird تنها بازیگر این میدان نیست. در واقع، تصمیم Ladybird بخشی از یک روند صنعتی گسترده‌تر است:

• Android و پروژه Carat: گوگل از ۲۰۲۱ به توسعه‌دهندگان Android توصیه کرده که کدهای native جدید را در Rust بنویسند. در ۲۰۲۴، بیش از ۲۱٪ از کدهای جدید kernel Android به Rust نوشته شده. نتیجه: CVE‌های memory-safety در Android در دو سال اخیر ۵۲٪ کاهش یافته.
• Chromium و sandbox code: گوگل اجازه داد Rust در بخش‌های خاصی از Chromium (به‌خصوص sandbox) استفاده شود. این یک قدم محتاطانه است، اما مسیر را برای مهاجرت گسترده‌تر باز کرده.
• Microsoft و Windows: Microsoft به توسعه‌دهندگان Windows Core اعلام کرد که باید از Rust یا «دیگر زبان‌های memory-safe» برای کدهای جدید استفاده کنند. Windows Kernel در آینده نزدیک بخش‌هایی به Rust خواهد داشت.
• Apple و Swift: اپل رویکرد متفاوتی دارد — Swift و ویژگی‌های جدید C++23 برای ایمنی حافظه. اما در حوزه WebKit، مهاجرت به Swift برای بخش‌های حساس در جریان است.
• دولت آمریکا: در ۲۰۲۴، CISA (آژانس امنیت سایبری) رسماً از صنعت خواست که به زبان‌های memory-safe مهاجرت کنند و C/C++ را در کدهای جدید کنار بگذارند.

۶. بازار کار و آینده مهندسان Systems

تصمیم Ladybird و روند صنعتی گسترده‌تر تاثیر مستقیمی بر بازار کار مهندسان systems programming دارد. در ۲۰۲۵، Rust در جایگاه هفتم زبان‌های پرتقاضا در Stack Overflow Developer Survey قرار گرفت — اما مهم‌تر از این، برای هشتمین سال پیاپی محبوب‌ترین زبان برنامه‌نویسی از نظر توسعه‌دهندگان بود.

تقاضا برای مهندسانی که هم Rust بلدند و هم سابقه systems programming در حوزه‌هایی مانند مرورگر، OS، یا embedded دارند، به‌شدت از عرضه پیشی گرفته. شرکت‌هایی مانند Amazon (Firecracker VMM)، Cloudflare (Pingora reverse proxy)، Discord، و حالا Ladybird تیم‌های بزرگی از مهندسان Rust دارند.

برای توسعه‌دهندگان جوانی که می‌خواهند در حوزه systems programming کار کنند، یادگیری Rust دیگر یک مزیت رقابتی نیست — به یک پیش‌نیاز تبدیل می‌شود. نظام تدریس دانشگاه‌ها هم در حال تغییر است: MIT و Stanford دوره‌های جدیدی با تمرکز بر Rust اضافه کرده‌اند.

جالب است که این تحول بازار یک چرخه خودتقویت‌کننده ایجاد می‌کند: مهندسان بیشتری Rust یاد می‌گیرند چون تقاضا هست، پروژه‌های بیشتری به Rust مهاجرت می‌کنند چون مهندس Rust پیدا می‌شود، و اکوسیستم (crates، ابزارها، آموزش) رشد می‌کند.

۷. مقایسه رویکردهای صنعت در برابر خطاهای ایمنی حافظه

تصمیم Ladybird برای اجبار Rust در کدهای جدید، وقتی در کنار سیاست‌های مشابه در گوگل، مایکروسافت و اپل قرار می‌گیرد، تفاوت‌های مهمی را آشکار می‌کند. برخی پروژه‌ها مانند Ladybird مسیر رادیکال را انتخاب کرده‌اند: قطع کامل مسیر ورود کد ناایمن از روز اول. برخی دیگر مانند Chromium محتاطانه‌تر عمل کرده‌اند و Rust را فقط در بخش‌های محدودی مانند sandbox پذیرفته‌اند، در حالی که پیکره اصلی موتور همچنان C++ باقی مانده. این تفاوت در سرعت و شدت مهاجرت، عمدتاً به اندازه codebase، ریسک‌پذیری تیم مهندسی، و میزان وابستگی به ecosystem موجود بستگی دارد.

بُعد دیگری که این مقایسه را کامل می‌کند، فشار سیاست‌گذاری است. آژانس CISA در آمریکا از تولیدکنندگان نرم‌افزارهای زیرساختی خواسته نقشه‌راه مهاجرت به زبان‌های memory-safe را منتشر کنند، بدون آنکه ابزار قانونی الزام‌آوری داشته باشد. این یعنی تصمیم نهایی همچنان در دست تیم‌های مهندسی هر پروژه است، اما هزینه سیاسی و اعتباری نادیده‌گرفتن این توصیه روزبه‌روز بالاتر می‌رود — دقیقاً همان فضایی که Ladybird در آن تصمیم گرفت جلوتر از الزام برود.

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

برای خواننده‌ای که می‌خواهد این تصمیم‌ها را در عمل ارزیابی کند، معیار ساده این است: هرچه دامنه اجبار Rust محدودتر و کد قدیمی حجیم‌تر باشد، سرعت واقعی کاهش CVE‌های ناشی از حافظه کندتر خواهد بود. Ladybird با نداشتن این بار تاریخی، در موقعیتی است که می‌تواند این معیار را در کوتاه‌ترین زمان ممکن به رخ بکشد و به الگویی عملی برای پروژه‌های تازه‌تاسیس تبدیل شود.

نتیجه‌گیری: بلوغ صنعتی یا انقلاب معماری؟

تصمیم Ladybird برای اجبار Rust را می‌توان از دو زاویه دید. اول، یک نشانه بلوغ صنعتی است: اکوسیستم Rust به نقطه‌ای رسیده که یک پروژه جاه‌طلبانه مانند موتور مرورگر می‌تواند روی آن بسازد. ابزارها، کتابخانه‌ها، و جامعه به اندازه کافی بزرگ شده‌اند.

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

Ladybird شاید هنوز سال‌ها از قابلیت استفاده عمومی فاصله داشته باشد. اما تاثیر آن بر جامعه مرورگر و systems programming قبلاً شروع شده. وقتی اولین بلاک دیاگرام معماری Ladybird با بخش‌های Rust به جای C++ منتشر شد، یک پیام واضح فرستاده شد: دوران نوشتن موتورهای مرورگر با C++ خالص به پایان نزدیک است.