«بدون دیمون و سریع»؛ رویکرد Kern برای بهینه‌سازی محیط‌های ایزوله

تصور کنید یک عامل هوش مصنوعی کدی را می‌نویسد و شما باید در کمتر از یک پلک زدن، محیطی کاملاً ایزوله برای اجرای آن بسازید تا سیستم شما به خطر نیفتد. اگر از داکر برای این کار استفاده کنید، تأخیر در راه‌اندازی محیط (Cold Start) باعث می‌شود سرعت پاسخ‌دهی عامل شما به شدت افت کند.

یک فایل باینری کوچک ۱.۵۲ مگابایتی به نام Kern اکنون می‌تواند یک کانتینر کاملاً ایزوله و تحت کنترل هسته لینوکس را در حدود ۳.۵ میلی‌ثانیه اجرا کند. این جهش عملکردی دقیقاً برای رفع خطرات اجرای کدهای تولیدشده توسط هوش مصنوعی زاینده (Generative AI) طراحی شده است؛ جایی که سرعت محیط ایزوله (Sandbox) باید با سرعت خروجی مدل‌های زبانی همخوانی داشته باشد.

سال‌هاست که توسعه‌دهندگان برای ایزوله‌سازی بارهای کاری نامطمئن به موتورهای سنگین کانتینر تکیه کرده‌اند. ابزارهایی مثل داکر امنیت خوبی فراهم می‌کنند، اما اغلب یک دیمون (Daemon) سنگین و تأخیر قابل‌توجهی در شروع به کار به همراه دارند. این موضوع برای سامانه‌های عامل‌محور (Agentic) که نیاز دارند در هر ثانیه صدها محیط موقت را بسازند و تخریب کنند، یک گلوگاه واقعی است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، ایزوله‌سازی در سطح سخت‌افزار یا هسته، تنها راه مقابله با کدهای مخرب است. Kern به عنوان یک محیط اجرای بدون ریشه (Rootless) معرفی شده که به هیچ سوکت یا دیمون پس‌زمینه‌ای نیاز ندارد. این ابزار به‌طور خاص برای «حریم انفجار» (Blast Radius) فراخوانی‌های ابزاری توسط عامل‌ها، کارهای CI و سلول‌های کد تعاملی طراحی شده است. طبق مستندات این پروژه، این ابزار با زبان Rust و تنها با یک وابستگی به libc نوشته شده است. برای کاهش حجم و پیچیدگی، مانیفست‌های JSON و OCI به‌صورت دستی پارس می‌شوند و عملیات دریافت تصاویر (Pull) به جای لینک کردن یک استک TLS، مستقیماً از دستورات curl و tar موجود در سیستم استفاده می‌کند.

عملکرد حداکثری و ردپای ناچیز

معماری فنی Kern بر حذف «مالیات دیمون» تمرکز دارد. چون این ابزار یک باینری استاتیک است، در حالت استراحت صفر مگابایت رم مصرف می‌کند. این موضوع تضاد شدیدی با Docker Desktop دارد که حتی قبل از شروع اولین کانتینر، به یک ماشین مجازی (VM) در پس‌زمینه نیاز دارد. حجم نسخه نهایی (Release build) آن ۱.۵۲ مگابایت است، هرچند نصب ساده از طریق cargo از روی سورس منجر به ایجاد یک باینری ۱.۹۱ مگابایتی می‌شود.

بر اساس بنچمارک‌های انجام شده روی پردازنده Intel i7-14700KF با لینوکس ۷.۰.۰ و با استفاده از باینری نسخه نهایی، شکاف عظیمی در تأخیر راه‌اندازی سرد (Cold Start) — یعنی زمان لازم برای بیدار شدن یک محیط از حالت خاموش — دیده می‌شود. یک محیط خام (Bare box) در Kern در حدود ۲.۳ میلی‌ثانیه اجرا می‌شود، در حالی که داکر و پادمن معمولاً در محدوده ۲۹۰ میلی‌ثانیه هستند. حتی هنگام دریافت تصویر از یک رجیستری OCI، زمان اجرا در Kern حدود ۳.۵ میلی‌ثانیه باقی می‌ماند.

در سناریوهای با تراکم بالا، تفاوت‌ها تکان‌دهنده‌تر است. گزارش‌ها حاکی از آن است که ۲۰۰ محیط ایزوله را می‌توان به صورت موازی در ۰.۱۱ ثانیه اجرا کرد. در مقابل، داکر ۱۶.۲ ثانیه و پادمن ۴۴.۸ ثانیه زمان می‌برند. حتی در مقیاس بزرگ، ۳۰۰۰ محیط در حدود ۲.۲ ثانیه اجرا می‌شوند و هر محیط فعال تنها حدود ۰.۳ مگابایت حافظه اشغال می‌کند.

مکانیزم‌های امنیت و ایزوله‌سازی

باید توجه داشت که Kern یک هایپروایزر نیست. مرز امنیتی آن همان هسته لینوکس است، به این معنی که هر باگی که منجر به افزایش سطح دسترسی در هسته (Kernel privilege-escalation) شود، می‌تواند باعث خروج از محیط ایزوله شود؛ وضعیتی که داکر و پادمن نیز با آن روبروند. به همین دلیل است که جایگزین‌هایی مانند gVisor و Firecracker وجود دارند. برای securing کدهای نامطمئن، این ابزار از استراتژی «رد پیش‌فرض» (Deny-by-default) استفاده می‌کند. فعال کردن پرچم --security-profile untrusted مجموعه‌ای از حفاظ‌های سخت‌گیرانه را فعال می‌کند:

• لیست سفید Seccomp: یک فیلتر سخت‌گیرانه بر اساس پیش‌فرض‌های Moby، اما با حذف ۳۵ فراخوان سیستمی (Syscall) خاص که به طور قطعی مسدود شده‌اند. هر فراخوانی خارج از مجموعه تایید شده، خطای ENOSYS برمی‌گرداند. لیست سیاه گسترده‌تر نیز از طریق KERN_SECCOMP=denylist قابل تغییر است.
• حذف قابلیت‌ها: حذف تمام قابلیت‌های خطرناک سیستم از طریق دستور --cap-drop ALL.
• امنیت سیستم فایل: استفاده از سیستم فایل ریشه فقط-خواندنی (Read-only) و مسدود کردن پیش‌فرض /dev. کاربران در صورت تمایل می‌توانند پرچم --read-only را به صورت دستی برای تعیین دقیق‌تر تنظیمات وارد کنند.
• محدودیت منابع: اعمال سقف حافظه و تعداد پردازش‌ها (PID caps) از طریق Cgroup v2. کاربران می‌توانند پرچم --require-limits را اضافه کنند تا سیستم در صورتی که این محدودیت‌ها اعمال نشده باشند، از اجرا خودداری کند.
• ایزوله‌سازی Namespace: استفاده از فضاهای نام کاربر (User)، پردازش (PID)، مونت (Mount)، شبکه (Network)، UTS و IPC به همراه یک overlay پیوت شده یا ریشه فقط-خواندنی.

ایزوله‌سازی بر پایه User Namespaceهای بدون امتیاز ساخته شده است. توسعه‌دهندگان در فایل SECURITY.md صراحتاً اشاره کرده‌اند که اگرچه این روش اجازه اجرای Rootless را می‌دهد، اما همچنان منبعی برای باگ‌های LPE (افزایش سطح دسترسی محلی) در هسته لینوکس است.

اعتماد و مرزهای دسترسی

باید توجه داشت که Kern دیواری دور هر چیزی که شما به آن متصل (Mount) می‌کنید نمی‌کشد. برای مثال، استفاده از -v $HOME:/host پوشه Home شما را در اختیار محیط ایزوله قرار می‌دهد؛ مونت کردن یک مسیر، یک تصمیم اعتمادی از سوی کاربر است، نه مرزی که محیط اجرا تحمیل کند. به همین ترتیب، پرچم‌های --net host و --privileged خروج‌های صریح از حالت ایزوله‌سازی هستند. تنها مسیری که Kern از اتصال به آن خودداری می‌کند، رجیستری رانتایم خودش است.

برای تایید این مرزها، پروژه چهار مجموعه تست نفوذ (Pentest) در پوشه pentest/ قرار داده است که ایزوله‌سازی را مستقیماً در برابر هسته لینوکس می‌سنجند، به جای اینکه به گزارش‌های خودِ Kern تکیه کنند. این تست‌ها بدون نیاز به حساب رجیستری یا شبکه اجرا می‌شوند. کاربران می‌توانند این تست‌ها را از طریق اسکریپت‌هایی مانند pentest/run-with-local-registry.sh یا pentest/pentest-ports.sh اجرا کنند.

برش منابع و ارکستراسیون

فراتر از یک محیط ایزوله ساده، Kern مانند یک برش‌دهنده منابع (Resource Slicer) عمل می‌کند. کاربران می‌توانند پروفایل‌های منابع را در فایل kern.toml تعریف کنند و آن‌ها را با نام به یک محیط ایزوله یا یک پردازش ساده از طریق kern run متصل کنند.

انواع پروفایل‌ها:

• vcpu: تعریف هسته‌های CPU و سقف حافظه. برای مثال، یک پروفایل به نام "heavy" می‌تواند از بودجه میزبان (مثلاً cpu:0 با ۸ هسته) تراشیده شود تا ۱.۵ هسته و ۵۱۲ مگابایت رم فراهم کند.
• vdisk: ایجاد دیسک‌های موقت (Scratch disks) با حجم محدود. این دیسک‌ها در حالت Rootless از نوع tmpfs (مبتنی بر رم) هستند و در حالت Privileged از تصاویر ext4-on-loop با کوتای واقعی استفاده می‌کنند. Kern در هر پروفایل گزارش می‌دهد که کدام حالت فعال است.
• vgpio: اعطای دسترسی به گره‌های سخت‌افزاری برای کارهای اینترنت اشیا (IoT). این دسترسی در سطح تراشه است؛ نام بردن از یک گره (مانند /dev/i2c-1) دسترسی انحصاری به آن گره را فراهم می‌کند. توجه داشته باشید که تعیین پین‌ها (مثلاً pins = [17]) صرفاً متادیتای همکاری است، زیرا هسته لینوکس فاقد مرزهای مونت در سطح هر خط (per-line) است.

سازگاری با داکر

برای کسانی که از زیرساخت‌های سنتی می‌آیند، Kern زبان Docker Compose را می‌فهمد. این ابزار می‌تواند فایل docker-compose.yml را دقیقاً همان‌طور که نوشته شده بخواند و استک را بدون نیاز به Docker Desktop اجرا کند. همچنین از قابلیت‌های Pull، ساخت از روی Dockerfile، Commit، Push و ذخیره/بارگذاری تصاویر OCI پشتیبانی می‌کند.

در یک مورد تست شامل Postgres و Adminer، کل استک تنها حدود ۶۶ مگابایت رم مصرف کرد و لایه وب در ۰.۳ ثانیه پاسخ داد. اگرچه از فرمت‌های داکر پشتیبانی می‌کند، اما بازسازی موتور داکر نیست؛ بنابراین از API داکر، شبکه‌های overlay، پلاگین‌ها یا Swarm پشتیبانی نمی‌کند. همچنین یک رانتایم کوبرنتیز نیست و فاقد پشتیبانی از CRI است. کاربرانی که به CRI نیاز دارند باید از containerd یا CRI-O استفاده کنند.

ادغام با عامل‌های هوش مصنوعی

برای تسهیل کار توسعه‌دهندگان، kern-sandbox به عنوان یک پوشش (Wrapper) سبک برای پایتون و Node.js ارائه شده است. این ابزار اجازه می‌دهد یک برنامه، کدهای تولیدشده توسط LLM را در یک محیط تازه و ایزوله برای هر فراخوانی اجرا کند، در حالی که شبکه خاموش و خروجی‌ها محدود شده‌اند.

خطاهایی مانند اتمام زمان (Timeout)، کشتن پردازش به دلیل اتمام حافظه (OOM kill) یا مسدود شدن فراخوان‌های سیستمی، به جای ایجاد Exception، به عنوان فیلدهای داده در شیء نتیجه بازگردانده می‌شوند. این امر به یک عامل هوش مصنوعی اجازه می‌دهد به صورت برنامه‌نویسی شده بفهمد چرا یک قطعه کد شکست خورده است، بدون اینکه ارکستراتور متوقف شود.

ویژگی‌های پیشرفته SDK:

• پایداری فضای کاری: کلاس Sandbox فضای کاری را در بین فراخوانی‌های مختلف حفظ می‌کند.
• هسته‌های گرم (Warm Kernels): یک kernel() می‌تواند یک مفسر را فعال نگه دارد تا سلول‌های کد در کمتر از یک میلی‌ثانیه اجرا شوند، هرچند این حالت به انتخاب کاربر، ایزوله‌سازی ضعیف‌تری دارد.
• نتایج غنی: SDK آخرین عبارت (Expression)، فراخوانی‌های display() و اشکال matplotlib را ثبت می‌کند و بدین ترتیب رفتار یک سلول Jupyter notebook را بدون نیاز به هسته واقعی Jupyter شبیه‌سازی می‌کند.

علاوه بر این، kern-mcp یک سرور بر اساس پروتکل زمینهٔ مدل (Model Context Protocol) فراهم می‌کند. این امکان را به کلاینت‌هایی مثل Claude Desktop یا Cursor می‌دهد تا از Kern به عنوان مفسر کد محلی استفاده کنند. این سرور ابزارهایی برای run_code (پشتیبانی از پایتون، بش و نود)، write_file ، read_file و list_files فراهم می‌کند که همگی در محیط‌های تازه و بدون شبکه اجرا می‌شوند و فایل‌ها در یک فضای کاری روی دیسک باقی می‌مانند.

سخت‌افزار و سازگاری

Kern برای تطبیق‌پذیری در محیط‌های مختلف لینوکس طراحی شده است. این ابزار به هسته لینوکسی نیاز دارد که از User Namespaceهای بدون امتیاز و cgroup v2 پشتیبانی کند. روی معماری‌های استاندارد x86_64 و aarch64، از جمله Raspberry Pi 5، Jetson Orin Nano و Arduino UNO Q اجرا می‌شود.

اگرچه نسخه بومی برای ویندوز وجود ندارد، اما یک rootfs پیش‌ساخته برای WSL2 ارائه شده است. نصب آن از طریق یک اسکریپت ساده انجام می‌شود که یک باینری واحد را در مسیر کاربر (معمولاً ~/.local/bin یا /usr/local/bin) قرار می‌دهد. این اسکریپت برای اطمینان از یکپارچگی، چک‌سام SHA256 را قبل از نصب بررسی می‌کند. تایید دستی نیز با استفاده از sha256sum -c روی فایل tarball دانلود شده امکان‌پذیر است.

برای کسانی که ترجیح می‌دهند از سورس بسازند، درخت وابستگی‌های حداقلی اجازه می‌دهد پروژه در حدود ۳۶ ثانیه روی سخت‌افزارهای مدرن (مانند i7-14700KF) کامپایل شود. همچنین دستور kern doctor برای بررسی توانایی میزبان در اجرای محیط‌ها قبل از شروع به کار فراهم شده است.

جزئیات عملیاتی

Kern مجموعه‌ای جامع از ابزارهای CLI برای مدیریت چرخه حیات فراهم کرده است. کاربران می‌توانند از kern ps برای مشاهده محیط‌های در حال اجرا (شامل پورت‌ها و وضعیت سلامت) یا kern top برای نمایش زنده TUI مصرف CPU/RAM و پروفایل‌ها استفاده کنند. برای مدیریت سرویس‌ها، kern box svc امکان انتشار پورت‌ها، ری‌استارت خودکار و بررسی‌های سلامت (مثلاً با استفاده از wget برای تایید پورت محلی) را فراهم می‌کند.

هر دستور خواندن در CLI، مانند kern ps ، kern volume ls یا kern pod ls از پرچم --json پشتیبانی می‌کند. این به توسعه‌دهندگان اجازه می‌دهد خروجی را به ابزارهایی مانند jq بفرستند تا سرویس‌های ناسالم یا پیکربندی‌های خاص را بدون نیاز به پارس کردن جداول متنی فیلتر کنند.

مقایسه نهایی

در مقایسه با موتورهای سنتی، Kern ردپای حافظه در حالت استراحت را حذف می‌کند (۰ مگابایت در مقابل ۱۵۴-۱۶۰ مگابایت برای داکر) و زمان توقف سرویس‌ها را به شدت کاهش می‌دهد (حدود ۱.۹ میلی‌ثانیه در مقابل ۳۱۰-۳۸۰ میلی‌ثانیه). اگرچه شبکه‌سازی پیچیده یک ارکستراتور تولیدی را فراهم نمی‌کند، اما شکاف ایزوله‌سازی محلی، سریع و بدون ریشه را پر می‌کند.

این حرکت به سمت «میکرو-رانتایم‌ها» نشان می‌دهد که کانتینرها دیگر واحدهای سنگین استقرار نیستند، بلکه سلول‌های اجرایی یک‌بارمصرف و سبک‌اند. با کاهش هزینه ایزوله‌سازی به نزدیک صفر، Kern اصلی‌ترین نقطه اصطکاک برای استقرار عامل‌های خودمختاری که با دنیای واقعی تعامل دارند را از بین می‌برد.

توسعه‌دهندگان باید نقشه راه پروژه را برای قابلیت‌های آتی «برش GPU» (GPU slicing) دنبال کنند. در حال حاضر هیچ کدی برای GPU در این نسخه وجود ندارد، به این معنی که هنوز چیزی برای اعتماد یا حمله در این حوزه نیست. پس از پیاده‌سازی، این قابلیت ایزوله‌سازی سریع را به بارهای کاری آموزش و استنتاج ML گسترش خواهد داد.

گام بعدی شما

• اگر از عامل‌های هوش مصنوعی برای اجرای کد استفاده می‌کنید، کتابخانه kern-sandbox را برای کاهش تأخیر و افزایش امنیت جایگزین محیط‌های فعلی کنید.
• برای تست ایزوله‌سازی در سیستم خود، مجموعه تست‌های موجود در پوشه pentest/ را اجرا کنید.
• اگر از Cursor یا Claude Desktop استفاده می‌کنید، سرور kern-mcp را برای داشتن یک مفسر کد محلی و امن راه‌اندازی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.