Проблемы современных ОС и пути их преодоления

Проблемы современных  ОС и пути их преодоления

Мы живём в post/информационном, глобализированном мире, где компьютеры управляют атомными станциями, военными объектами стратегического назначенияи т.д. И при этом в современных операционных системах (ОС) имеются две характеристики, делающие их ненадежными и небезопасными: они огромны и обладают очень плохой изоляцией сбоев.

Большой размер современных операционных систем означает, что нет ни одного человека, который может разобраться во всей системе целиком. Очевидно, что трудно спроектировать систему хорошо, если никто на самом деле не понимает её. Но ни один также человек не разбирается во всех деталях того, как функционирует авианосец, да в этом и нет необходимости, так как каждая из подсистем авианосца хорошо изолированы друг от друга. Поэтому проблема с засорённым туалетом никак не повлияет на запуск ракет. В отличие от операционных систем где изоляция между компонентами выражена не так сильно. Поэтом, если вирус или червь инфицирует одну процедуру ядра, то нет способа удержать его от быстрого распространения на остальные процедуры и от захвата управления машиной в целом.

К счастью, ситуация не безнадёжна. Исследователи пытаются создать  более надёжные операционные системы. Есть несколько различных подходов, которые направлены на то, чтобы сделать операционные системы будущего более надёжными.

Подход 1.

Подход на основе изоляции драйверов предложили Свифт и Бершад. Ими была создана прототипную подсистему, получившую название Nooks. Nooks разработан для улучшения надёжности существующих операционных систем, таких, как Windows или Linux. Технология Nooks поддерживает монолитную структуру ядра, в которой сотни или тысячи процедур связаны вместе в одном адресном пространстве и работают в режиме ядра. Этот подход сосредоточен на том, чтобы сделать драйверы устройств менее опасными.//Слайд

В частности, как показано на Рисунке, Nooks защищает ядро от переполненных ошибками драйверов устройств, за счет того, что каждый драйвер заключается в оболочку и размещается на уровне защищенного программного обеспечения, который формирует домен упрощенной защиты. Оболочка вокруг каждого драйвера тщательно отслеживает все взаимодействия между драйвером и ядром. Этот метод также может быть использован для других расширений ядра, таких, как загружаемые файловые системы.

Целями проекта Nooks являются:

• защита ядра от сбоев и  отказов драйвера,

• автоматическое восстановление в случае сбоя драйвера, и

• делать всё это со столь минимально возможными изменениями по отношению к существующим драйверам и ядру.

Подход 2.

Второй подход корнями  восходит к концепции виртуальной  машины, которая была актуальна в конце 1960-х годов. Идея заключается в запуске специальной управляющей программы, называемой монитором виртуальной машины, напрямую на «голом железе», то есть на компьютере без операционной системы. Виртуальная машина создаёт несколько экземпляров реального компьютера. Каждый экземпляр может поддерживать работу любой программы, которая может быть запущена на на данном аппаратном обеспечении. Эта методика частоо используется для того, чтобы была возможность запуска сразу нескольких операционных систем одновременно на одном и том же компьютере, при этом каждая ОС думает, что она владеет компьютером полностью и единолично. Так же использование виртуальных машин имеет заслуженную репутацию, как хорошего способа для локализации отказов – в конце концов, если каждая из виртуальных машин даже не подозревает о существовании остальных, то и проблемы в одной из них не могут распространиться на остальные виртуальные машины.//Слайд

Если конкретно, то в 1990-х  исследовательская группа в университете Карлсруэ разработала микроядро L4. Они смогли запустить слегка модифицированную версию Linux (L4 Linux) поверх L4 , это было описано как разновидность виртуальной машины. Позднее исследователи смогли запустить поверх L4 несколько копий Linux. Как показано на Рисунке, интуиция привела их в дальнейшем к идее использовать одну виртуальную машин для работы прикладных программ, а ещё одну или более виртуальных машин – для драйверов устройств.

Если поместить драйверы устройств в одну или более  виртуальных машин, отделённых от основной виртуальной машины, на которой работает остальная часть операционной системы и прикладные программы, то в случае отказа какого-либо драйвера устройства «рухнет» только его виртуальная машина, но никак не основная. Дополнительное преимущество данного метода заключается в том, что нет никакой необходимости вносить изменения в драйверы устройств, поскольку они «видят» нормальное состояние ядра Linux. Конечно же, само ядро Linux должно было быть изменено в целях паравиртуализации, но это разовое изменение, и нет необходимости повторять его для каждого драйвера устройства.

Два предыдущих подхода основываются на латании существующих операционных систем. Но для того, чтобы системы будущего были более надежны, необходимо рассмотреть одну из главных проблем ос: существование цельной операционной системы, которая запускается как единая гигантская двоичная программа в режиме ядра. И это вместо того, чтобы только крошечное микроядро запускалось в режиме ядра, а вся остальная часть операционной системы работала в режиме пользователя как набор изолированных серверных процессов и драйверов.

Этой идее уже около 20 лет, однако она не была полностью исследована сразу же, поскольку имела маленькую производительность, нежели монолитное ядро. В 1980-е производительность имела более важную роль, а вот надёжность и безопасность ещё не были под жёстким контролем. //Слайд

Рассмотрение нового примера позволяет сделать идею мультисерверной операционной системы более ясной. Как показано на Рисунке, в Minix 3 (микроядерная операционная система) микроядро обрабатывает прерывания, обеспечивает основные механизмы управления процессами, осуществляет межпроцессное взаимодействие и выполняет планировку процессов.

Поверх микроядра находится уровень драйверов устройств. Для каждого устройства ввода- вывода имеется свой собственный драйвер, который работает как отдельный процесс в своём собственном адресном пространстве.

Поверх уровня драйверов  устройств находится уровень  серверов. Файловый сервер является маленькой (4'500 строк исполняемого кода) программой, которая принимает запросы от пользовательских процессов на формирование POSIX-системных вызовов, связанных с файлами, таких, как read, write, lseek и stat, и выполняет их.

И наконец, над серверным  уровнем располагаются пользовательские процессы Разница этой Unix-подобной системой перед другими заключается в том, что библиотечные процедуры для read, write и остальных системных вызовов выполняются через посылку сообщений серверам. Кроме этой разницы – скрытой в системных библиотеках – они являются нормальными пользовательскими процессами, которые могут использовать POSIX API.

Каждая из попыток улучшить надёжность операционной системы базируется на предотвращении полного отказа системы из-за множества ошибок в драйверах устройств.