‏Tinfoil یه میلیون خط فرم‌ور رو با ۳۰۰ خط اسمبلی عوض کرد

تیم Tinfoil تو این مقاله تعریف می‌کنه که چطور فرم‌ور ماشین‌های مجازی‌شون رو از OVMF (فرم‌ور متن‌باز و پراستفاده برای VMها) با بیشتر از یه میلیون خط C، به حدود ۳۰۰ خط اسمبلی بدون وابستگی رسوندن. Tinfoil همه‌ی کارها رو داخل secure enclave اجرا می‌کنه، یعنی VMی که حافظه‌ش با سخت‌افزار Intel و AMD و NVIDIA رمز می‌شه و می‌تونه ثابت کنه دقیقاً چه کدی روش اجرا می‌شه. تو مدل تهدیدشون خود میزبان (یعنی خود Tinfoil) هم غیرقابل‌اعتماده.

حساس‌ترین لحظه بوته، چون همون موقع attestation (گواهی سخت‌افزار از کدی که اجرا شده) ساخته می‌شه. قبلاً سخت‌افزار فقط OVMF رو اندازه می‌گرفت و بعدش OVMF باید kernel و initramfs و command line رو لود و اندازه‌گیری می‌کرد. یعنی اگه فرم‌ور باگ داشت، یه میزبان بدخواه می‌تونست هر نرم‌افزاری رو لود کنه. تازه همین هفته هم یه آسیب‌پذیری RCE تو درایور شبکه‌ی PXE همین کدبیس پیدا شده.

راه‌حلشون اینه که همه‌چیز از اول تو حافظه‌ی اولیه‌ی enclave باشه: فرم‌ور، kernel، initramfs، page tableها، جدول‌های ACPI و command line. این‌ها با فرمت IGVM (فرمت مایکروسافت برای توصیف حافظه‌ی اولیه‌ی VM) تو CI ساخته می‌شن و همه با هم یه هش واحد می‌شن، یعنی MRTD روی TDX یا launch digest روی SEV-SNP. پس فرم‌ور دیگه لازم نیست چیزی رو لود یا اندازه‌گیری کنه و فقط باید لینوکس رو بوت کنه.

فرم‌ور فقط دو چیز رو از میزبان می‌گیره و چک می‌کنه. اول memory map که شکلش باید با الگوی از پیش ساخته‌شده بخونه و فقط اندازه‌ی RAM عوض می‌شه. دوم تعداد CPU که باهاش جدول MADT تو ACPI پچ می‌شه. اگه میزبان دروغ بگه، نهایتش بوت شکست می‌خوره یا CPUهای اضافه پارک می‌مونن و محرمانگی به خطر نمی‌افته. آخرش هم فرم‌ور فقط می‌پره رو لینوکس و دیگه هیچ‌وقت اجرا نمی‌شه:

mov $ZERO_PAGE, %rsi
mov $KERNEL_ENTRY, %eax
jmp *%rax

بقیه‌ی کارهای OVMF یا رفته به زمان build، یا به خود لینوکس سپرده شده (مثل PCI enumeration و بالا آوردن بقیه‌ی CPUها)، یا کلاً حذف شده (مثل Secure Boot و درایورهای دیسک و شبکه). نویسنده‌ها توضیح می‌دن چرا Stage0 گوگل رو انتخاب نکردن: Stage0 هنوز بعد از launch خودش kernel رو اندازه می‌گیره و ورودی میزبان رو از fw_cfg می‌خونه. نکته‌ی اصلی‌شون فرق audit TCB با runtime TCBه: ابزار build باید درست باشه، ولی مهاجم زنده هیچ‌وقت بهش ورودی نمی‌ده. هزینه‌ش اینه که اگه QEMU چیدمان حافظه رو عوض کنه، فرم‌ور تا اضافه شدن الگوی جدید بوت نمی‌کنه.

نویسنده‌ها معتقدن با LLMها پیدا شدن باگ سرعت گرفته و پچ کردن با گله‌ی ایجنت‌ها فقط از پس شرکت‌های بزرگ برمیاد. مثلاً OpenAI نزدیک ۴۰۰ میلیارد توکن برای red-team زیرساختش سوزونده که حدود ۸ تا ۲۰ میلیون دلار می‌شه. به گفته‌ی اون‌ها، جواب منطقی‌تر ساختن نرم‌افزار کوچیک و مخصوص یه کاره که بشه راحت fuzz و حتی به‌صورت formal وریفای‌ش کرد.

نکات کلیدی:

• فرم‌ور جدید Tinfoil حدود ۳۰۰ خط اسمبلی بدون وابستگیه و جای بیشتر از یه میلیون خط C در OVMF رو گرفته.
• با فرمت IGVM، kernel و initramfs و جدول‌ها موقع launch با یه هش واحد (MRTD یا launch digest) اندازه‌گیری می‌شن.
• جاهایی که کد مهمان بایت‌های میزبان رو parse می‌کرد از ۸ مورد به ۲ مورد رسیده: memory map و تعداد CPU.
• Stage0 گوگل رد شد چون بعد از launch خودش kernel رو اندازه می‌گیره و از fw_cfg ورودی می‌خونه.
• محدودیتش اینه که اگه QEMU چیدمان حافظه رو تغییر بده، تا اضافه شدن الگوی جدید بوت نمی‌شه.