EROS (microkernel)
| توسعه‌دهنده | University of Pennsylvania Johns Hopkins University The EROS Group, LLC |
|---|---|
| نوشته شده به زبان | C |
| خانواده | Capability-based |
| وضعیت توسعه | Discontinued |
| تاریخ اولین انتشار | ۱۹۹۱ |
| آخرین ویرایش پایدار | Final ۲۰۰۵ |
| مخزن |
|
| بازار هدف | Research |
| زبان (های) در دسترس | English |
| روش بروزرسانی | Compile from source code |
| بن‌سازه رایانش | IA-32 |
| نوع هسته | Real-time microkernel |
| پیش فرض واسط کاربر | Command-line interface |
| جلوتر از | KeyKOS |
| ادامه یافته توسط | CapROS, Coyotos |
| وبگاه رسمی |
سیستم عامل بسیار قابل اعتماد ( EROS ) سیستم عاملی است که از سال 1991 توسط دانشگاه های پنسیلوانیا، بعدها توسط دانشگاه جان هاپکینز و گروه EROS، LLC توسعه یافت. ویژگی‌ها عبارتند از داده های خودکار و تداوم فرآیند، برخی پشتیبانی اولیه و امنیت مبتنی بر قابلیت است. EROS صرفاً یک سیستم عامل تحقیقاتی است و هرگز در دنیای واقعی استفاده نشده است.توسعه به نفع دو سیستم جایگزین CapROS و Coyotos تا سال 2005 پایان یافت.
مفاهیم کلیدی[ویرایش]
هدف اصلی سیستم EROS (و بستگان آن) ارائه پشتیبانی قوی در سطح سیستم عامل برای بازسازی کارآمد برنامه های کاربردی حیاتی به اجزای کوچک ارتباطی است. هر جزء فقط از طریق رابط های محافظت شده می تواند با سایرین ارتباط برقرار کند و از بقیه سیستم جدا شده است. یک رابط محافظت شده ، در این زمینه، رابطی است که توسط پایین ترین سطح سیستم عامل، هسته اعمال می شود . این تنها بخشی از سیستم است که می تواند اطلاعات را از یک فرآیند به فرآیند دیگر منتقل کند. همچنین کنترل کامل دستگاه را دارد و (در صورت ساخت صحیح) نمی توان آن را دور زد. در EROS، مکانیسم ارائه شده توسط هسته که توسط آن یک جزء خدمات دیگری را نامگذاری و فراخوانی می کند، یک قابلیت است که با استفاده از ارتباطات بین فرآیندی (IPC) انجام می شود. با اعمال رابط های محافظت شده با قابلیت، هسته تضمین می کند که تمام ارتباطات به یک فرآیند از طریق یک رابط صادراتی عمدی وارد می شود. همچنین تضمین می کند که هیچ فراخوانی امکان پذیر نیست مگر اینکه جزء فراخوانی قابلیت معتبری برای فراخوان داشته باشد. حفاظت در سیستم‌های قابلیت با محدود کردن انتشار قابلیت‌ها از یک مؤلفه به مؤلفه دیگر، اغلب از طریق یک خط‌مشی امنیتی به نام محصور کردن به دست می‌آید .
سیستم های قابلیت به طور طبیعی ساختار نرم افزار مبتنی بر مولفه را ارتقا می دهند. این رویکرد سازمانی مشابه مفهوم زبان برنامه نویسی برنامه نویسی شی گرا است ، اما در دانه بندی بزرگتر رخ می دهد و مفهوم وراثت را شامل نمی شود. هنگامی که نرم افزار به این روش بازسازی می شود، چندین مزیت ظاهر می شود.
اجزای منفرد به طور طبیعی به عنوان حلقه های رویداد ساختار یافته اند. نمونه‌هایی از سیستم‌هایی که به طور معمول به این شکل ساخته می‌شوند شامل سیستم‌های کنترل پرواز هواپیما (به ملاحظات نرم‌افزاری DO-178B در سیستم‌های هوابرد و گواهی‌نامه تجهیزات نگاه کنید ) و سیستم‌های سوئیچینگ تلفن (به سوئیچ 5ESS نگاه کنید ) می‌شوند. برنامه‌نویسی رویداد محور برای این سیستم‌ها عمدتاً به دلیل سادگی و استحکام، که ویژگی‌های ضروری در سیستم‌های ماموریت-حیاتی و زندگی-حیاتی هستند، انتخاب شده‌اند
اجزا کوچکتر می شوند و به صورت جداگانه قابل آزمایش هستند، که به جداسازی و شناسایی آسان تر نقص ها و اشکالات کمک می کند.
جداسازی هر مؤلفه از سایر مؤلفه‌ها دامنه آسیب‌هایی را که ممکن است در صورت بروز مشکل یا عملکرد نادرست نرم‌افزار رخ دهد، محدود می‌کند.
در مجموع این مزایا منجر به سیستم های قابل اندازه گیری قوی تر و امن تر می شود. پلسی سیستم 250،سیستمی بود که در اصل برای استفاده در کلید های تلفن طراحی شده بود، به طوری که طراحی مبتنی بر قابلیت به طور خاص به دلایل نیرومندی انتخاب شد
در مجموع این مزایا منجر به سیستم های قابل اندازه گیری قوی تر و امن تر می شود. این پلسی سیستم 250 بود یک سیستم در اصل برای استفاده در کلید های تلفن طراحی شده, که طراحی مبتنی بر قابلیت به طور خاص به دلایل نیرومندی انتخاب شد.
برخلاف بسیاری از سیستم‌های قبلی، قابلیت‌ها تنها مکانیزم برای نامگذاری و استفاده از منابع در EROS هستند که گاهی اوقات از آن به عنوان یک سیستم قابلیت خالص یاد می‌شود. در مقابل، IBM i نمونه ای از یک سیستم توانایی تجاری موفق است، اما یک سیستم قابلیت خالص نیست.
معماری‌های قابلیت خالص توسط مدل‌های امنیتی ریاضی کاملاً آزمایش‌شده و بالغ پشتیبانی می‌شوند. اینها برای نشان دادن رسمی اینکه سیستم های مبتنی بر قابلیت در صورت پیاده سازی صحیح می توانند ایمن شوند استفاده شده است. نشان داده شده است که به اصطلاح "ویژگی ایمنی" برای سیستم های قابلیت خالص قابل تصمیم گیری است ( لیپتون را ببینید). محصور کردن، که بلوک اصلی جداسازی است، به طور رسمی تأیید شده است که توسط سیستم‌های قابلیت خالص قابل اجرا است، و توسط سازنده EROS و کارخانه KeyKOS به اجرای عملی کاهش می‌یابد. هیچ تایید قابل مقایسه ای برای هیچ مکانیزم حفاظت اولیه دیگری وجود ندارد. یک نتیجه اساسی در ادبیات وجود دارد که نشان می دهد ایمنی از نظر ریاضی در حالت کلی غیرقابل تصمیم گیری است (به HRU مراجعه کنید، اما توجه داشته باشید که البته برای مجموعه نامحدودی از موارد محدود قابل اثبات است [۱] ). از اهمیت عملی بیشتر، ایمنی نشان داده شده است به غلط برای همه از مکانیسم های محافظت بدوی حمل و نقل در سیستم عامل های کالا در حال حاضر. ایمنی پیش شرط لازم برای اجرای موفقیت آمیز هر سیاست امنیتی است. از نظر عملی، این نتیجه به این معنی است که اصولاً ایمن سازی سیستم های کالای فعلی امکان پذیر نیست، اما به طور بالقوه ایمن سازی سیستم های مبتنی بر قابلیت ممکن است به شرطی که با دقت کافی اجرا شوند. نه EROS و نه KeyKOS هرگز با موفقیت نفوذ نکرده اند، و مکانیسم های جداسازی آنها هرگز توسط هیچ مهاجم داخلی با موفقیت شکست نخورده است، اما مشخص نیست که آیا این دو پیاده سازی به اندازه کافی دقت کرده اند یا خیر. یکی از اهداف پروژه Coyotos این است که نشان دهد که جداسازی و امنیت اجزا به طور قطعی با استفاده از تکنیک های تأیید نرم افزار به دست آمده است.
ال 4.سیستم ثانیه, که جانشین به است خانواده میکروکرنل ال 4 یک سیستم مبتنی بر قابلیت است و به طور قابل توجهی تحت تاثیر نتایج پروژه اروس قرار گرفته است. نفوذ متقابل است, از کار اروس در نیایش با عملکرد بالا به شدت توسط انگیزه بود یوخن لیدتکموفقیت با خانواده میکروکرنل ال 4.
تاریخچه[ویرایش]
توسعه دهنده اصلی اروس جاناتان اس شاپیرو بود. او همچنین نیروی محرکه کویوتوس است که "گام تکاملی"است[۲] فراتر از سیستم عامل اروس.
پروژه اروس در سال 1991 به عنوان یک بازسازی اتاق تمیز از یک سیستم عامل قبلی شروع شد, کیکوس. کیکوس توسط منطق کلیدی توسعه داده شد, شرکت. و به طور مستقیم به کار قبلی ادامه داد سیستم عامل جدید در فضا (عرفان) سیستم ایجاد شده توسط تیمشیر, شرکت. شرایط اطراف مرگ منطق کلیدی در سال 1991 ساخته شده صدور مجوز کیکوس غیر عملی است. با توجه به اینکه کیکوس به هیچ وجه بر روی پردازنده های محبوب کالا اجرا نشد تصمیم به بازسازی این پردازنده از طریق اسناد و مدارک در دسترس عموم گرفته شد.
در اواخر سال 1992، مشخص شد که معماری پردازنده از زمان معرفی ایده قابلیت به طور قابل توجهی تغییر کرده است، و دیگر آشکار نبود که سیستم‌های ساختارمند عملی باشند. سیستم‌های مبتنی بر میکروکرنل ، که به‌طور مشابه تعداد زیادی از فرآیندها و IPC را مورد استفاده قرار می‌دهند، با چالش‌های عملکردی شدیدی مواجه بودند و مشخص نبود که آیا می‌توان آنها را با موفقیت حل کرد یا خیر. معماری x86 به وضوح به عنوان معماری غالب در حال ظهور بود، اما تأخیر گران قیمت انتقال کاربر/ناظر در 386 و 486 چالش‌های جدی را برای جداسازی مبتنی بر فرآیند ایجاد کرد. پروژه EROS در حال تبدیل شدن به یک تلاش تحقیقاتی بود و به دانشگاه پنسیلوانیا منتقل شد تا کانون تحقیقات پایان نامه شاپیرو شود. تا سال 1999، یک پیاده سازی با کارایی بالا برای پردازنده Pentium نشان داده شده بود که عملکرد مستقیماً قابل رقابت با خانواده میکروکرنل L4 بود که به دلیل سرعت استثنایی خود در IPC شناخته شده است. مکانیزم محصور کردن EROS به طور رسمی تأیید شده بود، در این فرآیند یک مدل رسمی کلی برای سیستم‌های قابلیت ایمن ایجاد می‌کرد.
که در 2000, شاپیرو دانشکده علوم کامپیوتر در دانشگاه جانز هاپکینز پیوست. در هاپکینز هدف این بود که نشان دهد چگونه استفاده امکانات فراهم شده توسط هسته اروس برای ساخت سرورهای امن و قابل دفاع در سطح برنامه. بودجه توسط دفاعی پروژههای تحقیقاتی پیشرفته و تحقیقات نیروی هوایی, اروس به عنوان پایه ای برای یک سیستم پنجره مورد اعتماد مورد استفاده قرار گرفت,[۳] یک پشته شبکه با کارایی بالا و قابل دفاع,[۴] و شروع یک مرورگر وب امن. همچنین برای بررسی اثربخشی چک کردن استاتیک سبک وزن مورد استفاده قرار گرفت.[۵] در سال 2003 برخی از مشکلات امنیتی بسیار چالش برانگیز کشف شد[۶] که ذاتی هستند هر معماری سیستم بر اساس شکلهای اولیه اولیه همزمان (به ویژه اروس و ال 4). کار بر روی اروس به نفع کویوتوس متوقف شد که این مشکلات را حل می کند.
تا تاریخ ۲۰۰۶[بروزرسانی], EROS and its successors are the only widely available capability systems that run on commodity hardware.
وضعیت[ویرایش]
کار بر روی اروس توسط گروه اصلی متوقف شده است, اما دو سیستم جانشین وجود دارد. این کپروس سیستم در حال ساخت به طور مستقیم از کد پایه اروس, در حالی که سیستم کویوتوس یک سیستم جانشین که به برخی از کمبودهای معماری اروس است, و در حال بررسی امکان یک سیستم عامل به طور کامل تایید. انتظار می رود هر دو کپرو و کویوتوس در استقرار های مختلف تجاری منتشر شوند.
جستارهای وابسته[ویرایش]
منابع[ویرایش]
مقالات[ویرایش]
- Lipton, R. J.; Snyder, L. (July 1977). "A Linear Time Algorithm for Deciding Subject Security". Journal of the ACM. 24 (3): 455–464.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد."الگوریتم زمان خطی برای تصمیم گیری در مورد امنیت موضوعی". فصلنامه انجمن. 24 (3): 455–464.
- Harrison, Michael A.; Ruzzo, W. L.; Ullman, Jeffrey D. (August 1976). "Protection in Operating Systems". Communications of the ACM. 19 (8): 461–471.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد."حفاظت در سیستمعاملها". ارتباطات انجمن. 19 (8): 461–471.
پیوند به بیرون[ویرایش]
- EROS home page توسط Wayback Machine (archived مارس ۴, ۲۰۱۶)
- صفحه اصلی Coyotos در Wayback Machine (بایگانی شده در 2 سپتامبر 2016)
- KeyKOS home page توسط Wayback Machine (archived ژانویه ۴, ۲۰۱۶)
- صفحه اصلی جاناتان شاپیرو
- CapROS
الگو:Real-time operating systemsالگو:Microkernel
This article "EROS (microkernel)" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:EROS (microkernel). Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.
- ↑ Lee, Peter. "Proof-Carrying Code". Archived from the original on September 22, 2006.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Shapiro, Jonathan (April 2, 2006). "Differences Between Coyotos and EROS: A Quick Summary". Archived from the original on 2012-07-31.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Shapiro, Jonathan S.; Vanderburgh, John; Northup, Eric; Chizmadia, David. "Design of the EROS Trusted Window System". Archived from the original on March 3, 2016.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Sinha, Anshumal; Sarat, Sandeep; Shapiro, Jonathan S. "Network Subsystems Reloaded: A High-Performance, Defensible Network Subsystem". Archived from the original on March 3, 2016.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Chen, Hao; Shapiro, Jonathan S. "Using Build-Integrated Static Checking to Preserve Correctness Invariants" (PDF). Archived from the original (PDF) on March 3, 2016.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ Shapiro, Jonathan S. "Vulnerabilities in Synchronous IPC Designs". Archived from the original on March 3, 2016.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
