Центр информации по операционным системам: Форумы / ОС-21 / Заглядывая в туманное будущее

Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21		<< Предыдущая тема \| Следующая тема >>
Заглядывая в туманное будущее - обсуждение

Переход на страницу 1 2 3 ... 7 [8] 9 ... 13 14 15
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

captain cobalt

Вторник 13.09.2005 22:23

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

Dron написал(а) ...
А в остальном я полностью согласен с предыдущим оратором... доверяй, но проверяй как говорится.

Что мешает?

Dron написал(а) ...
там что, USE SYSTEM - это подсказка компилятору?

Да.
IMPORT SYSTEM;

Dron написал(а) ...
Кстати, вот такой вопрос Капитану...
Ты согласился бы если в твоем банке все работли бы под твоей любимой BlueBottle? и сервера... все... а?
(сейчас мы сразу узнаем что он реально думает про безопасность своей системы

)

Разумеется.

Вообще, у меня руки чешутся поставить свой собственный сервер на Bluebottle. Чтобы его все ломали.

Вот только средств не хватает.

Про банки проблема в большей степени в том, что для Bluebottle нет банковских систем.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

captain cobalt

Вторник 13.09.2005 22:26

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

may написал(а) ...
Такая система по определению ПОЛНОСТЬЮ зависит от добропорядочности - внимательности - профессионализма стороннего разработчика. Единственный тезис который как-то касается защиты от несанкционированной работы модулей звучит пока что так - "не загружайте непроверенные модули"
я попытался выянить, что означает "проверенный модуль".

Система зависит от "добропорядочности - внимательности - профессионализма" разработчиков только системных модулей.

В настоящее время программное обеспечение разрабатывается на языках высокого уровня. На ассемблере разрабатывается много менее одного процента - в основном драйверы и времякритичные процедуры.

Идея заключается в том, чтобы поместить все эти ассемблерные процедуры в системные модули, а весь остальной код разрабатывать на безопасном языке.

Таким образом, практически весь код в системе будет безопасным - его не нужно "проверять", его безопасность обеспечивается языком программирования.

Системных же модулей будет весьма немного.

may написал(а) ...
Допустим есть компания вся в цифровых подписях с головы до ног
и выпускает она замечательные модули, которые я загружаю уже 5 лет и жутко ими доволен
Тут приходит на работу в эту самую компанию "злонамеренный" Вася Пупкин, и немного правит код следующего шедевра которым компания радует миллионы свох поклонников
И я честно загружаю этот шедевр и получаю по полной программе от Васи

Это касается только системных модулей.
Для чего понадобилось так много системных модулей?

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

Vadim Ushakov

Среда 14.09.2005 11:38

ID пользователя #409

Зарегистрирован: Четверг 18.08.2005 04:25
Местонахождение: Красноярск
Сообщений: 85

captain cobalt написал(а) ...
У меня нет никаких чувств к языкам си. Поэтому особого смысла не вижу. Более того, если язык будет слишком похож на си, у других могут возникать вопросы типа "почему while (*p++=*q++) не компилируется?".

У меня тоже особых чувств к ним нет.

Но хотелось бы писать "{}", а не "BEGIN END"; "=", а не ":="; "a+=b", а не "a = a + b". Просто так удобнее лично мне. Можно прикрутить на тот же Оберон другой синтаксический анализатор - и все. В полностью модульной системе - это не проблема.

captain cobalt написал(а) ...
Встроенная в другие языки обработка исключений пытается преодолеть некоторые ограничения однопоточного программирования.
С активными объектами всё становится гораздо лучше.

Пусть у нас имеется активный объект без модификатора safe. В нем происходит исключение (например, деление на ноль). Поток объекта закрывается. Вопрос: что будет происходить с другими потоками, когда они вызывают методы "усопшего". Если по хорошему, то должно инициироваться исключение "ошибка взаимодействия", как в Аде. И еще вопрос: может ли один поток убить другой поток? И если нет, то как принудительно завершать активные объекты при остановке системы или при logout?

may написал(а) ...
Отвечаю конкретно - речь шла о том, что в любом модуле, импортирующем System,
разрешено выполнять любые низкоуровневые операции доступа к памяти, причем как рассказал Капитан в кольце 0.

Гениально! Каков аргумент!
В системах типа Windows АБСОЛЮТНО ЛЮБОЙ модуль может "выполнять любые низкоуровневые операции доступа к памяти", и это никого не приводит в возмущение! А если этот модуль - драйвер, то он их выполняет еще и в нулевом кольце! Замечательно! А вот в Обероне глядя на какой-то конкретный модуль можно с уверенность сказать одно из двух:
1. Этот модуль АБСОЛЮТНО безопасен, поскольку не имеет доступа к низкоуровневым операциям.
2. Этот модуль теоретически может быть опасен - тогда разработчик должен его тестировать, тестировать и еще сто раз тестировать.
Обратите внимание, что в Windows ВСЕ модули относятся к пункту два. А в Обероне - считанные единицы: только те модули, в которых реализована run-time среда и драйверы железа.

Падает тот, кто бежит; тот, кто лежит – уже не падает.

Наверх

captain cobalt

Среда 14.09.2005 13:00

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

Vadim Ushakov написал(а) ...
У меня тоже особых чувств к ним нет.

Ничего не имею против, но мне это не нужно.

Для меня исходники Bluebottle выглядят вполне читабельными.

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

Если мне приспичит писать компилятор, то я предпочту взять каноническое определение языка (хотя у меня тоже есть "сверхценные" идеи как "улучшить" язык).

Vadim Ushakov написал(а) ...
Пусть у нас имеется активный объект без модификатора safe. В нем происходит исключение (например, деление на ноль). Поток объекта закрывается. Вопрос: что будет происходить с другими потоками, когда они вызывают методы "усопшего".

Будут вызываться как обычно.

Возможность вызывать методы объекта, прекратившего активность - это штатная возможность.

Тонкости возникают если исключение произошло внутри EXCLUSIVE-блока. Очевидно, снимать блокировку объекта нельзя, потому что он находится в противоречивом состоянии. Блокировку никто не сможет снять. Каждый кто попытается войти в EXCLUSIVE-блок умершего объекта, будет заблокирован навечно. Когда заблокируются все, у кого были указатели на умерший объект, и на кого нет других указателей, всю эту компанию приберёт сборщик мусора.

Однако, исключение внутри EXCLUSIVE-блока, если не делать его специально - это фантастика.

Vadim Ushakov написал(а) ...
И еще вопрос: может ли один поток убить другой поток? И если нет, то как принудительно завершать активные объекты при остановке системы или при logout?

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

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

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

Vadim Ushakov

Среда 14.09.2005 14:46

ID пользователя #409

Зарегистрирован: Четверг 18.08.2005 04:25
Местонахождение: Красноярск
Сообщений: 85

captain cobalt написал(а) ...
Для меня исходники Bluebottle выглядят вполне читабельными.

В конечном счете, это дело вкуса. Когда в Delphi мне приходится в очередной раз старательно выписывать что-то типа "VeryVeryVeryVeryLongName:=VeryVeryVeryVeryLongName+1;", мне приходит в голову, что синтаксис Си все-таки не так уж плох. Впрочем, когда я вспоминаю про "for(tra-la-la; tra-la-la; tra-la-la)", я готов признать, что Паскаль гораздо логичнее.

captain cobalt написал(а) ...
Однако, исключение внутри EXCLUSIVE-блока, если не делать его специально - это фантастика.

Не эта ли фантастика приводит к тому, что на моей машине Bluebottle виснет намертво после 20-30-ти минут аптайма?..

Касательно исключений. Я убежден, что имеется реальная потребность их использования. Например, у нас есть некоторая процедура, которая открывает/создает несколько ресурсов и затем выполняет с ними нечто полезное. Без исключений придется писать так:
function Foo():SomeType;
begin
открываем первый ресурс;
если была ошибка, возвращаем nil;
открываем второй;
если была ошибка, возвращаем nil;
открываем третий;
если была ошибка, возвращаем nil;
делаем что-то полезное и возвращаем результат;
end;
И в вызывающей процедуре:
procedure Bar();
var нечто: SomeType;
begin
нечто := Foo();
if нечто = nil
then говорим пользователю об ошибке;
else делаем что-то полезное;
end;
В этом примере опасность скрывается в проверках на nil. Если мы пропустим хоть одну такую проверку - наша программа грохнется. Разыменование нулевого указателя run-time-среда никому не прощает.

А если есть механизм ловли исключений, то это значит, что в Foo таких проверок не будет вообще. А в Bar будет один оператор try-except. Исключения будут иницироваться в той процедуре, которая выполняет реальную работу по открыванию/созданию ресурса - и, поскольку она знает реальную причину ошибки, то сможет в объект-исключение поместить внятное описание ошибки, которое мы пользователю и приподнесем. При этом, даже если в Bar отсутствует try-except, то программа скорее всего аварийно завершится, но пользователь по крайней мере получит внятное описание случившегося, когда отработатет самый верхний try-except блок в стеке вызовов. (А если мы пропустим проверку "if нечто = nil", то пользователю скажут о "неверно выполненной операции" или о "разыменовании нулевого указателя", что душевного равновесия ему не прибавит.)
Исключения улучшают надежность программ и способствуют уменьшению количества ошибок в коде - меньше ветвлений в коде, меньше шанс ошибиться. И заодно позволяют писать более дружественные программы.

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

Падает тот, кто бежит; тот, кто лежит – уже не падает.

Наверх

captain cobalt

Среда 14.09.2005 16:09

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

Vadim Ushakov написал(а) ...
Когда в Delphi мне приходится в очередной раз старательно выписывать что-то типа "VeryVeryVeryVeryLongName:=VeryVeryVeryVeryLongName+1;", мне приходит в голову, что синтаксис Си все-таки не так уж плох.

Для инкремента в Оберонах есть полезная предопределённая процедура INC().

И в борландовых паскалях тоже.

Vadim Ushakov написал(а) ...
Не эта ли фантастика приводит к тому, что на моей машине Bluebottle виснет намертво после 20-30-ти минут аптайма?..

Не знаю...

Vadim Ushakov написал(а) ...
Касательно исключений. Я убежден, что имеется реальная потребность их использования.

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

Установки обработчиков исключений привносят накладные расходы по времени исполнения и размеру программы.

Исключения серъёзно препятствуют и усложняют оптимизацию кода.

Vadim Ushakov написал(а) ...
А если есть механизм ловли исключений, то это значит, что в Foo таких проверок не будет вообще. А в Bar будет один оператор try-except.

Коль скоро мы написали Bar с проверкой NIL вручную, то теперь опираясь на него можно возводить следующий уровень абстракции и не задумываться об исключениях. А Foo и Bar - это сильно сцепленные процедуры.

Vadim Ushakov написал(а) ...
Исключения будут иницироваться в той процедуре, которая выполняет реальную работу по открыванию/созданию ресурса - и, поскольку она знает реальную причину ошибки, то сможет в объект-исключение поместить внятное описание ошибки, которое мы пользователю и приподнесем.

Если из вызываемого кода возвращаются какие-то данные, то лучше делать это явно. Чтобы это было объявлено в интерфейсе.

Vadim Ushakov написал(а) ...
При этом, даже если в Bar отсутствует try-except, то программа скорее всего аварийно завершится

И здесь возникает вопрос. В чём фундаментальное отличие "забыли проверить NIL" от "забыли поймать исключение"?

Vadim Ushakov написал(а) ...
А если мы пропустим проверку "if нечто = nil", то пользователю скажут о "неверно выполненной операции" или о "разыменовании нулевого указателя", что душевного равновесия ему не прибавит.

Что есть в Оберонах.

-- просмотр стека; можно увидеть в каком месте произошло исключение
-- можно создать отдельный активный объект для выполнения "небезопасной операции"; если он получит трапом по голове, мы будем в безопасности.

Vadim Ushakov написал(а) ...
Короче, если не хотите, чтобы ваши программы работали "почти всегда", используйте язык с механизмом обработки исключений.

Ст'оит только забыть поймать хотя бы только одно исключение, как программа начнёт работать "почти всегда". Использование языка с исключениями приводит к излишне расслабленому, наполненному избыточными предположениями, стилю программирования: "с этой проблемой ТАМ [где поймают исключение] разберутся". А если не разберутся?

Гораздо лучше на уровне архитектуры гарантировать выполнение предусловий.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

may

Пятница 16.09.2005 14:46

ID пользователя #420

Зарегистрирован: Понедельник 05.09.2005 08:03
Местонахождение: г.Чита
Сообщений: 6

Vadim Ushakov написал(а) ...

Ну если уж мы начали использовать превосходные степени....
Предыдущий абзац это вобще шедевр аргументации!

Звучит примерно так же как "В прекрасной Bluebottle с защитой памяти дело обстоит так же плохо как и
в "попсовой" Windows".

А если в замечательной Bluebottle все примерно
так же как в окошках, то лучше такую систему использовать сторого для "любования"
и вместо аквариумов продавать компьютеры с предустановленной этой удивительной
системой.

Vadim Ushakov написал(а) ...

А вот в Обероне глядя на какой-то конкретный модуль можно с уверенность сказать одно из двух:

1. Этот модуль АБСОЛЮТНО безопасен, поскольку не имеет доступа к низкоуровневым операциям.
2. Этот модуль теоретически может быть опасен - тогда разработчик должен его тестировать, тестировать и еще сто раз тестировать.
Обратите внимание, что в Windows ВСЕ модули относятся к пункту два. А в Обероне - считанные единицы: только те модули, в которых реализована run-time среда и драйверы железа.

Еще раз повторюсь - знание о том, что модуль может быть опасен "в принципе" дает не очень много.
Конкретный потенциально опасный модуль можно либо проверить, либо принять на веру, что
все нормально, понадеявшись на цифровую подпись. Каким образом может быть произведена проверка в
Bluebottle мне никто так и не ответил. Проверка кода сторонней конторой показалась Капитану
невозможной по организационным и финансовым соображениям. Значит у нас осталась только вера в цифровую подпись.
Аргументы типа "в Windows тоже самое" и даже "у нас лучше чем в Windows" и даже "у нас лучше чем в Linux"

кажутся мне совершенно неубедительными потому, что если уж речь идет об новой
ОС, то закладываться надо в первую очередь не на превосходство над существующими,
а на "должно быть так". Исходя из изложенного выше я считаю, что подход к защите памяти примененный в Bluebottle
несостоятелен для ОС 21 века "массового применения".

Если расчитывать только на существующие процессоры то система управления памятью
может выглядеть так:
1. Микроядро в кольце 0
2. Драйвера в кольце 3
3. Фраймворк, рантайм, как угодно называйте, можно даже такой как использован в Bluebottle

)
4. Отдельная "песочница" для внешних приложений, т.е для бинарного кода со стороны
могущего считаться небезопасным. Каждая порция исполняемого кода в своем адресном
пространстве.
5. Реализация АПИ хотя бы от Линукса для того чтобы в песочнице мог исполняться унаследованный код
6. Продуманная система утилит для ускорения и облегчения процесса портирования приложений под фраймворк.
7. Самое главное - стимуляция разработчиков к переносу кода из "песочницы" во фраймворк

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

во-вторых, систему, оснащенную мощной собственной средой испонения "безопасного кода", можно АктивОберон

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

Наверх

captain cobalt

Пятница 16.09.2005 15:53

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

may написал(а) ...
Конкретный потенциально опасный модуль можно либо проверить, либо принять на веру, что все нормально, понадеявшись на цифровую подпись. Каким образом может быть произведена проверка в Bluebottle мне никто так и не ответил.

Bluebottle - это рантайм для языка Active Oberon.

Вообразим себе систему, в которой нельзя загружать бинарные модули, только через исходник на безопасном языке. Active Oberon - безопасный язык (без модуля SYSTEM).

Механизма для проверки безопасности бинарного модуля, или импортирующего SYSTEM нет. Есть только чёткое разделение на безопасные и системные модули. И на уровне архитектуры стараются минимизировать количество кода в системных модулях - используют их только для специфичных непереносимых вещей. Основная же часть (более 99%) является безопасной. Что непонятно?

may написал(а) ...
что если уж речь идет об новой ОС, то закладываться надо в первую очередь не на превосходство над существующими, а на "должно быть так".

Вот.

Такая архитектура это именно "должно быть так".

may написал(а) ...
1. Микроядро в кольце 0

Дальше можно не читать.

Если необходимо взаимодействие/совместимость с другими ОС, то гораздо сподручнее не кольцами жонглировать, а перенести Bluebottle в желаемую ОС. См, например, WinAos.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

Dron

Пятница 16.09.2005 16:07

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Капитан, а ты действительно думаешь что все строем пойдут изучать Оберон? или может научишь как писать модули на C++? (Ну ладно, С++ плохой язык) хочу на Eiffel... не люблю я паскаль!!!

Жава конечно хорошо, а .Net лучше... угадайте почему?
Да очень просто... под .Net десятки языков а Жава одна.

Кольцами жонглировать может и не так сподручно, зато никакой код не сможет это обойти! на слово я никому не верю.

тем более, когда речь идет о моей безопасности...

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

А насчет цифровых подписей... - помоему в виндузе это не работает.

если нужен какой-то модуль - тебе пофиг есть у него подпись или нет... Винда направно злится... всеравно устанавливать...

[ Редактирование пятница 16.09.2005 16:14 ]

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

Андрей Валяев

Наверх

captain cobalt

Пятница 16.09.2005 18:41

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

Dron написал(а) ...
Капитан, а ты действительно думаешь что все строем пойдут изучать Оберон?

Там нечего изучать.
Рассмотрим Active Oberon Language Report.
23 (двадцать три) страницы, включая:
-- обложку
-- описание конструкций языка
-- список литературы
-- клочки кода

Рассмотрим стандарт с++ (появился на osrc благодаря vilmor)
25 (двадцать пять) страниц - оглавление.

Dron написал(а) ...
или может научишь как писать модули на C++?

Никак. Только классы.

Dron написал(а) ...
хочу на Eiffel...

В таком случае рекомендую приобрести свежую книгу

Мейер - Объектно-ориентированное конструирование программных систем (2005)

написанную отцом-основателем языка Eiffel.
Книгу легко узнать на прилавке - на обложке изображена эйфелева башня.

Dron написал(а) ...
не люблю я паскаль!!!

Что это вообще за детский сад?

Хочу - не хочу; люблю - не люблю.

Хотя бы какой-то опыт программирования на сильно типизированных языках иметь надо.

Dron написал(а) ...
Жава конечно хорошо, а .Net лучше... угадайте почему?
Да очень просто... под .Net десятки языков а Жава одна.

Это только один технический параметр.
Другие есть?
Или .NET - это самое лучшее в мире во веки веков?

Dron написал(а) ...
Кольцами жонглировать может и не так сподручно, зато никакой код не сможет это обойти!

Вдобавок к вышеперечисленному можно добавить:
-- немаскируемое прерывание SMM
-- f00f на процессоре Pentium
-- прочие Errata на сайте производителя

Какие будут опровержения?

Dron написал(а) ...
на слово я никому не верю.

А Интелу?

Dron написал(а) ...
Эмуляция (Жава и .Net всякие) это конечно тоже хорошо, но реальная платформа быстрее. я не хочу тратить и так невысокую производительность (лишней она, как известно, не бывает)

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

Dron написал(а) ...
А насчет цифровых подписей... - помоему в виндузе это не работает.

Там других механизмов нет.
В Bluebottle другой механизм есть - безопасный язык программирования. И это основной механизм.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

Переход на страницу 1 2 3 ... 7 [8] 9 ... 13 14 15
Перейти: Наверх