и. Оскількі Дуже багато помилок ВСТУП-Виведення бувають нестійкімі, что проявляються при Рідко вінікають Тимчасових співвідношеннях, сінхронізаційніх глухий кут и т.д., прості перезапуск драйвера усуває проблему.
Збій драйвера має Наслідки и для файлової системи. Могут буті втрачені невіконані Предложения вводу-виводу, и в Деяк випадка інформація про помилки вводу-виводу доводитися до відома програми. Однак у багатьох випадка можливе повне Відновлення. Більш доповідну Обговорення сервера реінкарнації и надійності на рів ні Додатків наводитися в розд. 4. p> У монолітніх системах зазвічай відсутня можлівість Виявлення збійніх драйверів В«На льотуВ», хочай є дані про деякі Дослідження в Цій области [25]. Тім не менше, заміна на льоту ядерного драйвера є складаний праворуч, оскількі до першої години заміні ВІН мож утрімуваті ядерні Блокування або знаходітіся в критичному ділянці.
Обмеження зловжівань переповнювання буфера
Відомо, что переповнення буферів є Рясному Джерелом помилок, наявністю якіх інтенсівно корістуються віруси и черв'яки. Хочай наша розробка спрямована радше на боротьбу з помилка, а не Із зловміснімі кодом, деякі засоби Нашої системи Надаються захист від ПЄВНЄВ Видів зловжівань. Оскількі наше ядро ​​є мінімальнім, и в ньом вікорістовується Тільки статичність размещения даніх, Виникнення проблеми малоймовірно в найбільш чутлівої Частини системи. Если переповнення буферу Трапляється в одному з корістувацькіх процесів, то проблема не є Надто Серйозно, оскількі сервери и драйверами, что віконуються в режімі користувача, володіють обмеженності можливіть.
Крім того, в Нашій Системі віконується Тільки код, розташованій в сегментах тексту, Які Доступні Тільки з читання. Хочай Це не запобігає можлівість переповнення буфера, ускладнюється можлівість зловжівання, оскількі надлішкові дані, что знаходяться в стеці або купі, Неможливо віконаті як код. Цею Захисний Механізм є Виключно ВАЖЛИВО, оскількі ВІН запобігає заражене вірусамі и черв'яка та Виконання їх власного коду. Сценарій найгіршого випадка змінюється від взяття безпосередно управління до перезапису адреси повернення в стеку та Виконання деякої існуючої бібліотечної процедури. Найбільш відомій приклад Такої сітуації часто назівають атаками Шляхом В«повернення в libcВ» (В«return-to-libcВ»), и цею способ атаки вважається набагато більш складна, чем Виконання коду в стеці або купі.
На відміну від цього, в монолітніх системах купуються Повноваження супер, ЯКЩО переповнення буферу відбувається в будь-якій частіні операційної системи. Більш того, в багатьох монолітніх системах допускається Виконання коду в стеці або купі, что істотно спрощує зловжівання переповнювання буфера.
Забезпечення надійного IPC
Добрі відомою проблемою.Більше механізмів обміну повідомленнями є управління буферами, альо в нашому варіанті комунікаційних прімітівів ми Повністю унікаємо цієї проблеми. У нашому механізмі сінхронної передачі Повідомлень Використовують рандеву, в результаті чого усувається потреба в буферізації и управлінні буферами, а такоже відсутня проблема вічерпання ресурсів. Если одержувач НЕ очікує ПОВІДОМЛЕННЯ, то прімітів SEND блокує відправника. Аналогічно, прімітів RECEIVE блокує процес, ЯКЩО немає ПОВІДОМЛЕННЯ, что очікує свого Отримання. Це означає, что для заданого процеса в табліці процесів у будь-який годину винен зберігатіся єдиний вказівнік на буфер ПОВІДОМЛЕННЯ.
На додаток до цього, у нас є Механізм асінхронної передачі Повідомлень NOTIFY, Який такоже НЕ є чутлівім до вічерпання ресурсів. ПОВІДОМЛЕННЯ є тіпізовані, и для шкірного процеса зберігається Тільки один біт для шкірного типу. Хочай ОБСЯГИ ІНФОРМАЦІЇ, якові можна Передат таким чином, обмеженності, цею підхід БУВ Обраний з-за своєї надійності.
До РЕЧІ, зауважімо, что у своєму IPC ми унікаємо переповнювання буфера Шляхом обмеження ЗАСОБІВ комунікації короткими повідомленнями фіксованої Довжина. ПОВІДОМЛЕННЯ є об'єднанням декількох тіпізованіх форматів Повідомлень, так что розмір автоматично вібірається компілятором, як розмір найбільшого допустимого типом Повідомлень, Який поклади від розміру ціліх чисел и покажчіків. Цею Механізм передачі Повідомлень вікорістовується для всіх Запитів и Відповідей.
Обмеження IPC
IPC - це потужній механізмом, Який потребує суворого контролі. Оскількі наш Механізм передачі Повідомлень є синхронними, процес, что Виконує прімітів IPC, блокується, поки Обидва учасника не стануть готовими. Корістувальніцькій процес может легко зловжіваті ЦІМ властівістю для завішування системних процесів Шляхом посилки запиту без Очікування ВІДПОВІДІ. Тому є Інший прімітів IPC SENDREC, что комбінує в одному виклик SEND и RECEIVE. ВІН блокує відправника до Отримання ВІДПОВІДІ на запит. З метою захисту операційної системи цею прімітів є Єдиним, Який можна використовуват Звичайний користувач. Насправді, в ядрі для шкірного процеса підтрімується бі...
