اگر برای نوشتن کدهای سطح پایین به هوش مصنوعی اعتماد میکنید، احتمالاً با باگهایی دستوپنجه نرم میکنید که هیچ کامپایلری آنها را گزارش نمیکند. این خطاهای خاموش میتوانند هزینههای عیبیابی را به شدت افزایش دهند و امنیت سیستم را به خطر اندازند.
طبق گزارشی که در ۱۶ اوت ۲۰۲۶ در dev.to منتشر شد، دستیارهای هوش مصنوعی در دستورات سطح پایین بسیار مطمئن به نظر میرسند، اما اغلب با اختراع دستورات ساختگی یا جابهجایی ترتیب عملوندها، خطاهایی ایجاد میکنند که از سد کامپایلرهای استاندارد میگذرند.
برنامهنویسی سطح پایین به دقت مطلق نیاز دارد، اما مدلهای زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — اغلب با اسمبلی مانند یک زبان طبیعی برخورد میکنند و «محتمل بودن» را به «درست بودن» ترجیح میدهند. این رویکرد شکافی خطرناک ایجاد میکند؛ کد بهظاهر درست است و با موفقیت کامپایل میشود، اما کد ماشین نهایی با هدف برنامهنویس همخوانی ندارد.
همانطور که در تحلیلهای پیشین ما دربارهی توهمات مدلهای کدنویس اشاره کردیم، اعتماد به خروجی مدل بدون ابزار تأیید، ریسک بالایی دارد. این چالشها در واقع بخشی از الگوهای تکراری شکست هوش مصنوعی هستند که حتی با دستورات سختگیرانه نیز کاملاً برطرف نمیشوند. برای حل این مشکل، راهنمای مذکور یک «گیت مکانیکی» پیشنهاد میدهد: ابتدا کد را اسمبل کنید، سپس فایل باینری حاصل را دیساسمبل (بازگشایی) کنید و در نهایت خروجی را با سورس اصلی مقایسه کنید.
بر اساس مستندات این گزارش، این فرآیند سه دسته از شکستهای رایج را شکار میکند:
- دستورات ساختگی (Mnemonics): برخی دستورات رد میشوند، اما برخی دیگر کامپایل شده و عملیات ناخواستهای را اجرا میکنند.
- مقادیر ناقص (Truncated Immediates): در یک مورد، دستور
imulبهطور خاموش یک مقدار (۳۸) را حذف کرد؛ باگی که با BBoeOS PR#584 مرتبط است. - جابهجایی گویشها: ترکیب نحو AT&T و Intel میتواند ترتیب عملوندها را بهطور خاموش عوض کرده و معنای دستور را کاملاً تغییر دهد.
به نقل از گزارش dev.to، تطابق دقیق دستورات در دیساسمبلهای مبتنی بر LLM تنها در ۱۴٪ موارد رخ میدهد. حتی نسخههای «اصلاحشده» نیز تنها ۳۷٪ صحت دارند؛ این یعنی عبارت «کد کامپایل شد» معیار کافی برای ایمنی در سطح پایین نیست.
این تغییر رویکرد، بار اثبات را از «اعتماد به مدل» به «زنجیره ابزارهای تأییدپذیر» منتقل میکند. این متدولوژی مشابه رویکرد Trustample در استفاده از محاسبات ساده برای شناسایی توهمات خاموش در تبدیل صوت به متن است که بر تکیه بر منطق بیرونی به جای خروجی مدل تأکید دارد. برای توسعهدهندگان، این بدان معناست که کدهای اسمبلی تولید شده توسط AI تا زمانی که از فیلتر ابزارهایی مثل GCC 16.1 یا objdump رد نشوند، «تأییدنشده» محسوب شوند.
این انضباط فراتر از اسمبلی است. چه در تأیید تعداد رشتهها برای موازیسازی و چه در بررسی وجود واقعی یک API در Cargo، قانون یکسان است: هرگز به حافظه یا ادعاهای AI بیش از یک ابزار زنده اعتماد نکنید.
اکنون توسعهدهندگان میتوانند به فهرستی از ۱۲۴ مهارت سطح پایین تأییدشده و موارد شکست در مخزن TrothByte در گیتهاب دسترسی پیدا کنند. این کتابخانه نمونههای ردیابیشده برای زبانهای C، Rust و Zig ارائه میدهد تا از رسیدن این خطاهای تکراری به محیط عملیاتی جلوگیری شود.
گام بعدی شما
- برای هر قطعه کد اسمبلی تولید شده توسط AI، چرخه «اسمبل $\rightarrow$ دیساسمبل $\rightarrow$ مقایسه» را اجرا کنید.
- ابزار objdump را به گردشکار بررسی کدهای سطح پایین خود اضافه کنید.
- مخزن TrothByte را برای شناسایی الگوهای خطای رایج مدلهای زبانی در زبانهای Rust و Zig بررسی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو