Разработка концептуально новой ОС

Цитата x, 10.09.03, 21:44:23

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

Это в корне неверно!
Приложения вообще не видят друг друга: адресное пространство приложения включает ТОЛЬКО память, выделенную лично ему - остальные адреса (страницы) указывают в никуда, при обращении к ним происходит исключение.

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

Драйвера будут на другом уровне, что пользователи. Но и можно отделить от ядра. (допустим сделать RING 1).

Сообщение отредактировано: rcz - 10.09.03, 18:40

Цитата rcz, 10.09.03, 22:02:44

Вся проблемма, что драйверам необходим непосредственный доступ к аппаратному.

Непосредственный доступ реализуем и в пользовательском режиме, через БКВВ.
Надо попробовать реализовать через нее. В крайнем случае, вариант с привилегир. режимом не требует дополнительных усилий, и всегда есть про запас.

Цитата

Как уже писал, за подгрузку драйверов отвечает ФС. Она же распределяет ресурсы.

..Это не описка?! Уж ФС тут точно ни при чем.

Цитата

А проблемма з защитой может только быть, если разрешить пользователям загружать свои драйвера

Пожалуй, насчет своих драйверов я бы и не боялся..
Но вот какие-нибудь китайские драйвера к китайскому оборудованию.. как-то опасливо.. :-/

Цитата

Получается, что ему при сохранении файла придется постоянно набирать пароль. Мне его жалко.

Даже в голову ничего не приходит, откуда такой вывод.. поэтому теряюсь, что ответить - но пароль пользователь вводит не более раза за сеанс работы..
Смысл в том, что когда прикладная программа просит доступ к файлу, мы не можем гарантировать, что она это делает по поручению пользователя. А ПП - системная утилита, заслуживающая доверия, и если она говорит, что таков заказ пользователя, то так оно и есть.

ФС - это скорее МФС менеджер файловых систем. Это не описка. Все оборудование становится в иерархию. Доступ - по имене оборудования. Так что как раз при чем.
При загрузке нового драйвера он регистрируется в ФС ядра - списке всех драйверов. (Аналог в линухах /dev/ в Виндах - \Drivers  \Devices)

Цитата Vilmor, 10.09.03, 17:08:36

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

К вопросу о терминологии. Виртуальный - воображаемый, не существующий на самом деле. Виртуальная память - память физически не существующая. Нет свопа => нет виртуальной памяти.

Определим терминалогию в памяти.
Логический адрес - адрес, употребляемые в программе (Селектор:смещение)
Линейный адрес - адрес = база, получаемая с помощью селектора + смещение
Физический адрес - адрес, получаемый из  линейного адреса с помощью страничного преобразования.
Виртуальная память - реализуется ОС перехватом Page Fault. И подгружает страницы из свопа.

Поэтому виртуальная память будет (этот механизм), а вот свопа...

Далее для Real-Time - современные ОС при создании процесса его не сразу загружают в память. Он загружается при первом обращении к странице (PF происходит), но не используется своп. Это и придется рассмотреть в Real-Time.

Люди! Читайте внимательнее! Я уже устал повторять одно и то же!

Цитата nvm, 10.09.03, 19:27:28

Теперь повтор идеи.

ОС должна быть такой, чтобы вирусов в ней не было. Не было в том смысле, что вирусы бы не могли распространяться по своей инициативе, а только с разрешения пользователя (если пользователь сам хочет запустить вирус, то это его право - но тогда это не вирус).
Ядро предполагается минимальное, поэтому добиться отсутствия дыр в нем - задача реальная.
Главные сервисные приложения, которые поставляются в дистрибутиве ОС, - тоже возможно вычистить.
Остаются прикладные программы - в них были, есть и, пока стоит мир, будут дыры. И пока существует Интернет будут браузеры, запускающие червей.
Отсюда единственное решение: прикладная программа НЕ ДОЛЖНА получать прав пользователя (разве что часть).
Но приложению нужно сохранять документы в каталоге пользователя, на который оно не имеет прав.
Поэтому оно должно обратиться к ПП, который через драйвер консоли или GUI, спрашивает у пользователя имя файла, затем сам открывает файл и передает его прикладной программе.

Таким образом, из FileSave приходит все же путь - а handle появляется на следующем уровне.

Если у кого-то есть лучшие идеи для исключения вирусов - то интересно послушать. Но ИМХО предложенная мера практически вынужденная, и в том или ином виде абсолютно необходима.

Итак, вы хотите, чтобы ПП сам открывал диалоги SaveAs и OpenAs, а так же, возможно и другие. Потом он должен обрабатывать возвращаемое из диалога значение и, если это возможно, открывал файл, возвращая приложению handle.

Что тогда собой представляет собой ПП? Это "ворота", "шлюз", через которые приложение имеет доступ к ресурсам, доступ к которым следует ограничить - файлы, девайсы, ключи... В любом случае, ПП смотрит, может ли данное приложение, запускаемое от данного пользователя, иметь доступ к данному ресурсу. Если ПП будет делать что-то ещё кроме этого, то неизбежно возникнут проблемы.

Во-первых, если он открывает диалоги, то он должен знать о GUI, который ему СОВЕРШЕННО НЕ НУЖЕН. Это значит, что на бездисплейных машинах прийдётся запускать GUI. Более того, даже тогда ничего не выйдет, поскольку пользователь не сможет работать с диалогом (нет дисплея!), и значит, ПП не сможет получить результат работы диалога SaveAs. Вообще, тогда приложение обламывается, потому что оно не может использовать диалог SaveAs, работающий в GUI. А файлы-то по-прежнему сохранять куда-то надо! Что делать? Понапихать в ПП до кучи разных вариантов выбора файла. Эти варианты потребуют не только GUI, но и ещё чёрт знает что.... Ваш ПП раздувается и приобретает поистине громадные размеры, потому что содержит тысячу бессмысленных зависимостей от ненужных здесь модулей и интерфейсов. А если понадобится тысяче первый?  Если у того же модуля будет расширен интерфейс? Вы кинетесь обновлять ПП, чтобы и приложение смогло иметь доступ к этим позможностям?

Вот к чему приводит смешение функциональности разных компонент в одной-единственной компоненте!
Я вам говорил, а вы не хотите слушать.

Поймите, я же не против ПП! Я толко против такой глупой реализации!
Пусть будет ПП! Он, конечно же, нужен! Но зачем его привязывать к GUI?

Далее, вы знаете, что объект user - это и есть своего рода ПП для приложений того пользователя (человека), с которым он связан?

Цитата nvm, 10.09.03, 19:27:28

Объясню подробнее (в предыдущем посте была только "голая" идея, без деталей реализации).
У ОСи нет глаз и ушей, ей плевать кто сидит за терминалом и есть ли вообще терминал. С точки зрения системы пользователь - это просто некоторое приложение, назовем его представителем пользователя (ПП).
И логинится в систему именно ПП, а вовсе не сам пользователь, который лишь подсказывает пароль.
ПП может работать и без реального пользователя, но когда пользователь сидит за терминалом, то ключи от драйверов консоли, GUI, DirectX, клавы и пр. передаются во владение ПП.

Объект user (который ПП) - это не объект учётной записи пользователя. Он создаётся, когда пользователь залогинился. Если он логинится с нескольких терминалов, то user всё равно один. И если он нигде не залогинен, но его процессы продолжают существовать, user так же продолжает существовать, чтобы контролировать эти процессы! Да, когда пользоватьель вновь логинится, ключи драйверов терминала (с которого входит в систему пользователь) передаются во владение ПП, т.е. объекту user.

И потом, вы предложили идею ПП, но не сказали, на каком основании он будет решать, каким из приложений пользователя он будет давать тот или иной ключ, а каким - нет. Если не знаете - посмотрите, как это сделано в UNIX - там это предусмотренно. Не хотите делать как в UNIX - всё равно посмотрите, может, у вас мысли какие-нибудь новые идеи появятся.

Пожалуйста, если хотите сделать настоящую ОС, а не самоделку, то узайте об этом побольше. Одного знания ключей явно не хватит!

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

1. Шумиха.
2. Неразбериха.
3. Поиск виновных.
4. Наказание невиновных.
5. Награждение непричастных.

Вот

Цитата rcz, 11.09.03, 11:37:25

Виртуальная память - реализуется ОС перехватом Page Fault. И подгружает страницы из свопа.

Вы как-то плавно перешли от вопросов "что такое X" вопросу  "как X реализуется".
Надо так и сказать: виртуальной памяти не будет, а будет перехват Page Fault.

Цитата

Далее для Real-Time - современные ОС при создании процесса его не сразу загружают в память. Он загружается при первом обращении к странице (PF происходит), но не используется своп. Это и придется рассмотреть в Real-Time.

Современные Real-Time ОС этим не занимаются. Представьте: надо вырубать реактор,  а у нас страница еще не загружена.

Цитата nvm, 10.09.03, 22:19:12

Смысл в том, что когда прикладная программа просит доступ к файлу, мы не можем гарантировать, что она это делает по поручению пользователя. А ПП - системная утилита, заслуживающая доверия, и если она говорит, что таков заказ пользователя, то так оно и есть.

Вот он, корень всех зол!
Оказывается, только пользователь имеет право выбрать файл, чтобы открыть его! А если приложению нужно работать ещё с каими-нибудь файлами (.dat, .c, .obj, .exe, .res, .xml, .dbf), кроме документов пользователя (.doc, .avi, etc), то она каждый раз будет спрашивать бедного пользователя: "А введи, пожалуйста в OpenDialog файл '/mysql/data/mytable.idx', чтобы я тебе быстренько обработала запрос SELECT * FROM mytable WHERE name='borej';"

Главная "концептуальная новизна" этой ОСи получается микроядерность+объектность. Плюсы этого - гибкость и динамичность. Значит должно все хорошо подгружаться, настраиваться, перенастраиваться. От сюда все ее основные концепции.

Цитата

1. Шумиха.
2. Неразбериха.
3. Поиск виновных.
4. Наказание невиновных.
5. Награждение непричастных.

Неуспев начаться этот проект эже на стадиях 1 и 2 одновременно.

И с неразберихой надо бороться написанием точной спецификации. Так что пишем. Пытаемся. (реализацию не трогаем, но учитываем). Пока пишем, убъем 2-х зайцев и неразбериху, и шумиху с ней связанную. Уже сложно что-то читать и разбирать.

Сообщение отредактировано: rcz - 11.09.03, 09:42

Ok. Пишем.

Только когда начнём их согласовывать, всё повторится

По-хорошему, надо завести на каждую проблему по отдельному треду, в идеале - на отдельном форуме. Ещё лучше - на отдельном сайте.

По этому поводу есть у кого-нибудь какие-нибудь соображения? Сами сделаем, или помощи ждать будем?

Где бы найти дом... или отель? Помощь не помешала бы... Но может получится, что ждать придется долго.
Это пока самый важный вопрос на данный момент.

тут был проект, но что-то он замарожен
http://pascal.sources.ru/cgi-bin/forum/YaBB.cgi?board=Projects;action=display;num=1057133485;start=0

Цитата rcz, 11.09.03, 14:20:12

Где бы найти дом... или отель? Помощь не помешала бы... Но может получится, что ждать придется долго.
Это пока самый важный вопрос на данный момент.

тут был проект, но что-то он замарожен
http://pascal.sources.ru/cgi-bin/forum/YaBB.cgi?board=Projects;action=display;num=1057133485;start=0

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

Самыми привлекательными хостингами мне кажутся valuehost.ru и agava.ru, но с ними далеко не всё ясно. К тому же, это достаточно дорогое удовольствие.

Есть ещё вопрос о том, что нам может понадобиться для сайта: проще ли настроить готовый портал, или же лучше просто поставить туда форум, гостевую и чат. Думаю, нам не стоит тратить время на написание своих скриптов и красивое оформление сайта.

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

Кроме того, было бы хорошо иметь свой IRC-канал, но тут я совершенно не в курсе.

Чем же конкретно могу помочь я?

1. Умею программировать на Perl, имхо, не так уж и плохо.
2. Есть опыт создания сайтов.
3. Естественно, знаю HTML и CSS.
4. Есть опыт работы с MySQL через Perl DBI.
5. Умею работать с CVS, но только как юзер.

К сожалению, с хостингом ничем не могу помочь

Хост надо искать. ( Платные -  8-20$ в мес. Есть и бесплатные. Но их качество - образно говоря MySQL нет)

форум можно какой-нить phpBB (Или как здесь YaBB).
Помимо HTML немного только знаю о ASP и ASP.NET. Опыта создания сайтов нет.
IRC - пока не обязателен.