مروری بر کنفرانس اندرو اس تنن باوم جهت آشنایی با MINIX3

مینیکس (Minix3) پروژه تحقیقاتی/تجاری است که توسط اندرو اس تنن باوم در دانشگاه UV هلند در حال مطالعه است. در این مطلب که چکیده ای از کنفرانس پروفسور تنن باوم در رابطه با این سیستم عامل است، به آشنایی بیشتر با آن می پردازیم.

---

 

تاریخچه Minix3

1975 : انتشار Unix v6 توسط Bell Larbs
1977 : انتشار کتاب تشریح Unix v6 توسط John Lions
1979 : Unix v7 انتشار یافت ولی کسی حق آموزش آن را نداشت چراکه محصول حفاظت شده ای بود وسازندگان آن نمی خواستند راز سیستم عامل جدید خود را افشا کنند.
1984 : Tanenbaum یک Clone از Unix را به نام Minix  نوشت.
1987 : Minix با اهداف آموزشی رها شد.
1997 : Minix2  همراه با کتاب آن منشتر شد.
2004 : تحقیقات بر روی سیستم عامل‌های قابل اعتماد شروع شد.
2006 : نسخه‌ی سوم کتاب Minix منتشر شد.
2008 : Tanenbaum به دلیل فعالیت‌های خود در این زمینه از اتحادیه اروپا جایزه ای معادل 2.5 میلیون یورو دریافت کرد.
 2009 : اتحادیه اروپا بحثی را با موضوع "قوانین مسئولیت" (Liability Lows) برای نرم افزارها مطرح کرد، در واقع نوع خاصی از استاندارد سازی برای نرم افزار ها بود که موفقیت آمیز نبود.

2013: کار روی Minix ادامه دارد و نسخه جدید آن به تازگی منتشر شده است.

نرم افزارهای قابل اعتماد

هکرها علاقه مند هستند که برنامه نویس‌ها اینگونه بیاندیشند :
"اگر خدا می‌خواست که برنامه‌ای قابل اعتماد باشد، دگمه‌ی Reset را خلق نمی‌کرد."
همچنین مادربزرگ‌ها معتقدند :
"چرا کامپیوترها و نرم افزارها نمی تونن شبیه TV باشن. روشنش کن و برای سالها استفاده کن"


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

برای اینکه کامپیوترها مانند TVها شوند، باید ویژگی های زیر را به دست آورند:

• کوچک
• ساده
• امن
• Modular
• قابل اعتماد
• خود ترمیم گر (Self-healing)

طراحی هوشمندانه
میکروکرنل‌ها از حدود 6000 loc تشکیل می‌شوند در حالی که لینوکس بیش از 6 Million loc است. یکی از موارد مهم تعداد Bug در هر 1000 loc است. در نرم افزارهای صنعتی که همواره تحت کنترل هستند این عدد بین 5 تا 10 و در سیستم عامل FreeBSD ، 3 Bug در هر loc است.
Minix3، 18 bugs در هسته خود دارد که این عدد برای لینوکس 18000 است. همچنین درایورهای Linux تعداد bug بیشتری دارند چرا که 70% کدها، کد درایورها تشکیل می دهد.

معماری Minix3

Minix3 از یک microkernel تشکیل شده است که کارهای Basic را در سیستم انجام می‌دهد. Shell، Disk و ... بعنوان برنامه های سطح کاربر عمل می‌کنند.

فراخوانی هسته ای برای سرویس دهنده‌ها و درایورها

این فراخوانی ها با فراخوانی های سیستمی POSIX کاملا فرق دارد و فراخوان های درون هسته ای است. یک پردازش کاربر اگر بخواهد از یک I/O چیزی را بخواهد باید توسط دستور زیر این درخواست را از هسته انجام دهد و اگر هسته دارای مجوزهای لازم باشد، هسته این کار را برای او انجام خواهد داد.

•    SYS_DEVIO: read or write an I/O port

و دیگر مثالهایی از این قبیل :

•    SYS_IRQCTL: set interrupt policy for an IRQ
•    SYS_VIRCOPY: copy data to user address space
و حدودن 34 مثال دیگر از این قبیل.

قوانین کنترل مجوز دسترسی ها
Driverها و سرویس دهنده ها بعنوان پردازش های سطح کاربر اجرا می‌شوند.
حقوق دسترسی هر کسی بصورت دقیق تحت کنترل قرار دارد.

•    هر کسی حق اجرای دستورات خاصی را دارد.

•    تقسیم بندی سازمانی شکل می گیرد تا درایورها و سرویس دهنده ها در حلقه های نامتناهی گیر نیافتند.

درایورهای حالت کاربر

هر درایور بعنوان یک پردازش سطح کاربر جداگانه عمل می‌کند.
امتیازات فراتر از سطح کاربر ندارند.
توسط MMU (Memory Management Unit) حفاظت می شوند.
حق دسترسی به درگاه های I/O را ندارند.
برای کپی کردن فضاهای آدرس به درخواست از هسته نیازمندند.
"در کل قدرت چندانی ندارند"

سرویس دهنده های حالت کاربر

File Server
Process Manger
Virtual Memory Server
Date Store
Information Server
Network Server
Reincarnation Server

File Server

حالت اول : اطلاعات بر روی Cache، FS ذخیره شده اند. برنامه کاربردی از کتابخوانه سیستمی، read را فرامی‌خواند. دستور read پیغامی را به FS میفرستد که میخواهم فلان فایل را بخوانم. اگر خوش شانس باشیم، FS این فایل را بر روی خود دارد و فقط نیاز دارد که با فراخوانی SYS_TASK از هسته، بخواهد که عملیات کپی را انجام دهد. این فعالیت تقریبا 500nSec طول می کشد.

                                                                                                                                                                    
حالت دوم : در این حالت اطلاعات بر روی cache، FS قرار ندارد و باید از روی هارد دیسک خوانده شود. کاربر از طریق دستور read پیغام را به FS ارسال میکند،  FS از دیسک میخواهد که بلوک فایل مورد نظر را پیدا کند. Disk برای یافتن فایل مورد نظر از SYS میخواهد که عملیات I/O مورد نظر را انجام دهد. پس از یافتن، آن را به user تحویل می‌دهد.

Process Manager
شامل منطق لازم برای ایجاد و از بین بردن پردازه ها
مدیریت سیگنال ها

Virtual Memory Manager

به هسته می‌گوید در اینجا Memory Map برای فلان پردازش وجود دارد و هسته بدون قید و شرط آن را قبول می‌کند. در واقع VMM منطق لازم را فراهم می‌کند و مکانیزم بر عهده هسته است.
"در واقع تمامی هوشمندی سیستم و تمامی الگوریتم‌ها در بخش کاربر قرار دارند"

Data Store

یک Name Server کوچک محلی

قابل استفاده برای Recoverable Drivers
برای مثال یک درایور صوتی از کار میافتد، بعد از بازسازی و برگشت به حالت اول می تواند از طریق این Data Store، Volume  خود در حالت قبل از خرابی را مورد استفاده قرار دهد.

Information Server

برای اجرای dumpهای Memory  به کار می رود.

Network Server
پشته‌ی TCP/IP

Reincarnation Server
 والد همه‌ی درایورها و سرویس دهنده‌ها
وقتی یک درایور یا سرور از بین می‌رود، RS آن را جمع آوری می‌کند. سپس برای زنده کردن درایور یا سرور مورد نظر به جدول موجود در خود مراجعه می‌کند. RS همچنین بصورت مداوم درایورها و سرویس دهنده ها را Ping می‌کند تا از زنده بودن آن‌ها آگاه شود.
کاربر از FS  درخواست یک فایل را می‌کند، FS از Disk Drive می‌خواهد که بلوک فایل را به آن برگرداند که Disk Drive با Crash مواجه می‌شود. RS این اتفاق را تشخیص می‌دهد و کد مربوط به آن درایو را که در حافظه ذخیره کرده است، واکشی می‌کند و FS درخواست خود را به درایور جدید ارسال شده می فرستد. این سیستم خود ترمیم‌گر است.


برخی ویژگی‌های minix3

"بازگردانی درایورهای تخریب شده"
Ethernet: از نو اجرا میشود، فقط ممکن است برخی Packetها از دست بروند که معمول است.
Printer: اگر در میان عملیات باشد، راهی بجز پرینت دوباره وجود ندارد.
Audio: قطعه صوتی را از نو پخش میکند.
و ...

"در نظر بگیرید که وقوع این اتفاقها بهتر از تخریب (Crash) کل سیستم عامل است."

"قابلیت اعتماد و امنیت هسته"

• تعداد LOC کمتر به معنی تعداد  bug کمتر است.
• هسته کوچکتر بمعنی TCB(Trusted Computing Base) پایین‌تر است.
• هیچ کد بیرونی (مانند کد درایورها) وارد هسته نمیشود. یکی از عوامل تخریب هسته، کد درایورهایی است که نوشته می‌شود و آن را تخریب می‌کند.
• ساختار static اطلاعات در سیستم، در واقع جداول اندازه مشخص دارند و تعداد پردازش-هایی که میتوانید داشته باشید ثابت است. (256 پردازش( => میزانی RAM بخاطر بزرگ بودن جداول هدر می‌شود.
• انتقال bugها به حالت کاربر، تعداد آن‌ها را کاهش نمی‌دهد بلکه باعث می‌شود که قدرت آنها کاهش پیدا کند.
• "قابلیت اعتماد و امنیت ارتباطات بین پردازه‌ای"
• ارتباطات از این دست با پیغام‌هایی با طول ثابت انجام می‌شوند.
• پیغام‌ها ارسال می‌شوند، در صورتی که تحویل داده نشوند به سیستم میعادگاه (Rendezvous System) تحویل داده می‌شوند که نتیجتا هیچ پیغامی از بین نمی‌رود.
• مثلا در نظر بگیرید که client پیغامی را به server ارسال می‌کند، server تلاش می‌کند که پاسخ دهد ولی client مرده است. Server توانایی ارسال را ندارد و هنگ می‌کند. این سیستم باعث ارسال غیرهمزمان پیغام شده و این مشکل را حل می‌کند.

"قابلیت اعتماد و امنیت درایورها"

• درایورها کدهای غیرقابل اعتماد هستند وشدیدا ایزوله می‌شوند.
• در این حالت bugها و ویروس‌ها نمی‌توانند از ماژولی به ماژول دیگر به سادگی انتقال یابند.
• نمیتوانند به ساختار هسته دست پیدا کنند.
• “Bad Pointer” ها فقط می‌توانند یک درایور را از بین ببرند که توسط RS ترمیم خواهد شد.
• درایورهایی که درگیر حلقه‌های نامحدود شده‌اند، شناسایی شده و از نو راه‌اندازی می‌شوند.
• درایورها در حالت Super user  اجرا نمی‌شوند.

“Memory Grant Table”

فایل سرور یا برخی پردازش‌های دیگر نیاز دارند که از طریق پردازش‎ها به حافظه دست پیدا کنند. وقتی از فایل سرور می‌خواهیم که بلوکی از حافظه را بخواند، باید آن را بر روی فضای آدرس ما بنویسد ولی نمی‌تواند به فضای آدرس ما دسترسی داشته باشد چراکه فقط یک پردازش سطح کاربر دیگر است.
پس چکار باید کرد؟
هر پردازشی که می‌خواهد کس دیگر در فضای آدرس آن چیزی بنویسد، یک Memory Grant Table می‌سازد. یک فراخوانی هسته‌ای می‌سازد و می‌گوید که این Memory Grant Table من است و این مقدار ورودی را در خود جای داده است و آدرس شروع خود را ارائه می‌دهد. در این Memory Grant Table مشخص می‌کند که Disk Driver که شماره پردازش آن برای مثال 9 است، از بایت 1400 تا بایت  1499 قابلیت نوشتن در Entry ایجاد شده را دارد.
زمانی که Disk Driver (یا هر درایور دیگری) می‌خواهد بر روی Memory Grant Table، فایل سرور چیزی بنویسد یک فراخوانی هسته‌ای صادر می‌کند، هسته این جدول را بررسی می‌کند تا ببیند که آیا وجود دارد یا نه و آیا Disk Driver حق نوشتن بر آن قسمت دارد یا نه.


"Fault Injection"

800 000 injection بر روی درایورهای minix3 انجام شده است. در واقع خودمان تلاش می‌کنیم در برنامه bug ایجاد کنیم تا عکس العمل سیستم را نسبت به آن ببینیم. این برنامه‌ها junk تولید نمی‌کنند بلکه سیستم عامل را آنالیز می‌کنند و معماری آن را بدست می‌آورند سپس خطاهایی معنایی در آن ایجاد می‌کند.
بعنوان مثال در داخل حلقه‌ی For، جای ≥  را با < عوض می‌کند و یا i را به j تبدیل می‌کند. هربار 100 injection انجام می‌شد و 1 ثانیه در انتظار پاسخ می‌ماند (یعنی 100 قطعه کد توسط Fault Injection تغییر می‌کند.) تا ببیند Driver از کار افتاده است یا نه که اگر نیافتاده باشد 100 injection دیگر برای آن تولید می‌کند. بعد از این حملات 18038 driver از کار افتادند ولی سیستم عامل به حیات خود ادامه داد.

"نرم‌افزارهای موجود برای minix3"

Screen : x11,Ede
Shells: bash, pdksh, zsh
Languages: C, C++, Python, Perl, PHP
Editor: emacs, vim, vile, nedit & …
Photos: imagemagic, JPEG package, XV
Utilities: GNU, BSD utilities, & …
Web: Apache, Dillo, lym & …
Mail: Pine, Pop Tart, Exim, Sirn
Database: postgres, SQLlit, MySQLclient
Other: Qemu, Mplayer, Netback, subversion
And …


موضع Minix3

• نشان دادن اینکه سیستم‌های Multi Server می‌توانن قابل اعتماد باشند.
• نمایش اینکه درایورها به سطح کاربر تعلق دارند.
• تولید برنامه‌های قابل اعتماد با Fault Tolerant  بالا
• سیستم‌هایی با سخت‌افزار کوچکتر

دلایل انتخاب Raccoon بعنوان لوگو

• کوچک
• بامزه
• باهوش
• چابک
• Bugها را می خورد!

سعید چوبانی 891381210

زهرا عباسی 891381230