OSDev

Как правилнее обрабатывать ошибки в системных вызовах - прервать выполнение (СОИ или сигналы) или вернуть заведомо неверный результат?
Первый способ мне кажется неудобным для программиста. А второй чреват повреждением данных, если программу писал хелловордщик.

_________________
Found a CPU. LAPIC ID: 00

У меня все параметры, передаваемые системному вызову из задачи, подвергаются полному контролю. Если что-то не так, что:

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

Вообще, надёжность должна стоять на первом месте. Производительность, удобство и т.д. -- это всё менее важно.

Естественно, все параметры нужно тщательно проверять. Для одних неверных параметров достаточно вернуть ошибку "Неверный параметр", для других передать управление пользовательскому/ядерному обработчику исключений. Причем проверку нужно выполнять не только для явно передаваемых параметров, но и для всех буферов, структур, строк. Некоторые ошибки можно выявлять не только в начале обработки системного вызова, но и на протяжении всей обработки. Выполнение некоторых проверок зависит от уровня выполнения caller'а. Например, у меня есть user space service и kernel space service - для последнего не выполняются блокировки буферов, урезание области обработки нольтерминальных строк и т.п.

Это и ежу понятно.



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

_________________
Found a CPU. LAPIC ID: 00

Насчет "мю-ядра" не знаю, у меня монолит. Обработчик исключений вызывается, когда параметр некорректен косвенно - это всевозможные ошибки, связанные с буферами. Есть параметры, реакция на некорректность которых может отличаться в разных версиях ядра. Что касается обработки ошибок в приложении, то формально любой системный вызов, в который можно передать ошибочный параметр, должен выполнять проверку параметров, а приложение соответственно должно быть в состоянии эти ошибки обрабатывать. Однако по факту, если ты уверен во всех передаваемых приложением параметрах, то обработку ошибок можно и не делать. Хотя "это и ежу понятно".

Интерес представляет ошибка "Некорректный номер сервисной функции" и то, как ее обрабатывать.

Кажется я не умею объяснять. Что я имел ввиду:
Пусть есть два брата-погромиста: Петя и Вася. Пете надоели Линух и Винда и он решил поставить что-то новое.

Вариант первый: "высоконадёжная" ОСь "should die" с кошерной структурной обработкой исключений.
Установил, все работает. Пока Петя не начинает под нее программировать. Провозившись полдня с обработчиками исключений (вроде все логично продуманно, но для конкретной задачи не подходит) он решает сменить ОСь (а заодно и профессию). Петя уходит в магазин, а на компьютер садится Вася. Пишет свой хелловорд. Забывает поставить нолик. Видит окошко "программа совершила ошибку...". Проверяет программу, находит нолик, исправляет. Все работает!

Вариант второй: ненадёжная ось с кодами возврата.
Все поставил, все работает. Все! За две секунды все готово. Уходит в магазин, на компьютер садится Вася. Пишет свой хелловорд. Забывает поставить нолик. Ой, а он работал под рутом :-). БАХ и винта - как не бывало.

Кто виноват, кто прав?

_________________
Found a CPU. LAPIC ID: 00

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

Что же касается работы с правами администратора, то против лома нет приёма. Администратор по определению должен иметь возможность обходить стандартные средства защиты и т.п. Другое дело, что это должно выполняться явным образом. Например, система не даст открыть программе некий файл (весь диск, в частности), если эта программа не имеет соответствующих прав. Обычный пользователь не сможет запустить её с правами администратора, администратор -- сможет, но должен будет указать это явным образом. Ну а за это он уже будет отвечать сам :)

В общем, не надо пытаться сделать систему, надёжную на все 100% во всех ситуациях: такое попросту невозможно. Надо лишь точно и чётко обозначить границы, за которые обычная программа не сможет выйти ни при каких обстоятельствах, и проектировать/кодировать ОС, тщательно соблюдая эти самые границы (выполняя необходимые проверки и т.д.).

Кстати говоря, Вы зря противопоставляете обработку исключений и коды возврата. Эти механизмы отнюдь не противоречат друг другу и могут успешно совмещаться. Чтобы обеспечить обработку исключений на языке высокого уровня, требуется соответствующая поддержка со стороны компилятора и его библиотеки времени выполнения, однако от ОС тут требуется самый минимум: дать возможность задаче указать обработчики всяких нехороших событий вроде деления на 0. Никакой специальной поддержки SEH от собственно ОС не требуется, всё это реализуется исключительно кодом пользовательского режима.

А вот мой вариант. Я планирую в ОС сделать третий уровень привилегий - системный. Это наивысший уровень привилегий в моей архитектуре. Администратор почти всемогущ, но он не может непосредственно переписывать или удалять системные файлы работающей инсталляции ОС. Права на запись в конфигурационные файлы ОС имеют только системные сервисы, а замена исполняемых файлов ОС и файлов ресурсов возможна только после нотариальной проверки подлинности их источника. Удаление файла из системной области возможно только в том случае, что он не числится в списке системных файлов последнего, также нотариально заверенного, списка системных файлов. При такой архитектуре даже под администратором не страшен крэш любого пользовательского процесса, включая случайные нажатия Del, F8, Format C: и пр. Хотя, конечно остаются вопросы, связанные с ошибками в самом системном ПО и со сбоями оборудования. Также такая архитектура должна показать высокую устойчивость к вирусному заражению.
Надёжную на 100% систему сделать нельзя, но очень надёжную сделать можно.
Современные ОС уже делают некоторые телодвижения в этом направлении, - в Windows Vista/7 работает UAC, а в Линуксах администратору заводится банальный пользователь, а из под рута программы выполняются по спец требованию. Но это только шаг, к тому же кривобокий.

Что касается двух подходов, - согласен с SII, один другого не исключает, а наоборот, хорошо дополняют. Единственно, мне очень не нравится поддержка исключений со стороны ЯВУ. Все эти try/catch вместо облегчения написания кода сильно запутывают логику программирования. Пока что в стадии активного размышления, как должна выглядеть поддержка исключений со стороны ЯВУ, чтобы программировать стало действительно на порядок удобней.
Даже в относительно простом boot.exe на каждый read/write запарился писать if/else со стандартным сообщением об ошибке и однотипными действиями.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

У меня, как я уже говорил, при явном указании со стороны пользователя есть возможность делать всё, иначе нельзя, например, нормально отлаживать эти самые системные сервисы (ведь просто так к ним доступ получать нельзя, поскольку это будет дырой в безопасности). В общем, моя защита от администратора нацелена не на блокирование сознательно деструктивных действий, а на минимизацию шансов совершить какую-либо большую гадость по ошибке. Поэтому, в частности, задачи, запускаемые администратором, по умолчанию работают с правами обычного пользователя; если им нужны дополнительные права, администратор должен это указывать явно. Таким образом, если запущен файловый менеджер, но без таких прав, то случайно удалить системные файлы не удастся. Ну а если уж запустил с ними -- то это проблемы администратора :)

Что же касается Вашего подхода, то меня терзают смутные сомнения... Нет, не с надёжностью, а с удобством разработки и обслуживания системы и т.п. вещами. ИМХО, слишком жёсткие ограничения больше вреда приносят, чем пользы. Ну и, во всяком случае, должна иметься возможность настройки системы на отключение такой "параноидальной" безопасности :) Лично я бы точно отключил все подобные блокировки: если я -- администратор, я должен иметь возможность сделать абсолютно всё.



На Си++, как и на Си, не пишу, поэтому не шибко компетентен, чтобы судить о реализации обработки исключений в этих языках. Однако на Дельфях try...finally и try...except меня никак не напрягали, а временами позволяли улучшить читабельность программы. На Аде ещё лучше сделано (меньше писанины, никаких тебе классов ошибок придумывать не надо, ну и т.д.). Впрочем, сами по себе паскалеподобные языки намного читабельней, чем Си, если не пренебрегать правилами оформления.

Понятно, что если ты запустил rm -rf /, то уже ничто тут не спасет.

_________________
Found a CPU. LAPIC ID: 00