Изоляция ошибок

В большой вычислительной системе изоляция программ является ключевым фактором, гарантирующим, что отказы в программе одного пользователя не приведут к отказам в программах других поль­зователей или к полному выводу системы из строя. Основные правила изоляции ошибок перечислены ниже. Хотя в формулировке многих из них употреб­ляются слова «операционная система», они при­менимы к любой про­грамме (будь то операционная система, мо­нитор телеобработки или под­система управления файлами), кото­рая занята обслуживанием других про­грамм.

1. Прикладная программа не должна иметь возможности непос­редст­венно ссылаться на другую прикладную программу или дан­ные в другой программе и изменять их.

2. Прикладная программа не должна иметь возможности непо­средст­венно ссылаться на программы или данные операционной сис­темы и изме­нять их. Связь между двумя программами (или програм­мой и операцион­ной системой) может быть разрешена только при условии использования четко определенных сопряжений и только в случае, когда обе программы дают согласие на эту связь.

3. Прикладные программы и их данные должны быть защищены от операционной системы до такой степени, чтобы ошибки в опера­ционной системе не могли привести к случайному изменению при­кладных про­грамм или их данных.

4. Операционная система должна защищать все прикладные про­граммы и данные от случайного их изменения операторами сис­темы или обслуживающим персоналом.

5. Прикладные программы не должны иметь возможности ни оста­но­вить систему, ни вынудить ее изменить другую прикладную программу или ее данные.

6. Когда прикладная программа обращается к операционной сис­теме, следует проверять допустимость всех параметров. Более того, прикладная программа не должна иметь возможности изме­нить эти параметры между моментами проверки и реального их ис­пользования операционной систе­мой.

7. Никакие системные данные, непосредственно доступные при­клад­ным программам, не должны влиять на функционирование опе­рационной системы. Например, OS/360 хранила некоторые блоки, управляющие рас­пределением памяти, в областях основной памя­ти, доступных прикладным программам. Ошибка в прикладной программе, вследствие которой содер­жимое этой памяти могло быть случайно изменено, приводила в резуль­тате к сбою системы. Линейка Windows в теории выдерживает этот прин­цип, но на практике некорректное обращение к некоторым адресам приво­дит к зависанию системы.

8. Прикладные программы не должны иметь возможности в обход операционной системы прямо использовать управляемые ею аппа­ратные ресурсы. Прикладные программы не должны прямо вызывать компоненты операционной системы, предназначенные для исполь­зования только ее подсистемами.

9. Компоненты операционной системы должны быть изолированы друг от друга так, чтобы ошибка в одной из них не привела к изме­нению других компонент или их данных.

10. Если операционная система обнаруживает ошибку в себе са­мой, она должна попытаться ограничить влияние этой ошибки одной приклад­ной программой и в крайнем случае прекратить вы­полнение только этой программы.

11. Операционная система должна давать прикладным программам возможность по требованию исправлять обнаруженные в них ошиб­ки, а не безоговорочно прекращать их выполнение.

Реализация многих из этих принципов влияет на архитектуру лежа­щего в основе системы аппаратного обеспечения.

Читатель может заметить, что многие из перечисленных правил яв­ляются также правилами обеспечения защиты в операционных системах [20]. Таким образом, цели обеспечения защиты ресурсов и надежности обычно согласуются. Это подтверждается также разработанной IBM экспе­риментальной Системой защиты ресурсов для OS/360. Благодаря более высокой степени изоляции в этой системе были обнаружены ранее не за­меченные ошибки в системных компонентах (например, в компиляторах) и прикладных программах, а также значительно снижена частота случайных отказов системы из-за ошибок в при­кладных программах.