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

[nvm]

Цитата rcz, 23.09.03, 11:53:52

Ключи предлагаю организовать следующей структурой
.....

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

Цитата

struct OBJECT{
    ...

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

Объект содержит указатель на лист этого дерева (так определяется его ключ), ACL, и Sign - список ключей  - подпись, "олицитворение".

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

Ключ - это не только листья, но и любая вершина (узел) дерева.

Цитата

Интерйейс - тоже объект.

Здесь начинается путаница.
Предлагаю в ядре вообще не использовать понятие объекта, как "туманное", а использовать только процесс и поток.
Только процесс имеет свое адресное пространство и таблицу хэндлов.
Поток имеет ключ, стек и точку входа в пространстве процесса.

Цитата

Таблица хэндлов у каждого процесса своя и она не доступна юзеру для непоследственного обращения.

Она вообще в адресном пространстве ядра.

Цитата

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

Ну да.

Цитата

функции

Ненужные:
AddKeyToACL
RemoveKeyFromACL
AddKeyToSign
RemoveKeyFromSign

- вместо них описана Grant/RevokeKey

В функции
BOOL IsKeyInSign(HANDLE hKey) - достаточно одного параметра.

Цитата

Права доступа к объекту определяет администратор. При создании пользователя, создается и его ключ. Если он хочет допустить пользователя к объекту, он добавляет этот ключ в его ACL.

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

Цитата

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

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

Цитата

Ключи в дерево добавляются при запуске приложения.
...
Удаляются ключи из дерева, если RefCount становится 0.

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

Сложность возникает - когда приложение должно владеть ключом объекта, который еще не создан. В этом случае процесс, предоставляющий ключ, должен этот ключ перед этим создать, без привязки к объекту. То есть в ссылке на объект действительно допускается NULL.
Другой вариант - передавать ключ во владение позже, когда объект уже запущен. Но это уже вопросы дизайна следующего уровня (утилит).

[rcz]

Не согласен.

Цитата

1 - контролируется системой - сама возможность обратиться к интерфейсу, получение хэндла
2 - на уровне объектов. Может отсутствовать. Объект при обработке вызова может дополнительно проверять подписи.

Это должно быть.
1) Рассмотрим к примеру хотя бы частые обращения к записи. Постоянные проверки ни к чему.
2) Архитектуру это не уходшит. Даже наоборот.
3) Не все есть файловые системы. Большинству объектов не понадобятся проверки при каждом вызове.

Главное. Подпись будет всегда в каждом сообщении. А смотреть объекту ее необязательно.
Хэндлы вадает ОС. Она их всегда проверяет.

Цитата

Внутренний хэндл никак не защищен - это просто число, которое можно указать "от фонаря", и если оно случайно совпадет с хэндлом файла, открытого другим процессом, то к файлу получим доступ. Так можно совершать случайные пакости.

Таблицу внутренних хэндлов спокойно можно разделить между процессами или держать в адресном пространстве процесса. Надо избежать того, что внутренние объекты давали всей системе хэндлы из одного адресного пространства.

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

Цитата

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

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

Сообщение отредактировано: rcz - 23.09.03, 19:10

[rcz]

Цитата

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

Это как раз надо. Не будет одно и то же приложение, запущенное от разных пользователей, иметь одни и те же права?

Цитата

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

Сложность возникает - когда приложение должно владеть ключом объекта, который еще не создан. В этом случае процесс, предоставляющий ключ, должен этот ключ перед этим создать, без привязки к объекту. То есть в ссылке на объект действительно допускается NULL.
Другой вариант - передавать ключ во владение позже, когда объект уже запущен. Но это уже вопросы дизайна следующего уровня (утилит).

это простой момент. Ключ ведь создается явно при запуске приложения(создателем). Ключи для несуществующих объектов создаются, но ни на кого не ссылаются. Ключи интерфейсов создаются уже самим объектом.
А удаление ключей сделаьб очень просто при RefCount ==0; Отследить очень просто. Самому удалять - кто-то когда-то забудет, и останется мусор.
А при подсчете ссылок - при удалении объекта, проходишься по его объектам и удаляешь соответствующие ключи (RefCount--).

Цитата

Здесь начинается путаница.  
Предлагаю в ядре вообще не использовать понятие объекта, как "туманное", а использовать только процесс и поток.
Только процесс имеет свое адресное пространство и таблицу хэндлов.
Поток имеет ключ, стек и точку входа в пространстве процесса.

Никакой путаницы нет. Все есть объекты. И процессы, и потоки. DLL  - тоже объект со своим адресным пространством. (точнее должно быть все как COM). Дальше только детали, чьи это адресные пространства и с кем они его делят. (пример - в Linux и процессы и потоки имеют одинаковые структуры. Только у вторых одинаковые указатели на страницы памяти).

Цитата

Ненужные:
AddKeyToACL
RemoveKeyFromACL
AddKeyToSign
RemoveKeyFromSign
- вместо них описана Grant/RevokeKey

Работу с ACL и SIGN надо разделить. Поэтому эти функции будут.

BOOL IsKeyInSign(HANDLE hObj,HANDLE hKey);  - 2 параметра. Обязательны. Пример: приходит сообщение от Obj (допускаю первым параметром не HANDLE объекта а ID сообщения. Но вариант с объектом мне больше нравится), а надо проверить: содержит ли его подпись ключ.

Дальше остаются только детали, требуемые при реализации. Концепция понятна.

Сообщение отредактировано: rcz - 23.09.03, 19:34

[nvm]

Цитата rcz, 23.09.03, 22:16:41

Не согласен.
Это должно быть.
1) Рассмотрим к примеру хотя бы частые обращения к записи. Постоянные проверки ни к чему.

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

Цитата

2) Архитектуру это не уходшит. Даже наоборот.
3) Не все есть файловые системы. Большинству объектов не понадобятся проверки при каждом вызове.

ИМХО, это архитектуру испортит фатально..
Но, чтобы не спорить голословно, опишите для иллюстрации простейший пример: есть объект с ключом root\x, к которому все другие объекты должны иметь доступ без ограничений.
По моей схеме в этой ситуации вообще ничего делать не нужно.
А в Вашей это как реализовать технически?

Цитата

Хэндлы вадает ОС. Она их всегда проверяет.

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

Цитата

Таблицу внутренних хэндлов спокойно можно разделить между процессами или держать в адресном пространстве процесса. Надо избежать того, что внутренние объекты давали всей системе хэндлы из одного адресного пространства.

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

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

Цитата

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

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

[rcz]

Цитата

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

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

Цитата

Произвольное число ключей в подписи - это гибче, но сложнее в реализации. Но вопрос не слишком принципиальный.

    Сильно не усложняет это уж точно.

Цитата

>Не согласен.
>Это должно быть.  
>1) Рассмотрим к примеру хотя бы частые обращения к записи. Постоянные проверки ни к чему.
Тогда все равно придется проверять хотя бы обратный адрес, чтобы понять, от кого запрос. Проверка подписи - то же самое по трудоемкости, но убивает двух зайцев.

      Обратный адрес смотреть будут в любом случае.  Подпись ведь даже не дает обратный адрес

Цитата

>2) Архитектуру это не уходшит. Даже наоборот.
>3) Не все есть файловые системы. Большинству объектов не понадобятся проверки при каждом вызове.
ИМХО, это архитектуру испортит фатально..

Но, чтобы не спорить голословно, опишите для иллюстрации простейший пример: есть объект с ключом root\x, к которому все другие объекты должны иметь доступ без ограничений.
По моей схеме в этой ситуации вообще ничего делать не нужно.
А в Вашей это как реализовать технически?

Только введением фиктивного ключа. (Т.е. существует ключ,олицетворяющий все объекты. Его может потребовать себе в ACL ). Это несложно.
Но не будет объектов, к которым разрешен доступ всем. IMHO так правильней.

Сообщение отредактировано: rcz - 23.09.03, 20:39

[Kostas]

есть тестовая версия?

[nvm]

Цитата rcz, 24.09.03, 00:35:48

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

Но локальность с защитой не связана...

Цитата

Обратный адрес смотреть будут в любом случае.  Подпись ведь даже не дает обратный адрес

Дело в том, что есть еще одна любопытная идея: позволить отправителю вписывать произвольный обратный адрес.. Но идея спорная..
А обратный адрес смотреть как раз не всегда необходимо (может, даже чаще не нужно) - ведь есть reply.
В большинстве случаев обратный адрес получателю "ничего не говорит" - с какой стати он будет "знать" отправителя?!

Цитата

Только введением фиктивного ключа. (Т.е. существует ключ,олицетворяющий все объекты. Его может потребовать себе в ACL ). Это несложно.
Но не будет объектов, к которым разрешен доступ всем. IMHO так правильней.

В любом случае, будут объекты, к которым доступ разрешен ПОЧТИ всем - это та же файловая система. Но к реестру уж точно доступ нужен абсолютно всем!

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

В Вашей схеме, единственный способ  - это породить все такие (публичные) объекты от одного ключа, например, ...\public. А сам этот ключ прописывать в ACL ко всем без исключения объектам.
Это еще терпимо - всего один лишний ключ, по сравнению с моим вариантом.
Только пример можно усложнять: предположим, что к некоторому объекту должны иметь доступ все, кроме одного. Такой объект уже не породишь от public - придется его ключ вписывать в ACL всем объектам системы, кроме одного.

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

[nvm]

Цитата Kostas, 24.09.03, 16:55:21

есть тестовая версия?

Нету.. ;D
Главное - придумать идеальную архитектуру, а реализовать при достаточном упорстве всегда можно..

[rcz]

[qoute]Дело в том, что есть еще одна любопытная идея: позволить отправителю вписывать произвольный обратный адрес.. Но идея спорная.. [/quote]
Очень спорная. В данном случае предложу вообще отказаться от этого поля (ведь ему даже доверять не надо).

Цитата

А обратный адрес смотреть как раз не всегда необходимо (может, даже чаще не нужно) - ведь есть reply.
В большинстве случаев обратный адрес получателю "ничего не говорит" - с какой стати он будет "знать" отправителя?!

При reply оно и будет смотреться.

Цитата

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

Допустим ключ равный NULL (хэндл имеет указатель на ключ=NULL). В обычных объектах его содержать не будут. А те кто разрешают доступ всем...

Цитата

В Вашей схеме, единственный способ  - это породить все такие (публичные) объекты от одного ключа, например, ...\public. А сам этот ключ прописывать в ACL ко всем без исключения объектам.
Это еще терпимо - всего один лишний ключ, по сравнению с моим вариантом.
Только пример можно усложнять: предположим, что к некоторому объекту должны иметь доступ все, кроме одного. Такой объект уже не породишь от public - придется его ключ вписывать в ACL всем объектам системы, кроме одного.

Недавно выступая за ACL требовали, что будут содержать все ключи.
Но есть выход в данных случаях. Ввести дополнительный список (гибкость улучшится) DCL - список запрещенных объектов.

Так даже будет лучше. Можно регулировать тех,кто разрешен, тех кто запрещен. Ну и главное правило - "кто не разрешен - тот запрещен".

Цитата

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

Ну что ж . Приходим к capabilities.

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

Цитата

Главное - придумать идеальную архитектуру

Идеального ничего нет. Во всем хорошем есть что-то плохое.

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

[nvm]

Цитата rcz, 24.09.03, 17:39:06

При reply оно и будет смотреться.

Так ядром же, а не программой - то есть получателю не нужно для ответа создавать хэндл отправителя.

Цитата

Допустим ключ равный NULL (хэндл имеет указатель на ключ=NULL). В обычных объектах его содержать не будут. А те кто разрешают доступ всем...

Идея понятна.
..Прошу прощения, я было понял, что под ACL Вы понимаете capacities - то есть список ключей, к которым объект имеет доступ...

Цитата

Недавно выступая за ACL требовали, что будут содержать все ключи.
Но есть выход в данных случаях. Ввести дополнительный список (гибкость улучшится) DCL - список запрещенных объектов.

А кстати, кто за ACL выступал ???
Как я вижу, вреда от нее нет.. но польза все же сомнительна: вводить целую таблицу и специальные функции для работы с ней - и все только ради того, чтобы избежать одного syscall-а, цена которого по сравнению со средней ценой передачи сообщения совсем невелика.
Главное, что достаточной гибкости это все равно не дает: контрпримеры файловой системы и реестра, менеджеры которых в ACL будут содержать NULL - а это очень существенные компоненты.

Поскольку ACL - средство в любом случае сугубо техническое, и не влияющее на архитектуру (в целом), предлагаю по крайней мере для начала обойтись без нее (тем более без DCL). Пусть объекты сами контролируют к себе доступ. А если после испытаний будет очевидна полезность ACL - ее всегда можно добавить (я подозреваю, что ядро вовсе не раз придется менять вплоть до переписывания с нуля).

Цитата

Ну что ж . Приходим к capabilities.

А вот этого не надо..

Цитата

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

А то, что я предлагаю, сочетает и то, и то "в одном флаконе".

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

[nvm]

Тут один вопрос озадачивает: как вести отладку ОС ?
Не представляю, как работать без дебаггера. А на "голой" машине??

Может, сделать модельный вариант прям под виндами?

Или вообще написать интерпретатор кода. То есть программу, которая бы полностью имитировала процессор (и среду).
Есть, конечно, VMWare, но оно ведь не дает отлаживать..

[rcz]

Повторяюсь.
1)Систему это совсем не осложнит.

Цитата

Главное, что достаточной гибкости это все равно не дает: контрпримеры файловой системы и реестра, менеджеры которых в ACL будут содержать NULL - а это очень существенные компоненты.

2)В серьезной защите не должно быть объектов с допуском всех.

Цитата

Поскольку ACL - средство в любом случае сугубо техническое, и не влияющее на архитектуру (в целом), предлагаю по крайней мере для начала обойтись без нее (тем более без DCL). Пусть объекты сами контролируют к себе доступ. А если после испытаний будет очевидна полезность ACL - ее всегда можно добавить (я подозреваю, что ядро вовсе не раз придется менять вплоть до переписывания с нуля).

Думаю наоборот. Сначала реализуется ведь ядро. И добавление ACL не сложно. DCL - решат эксперименты.  Они появятся при реализации самой структуры объекта.
А проверка на уровне отдельных объектов - это уже при реализации этих объектов.

Но это детали, определяемые при подробном рассмотрении объектов, реализации.

3) Права roota меньше прав системы (если мы хотим претендавать на серьезную защиту).

Цитата

(я подозреваю, что ядро вовсе не раз придется менять вплоть до переписывания с нуля).

Чтоб этого не было, мы и должны утвердить спецификацию и архитектуру.

Цитата

Пусть объекты сами контролируют к себе доступ.

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

Итак. Что готово в архитектупе (обсудили)
- ключи
- объкекты.
- драйвера
- межмодульное взаимодействие - сообщения
- суть защиты объектов

[rcz]

Цитата

Тут один вопрос озадачивает: как вести отладку ОС ?
Не представляю, как работать без дебаггера. А на "голой" машине??

Очень хороший вопрос. Можно сбрасывать дампы памяти и регистры,  и в них разбираться.
(этим можно смотреть самый низкий уровень и загрузку. Когда нет ОС)

Цитата

Может, сделать модельный вариант прям под виндами?

ХМ. Можно попробовать. Отлаживать саму ОС. Но главное, чтобы потом не было проблем с переносом. А они могут быть.

Цитата

Или вообще написать интерпретатор кода. То есть программу, которая бы полностью имитировала процессор (и среду).
Есть, конечно, VMWare, но оно ведь не дает отлаживать..

На написание этого уйдет дольше времени, чем на саму ОС. (Всегда хотел создать эмулирующий отладчик, но не знал с чего начать). Можно взять bochs - эмулятр, но OpenSource. Долго придется разбираться, но может оказаться полезным.

Сообщение отредактировано: rcz - 24.09.03, 20:01

[rcz]

Придется еще писать отладчик под нашу ось.

[nvm]

По объектам обсуждения толком не было, а тем более, согласованности.

Подход из Unix - когда потоки и процессы примерно одно и то же - мне категорически не нравится. Это, ИМХО, на сегодня подход не только морально-устарелый, но и морально-разложившийся  ;D
И он не соответствует концепции объектности.

Свои соображения (с существенным заимствованием из KeyKOS) я уже привел в спецификации. Поясню основные идеи.

- Процесс - это НЕ объект. Это не более, чем адресное пространство (задача в "понимании" ЦП), пространство имен и "носитель" разрешений (права объектов - это права процесса).
- Объект - это точка входа в пространстве процесса, с ассоциированным с ней уникальным ключом. Все точки входа должны иметь связанный ключ; ключ может ассоциироваться ТОЛЬКО с точкой входа.
- Точка входа - адрес функции обработки сообщений (единственной в объекте).

Запуск потока производится исключительно сообщениями (других средств нет).
Процесс может существовать, не имея ни одного потока.

Список любых хэндлов и таблица Sign хранятся в дескрипторе процесса. Таблицу ACL придется поместить в дескриптор объекта (а без нее этот дескриптор был бы совсем небольшим).