
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[216.73.216.30] |
![]() |
|
Страницы: (21) « Первая ... 9 10 [11] 12 13 ... 20 21 ( Перейти к последнему сообщению ) |
Сообщ.
#151
,
|
|
|
В бюллетне выложены новые детали реализации ядра: приведен практически полный список функций для тестовой версии. В этом интерфейсе в значительной степени учтены высказывавшиеся здесь пожелания и использованы идеи KeyKOS.
Насчет хостинга для реализации проекта - ИМХО пока нет необходимости в сильно продвинутом. Людей немного, поэтому реально обойтись e-mail и обычным html-сайтом (а с этим проблем нет). |
Сообщ.
#152
,
|
|
|
В бюллетне?? где?
|
Сообщ.
#153
,
|
|
|
протоворечия небольшие есть
вытащил отсюда http://pascal.sources.ru/cgi-bin/forum/YaBB.cgi?board=Projects;action=display;num=1063178251#top Действия: - ключ можно создать, - уничтожить, - передать, - ключом можно владеть, - можно ассоциироваться с ключом, - на ключ можно ссылаться. Правила. Каждый ключ уникален (нельзя создать «дубликат»). Создать ключ можно только как потомка одного из ключей, уже находящихся во владении. Исключение составляет root. Владелец ключа имеет право уничтожить всех его потомков, но не сам ключ. Владелец может передать владение любому приложению, при этом он также остается владельцем. Каждому приложению должен быть назначен идентифицирующий его ключ, который находится в его владении. При уничтожении идентифицирующего ключа приложение аварийно завершается. Ключ - единственный способ идентифицировать приложение, и единственное средство определения прав доступа. Во всех сообщениях, отправляемых приложениями, указываются ключи отправителя и получателя (выступают в роли адреса). При отправке сообщения потомку ключ отправителя может фальсифицироваться - в остальных случаях система (ядро) гарантирует его достоверность. |
Сообщ.
#154
,
|
|
|
Цитата Работа с портами. Порты считаются таким же ресурсом, как оперативная память, поэтому принцип управления сходен: процесс, первым запросивший доступ к порту, получает исключительное на него право. Некоторые драйвера, устройства используют одни порты. (вроде даже мышь и клава). Получится что-то странное. Исключительности не надо. Но порты - это ресурс с определенными требованиями. Приложение, запросившее доступ, должно иметь разрешение. |
Сообщ.
#155
,
|
|
|
Цитата x, 15.09.03, 01:39:07 протоворечия небольшие есть- ключ можно создать, - уничтожить, Владелец ключа имеет право уничтожить всех его потомков, но не сам ключ. Здесь нет противоречия - просто неполная формулировка. Ключ можно создать ТОЛЬКО как подключ ключа, находящегося во владении. Поэтому создатель его всегда может уничтожить, так как у него есть предок. А просто владелец - нет. |
Сообщ.
#156
,
|
|
|
Цитата rcz, 15.09.03, 02:59:34 Некоторые драйвера, устройства используют одни порты. (вроде даже мышь и клава). Получится что-то странное. Исключительности не надо. Но порты - это ресурс с определенными требованиями. Приложение, запросившее доступ, должно иметь разрешение. Все-таки сомнительно, чтобы разные драйвера использовали один порт одновременно - это как они будут согласовываться??? Насчет разрешений я не спорю - но в ядре разбираться с правами неуместно, для этого есть возможность при старте первым запустить системную утилиту, которая "приберет к рукам" все порты и потом сама будет их предоставлять. |
Сообщ.
#157
,
|
|
|
посмотри порты 0x60,0x64.(подобных примеров может быть много). Их использует и клавиатура, и мышь. согласовываются просто. В один порт кидают код (характеризует оборудование), во второй данные.
Хотя их обработку можно засунуть в один объект, но теряется независимость объектов и модулей. |
Сообщ.
#158
,
|
|
|
Цитата rcz, 15.09.03, 13:53:55 посмотри порты 0x60,0x64.(подобных примеров может быть много). Их использует и клавиатура, и мышь. согласовываются просто. В один порт кидают код (характеризует оборудование), во второй данные. Хотя их обработку можно засунуть в один объект, но теряется независимость объектов и модулей. Тогда идея такая. Сделать управление по тому же принципу, что и памятью. Процесс может выделить себе сектор памяти, после чего он является его владельцем. Может предоставить другому процессу в совместное пользование, а может в любое время отобрать. Так же можно сделать для портов: приложение "приватизирует" порт в собственность, но потом может предоставлять доступ к нему любому числу приложений. Но при совместном доступе к порту очень замороченной становится синхронизация: пока один драйвер кидает код, может закончиться квант и данные отправит уже другой драйвер. С прерываниями еще хуже. Так получается вовсе не независимость, а конкретная связь. Но об этом пусть болит голова у писателей драйверов. Возможность совместного доступа дается. Хотя, в подобных случаях, пожалуй, правильнее делать драйвера двух уровней: на нижнем это драйвер портов обоих устройств, а через него работают индивидуальные драйвера. |
Сообщ.
#159
,
|
|
|
Цитата nvm, 15.09.03, 18:04:16 Тогда идея такая. Сделать управление по тому же принципу, что и памятью. Процесс может выделить себе сектор памяти, после чего он является его владельцем. Может предоставить другому процессу в совместное пользование, а может в любое время отобрать. Так же можно сделать для портов: приложение "приватизирует" порт в собственность, но потом может предоставлять доступ к нему любому числу приложений. Что-то вроде наследование описателей потомками. Загрузку драйверов надо сделать тогда примерно так. RunMessage(/driver,load...) //загрузка драйвера ... RunMessage(/driver/subdriver,load...) //driver подгружает subdriver и передает ему права. Тут неизвестно какие порты нужны subdriver'у. А переписывать сам driver при появлении нового subfdriver'a - плохо. Или subdriver сам потребует порты у driver (на финальной ветке driver будет отклонять все запросы), а driver у системы. А система доверенному драйверу их обязана обеспечить. Исключительности не должно быть. Доверенный драйвер - драйвер в корне, загруженный самой системой. Но этот путь может быть очень длинным и долгим (ведь каждай запрос получается проходит через ядро) и ленивые разработчики(их много), могут отдавать все просьбы вверх и получится, что ядро даст права любому приложению. - серьезный баг. Цитата Надо ядру предоставлять сервисы синхронизации(об этом отдельно надо говорить). И некоторые части драйверов должны все ж работать в прерываниях с запрещенными прерываниями. (Часто работа с портами здесь) Но при совместном доступе к порту очень замороченной становится синхронизация: пока один драйвер кидает код, может закончиться квант и данные отправит уже другой драйвер. С прерываниями еще хуже. Так получается вовсе не независимость, а конкретная связь. (Cделать типа Bottom и Top Halves как в линухах) Цитата Но об этом пусть болит голова у писателей драйверов.Возможность совместного доступа дается. Несогласен с таким подходом. Чем легче буде писать разработчикам прикладного ПО - тем лучше ОСь разовьется. Цитата Иерархия может быть очень страшной. Хотя, в подобных случаях, пожалуй, правильнее делать драйвера двух уровней: на нижнем это драйвер портов обоих устройств, а через него работают индивидуальные драйвера. Не очень красивая архитектура в итоге получается. Склоняюсь к отправлению всех драйверов на ring1. Дать всем порты и отделить от юзерского режима. Юзерам запретить доступ к портам. Загрузка происходит тем же способом, что писал выше, но драйвер сам решает на какой уровень кидать загружаемое(будет ли это subdriver'ом или пртложением). |
Сообщ.
#160
,
|
|
|
Цитата rcz, 15.09.03, 19:13:41 Что-то вроде наследование описателей потомками. Загрузку драйверов надо сделать тогда примерно так. RunMessage(/driver/subdriver,load...) //driver подгружает subdriver и передает ему права. Передача прав - отдельный системный вызов.. Цитата Или subdriver сам потребует порты у driver (на финальной ветке driver будет отклонять все запросы), а driver у системы. А система доверенному драйверу их обязана обеспечить. Исключительности не должно быть. Доверенный драйвер - драйвер в корне, загруженный самой системой. Но этот путь может быть очень длинным и долгим (ведь каждай запрос получается проходит через ядро) и ленивые разработчики(их много), могут отдавать все просьбы вверх и получится, что ядро даст права любому приложению. - серьезный баг. Ядро даст права не любому приложению - а ТОЛЬКО тому, кто ПЕРВЫЙ их попросит! А первым всегда будет менеджер драйверов (МД). Дискуссия подсказала идею о необходимости двух уровней доступа к портам: владение и пользование (то же и для памяти). Права на владение всегда исключительны - если система дала их кому-то, то больше никому не предоставит (пака владелец не завершит работу или явно от них не откажется). Права на доступ могут иметь одновременно многие, но предоставляются они ТОЛЬКО владельцем. Теперь права на порты предоставляет только МД. Какие порты какому драйверу можно предоставлять - указывает админ. при установке драйвера (установка идет через МД). И это только один вариант из возможных, причем вполне надежный. Пользователь (админ.) вправе писать свои варианты МД. Цитата Надо ядру предоставлять сервисы синхронизации(об этом отдельно надо говорить). Можно сделать для начала простейший семафор, а над продвинутыми средствами думать потом - сразу все равно все не предусмотреть, поэтому стоит выбрать для первой реализации самый минимум. Цитата Не очень красивая архитектура в итоге получается. Так я и предлагаю сделать красиво: единообразие, минимум правил. Это только кажется, что архитектура небезопасна - потому что она очень непривычная. Посмотрите внимательнее - нет там дыр! Цитата Склоняюсь к отправлению всех драйверов на ring1. Дать всем порты и отделить от юзерского режима. Юзерам запретить доступ к портам. Загрузка происходит тем же способом, что писал выше, но драйвер сам решает на какой уровень кидать загружаемое(будет ли это subdriver'ом или пртложением). Нет проблем. Такая возможность уже предусмотрена (как вариант) в выложенном описании ядра. Запускается МД, который присваивает себе все порты и больше ничего не делает - порты после этого в непривилегированном режиме недоступны никому (больше). Зато драйверам дается ключ root или ring1, позволяющий включить нужный уровень привилегий. Получается просто, что можно действовать и так, и так - ИМХО, разумный компромисс (..конечно, утверждение отчасти лукавое ;) - так как переключение режима в любом случае необходимо, а функции управления портами - только в одном варианте... но ведь и возможности они дают беспрецедентные : ![]() |
Сообщ.
#161
,
|
|
|
Что-то народ в значительной массе "рассеялся"..
То ли заметка модератора в бюллетне слишком "предостерегающая" : ![]() Но это и к лучшему: у кого празный интерес - отсеются сразу ![]() |
Сообщ.
#162
,
|
|
|
Цитата очень надеюсь, что не в ручную. Админ не должен знать архитектуру драйверов. Но это не важно.Теперь права на порты предоставляет только МД. Какие порты какому драйверу можно предоставлять - указывает админ. при установке драйвера (установка идет через МД). До компромиса далеко... ![]() Лучше сделать так. Админ устанавливает драйвера (установит плохие - его проблемы. Но защита по потрам от этого в любом случае не спасет). Драйвер прописывается в правильное место иерархии драйверов. Доступ к прерываниям регулируется просто. А владение портами как? Т.е. МД - итак один в системе. До сих пор не вижу причин запрещать порты всем драйверам (они будут доступны только на RING 0-1); Ведь запрет портов драйверам(их устанавливал админ) надежности вообще не прибавляет. Только лишнии проблемы и ухудшение архитектуры. Или приведите доводы, жизненные примеры, почему вы считаете, что драйверам их надо запретить. Случайно (как к неправильной памяти) к ним не обратишься. Вирусы... это же админ устанавливает, при защите по портам админ то же самое сделает. В системах WIN, *nix и т.п. главные проблемы драйверов не из-за обращения к портам. У драйверов - главное отправить иж в разные адресные пространства. Защиты памяти достаточно. Цитата Что-то народ в значительной массе "рассеялся".. То ли заметка модератора в бюллетне слишком "предостерегающая" ... Но это и к лучшему: у кого празный интерес - отсеются сразу Тут и не было народа(3-4 чел), которые до сих пор здесь. Сейчас "затишье перед бурей" переход на 2-ю стадию. Обдумываем архитектуру. Вцелом достаточно хорошая. остаются только детали, оптимизация, реализация. |
Сообщ.
#163
,
|
|
|
Цитата rcz, 16.09.03, 16:12:35 Лучше сделать так. Админ устанавливает драйвера (установит плохие - его проблемы. Но защита по потрам от этого в любом случае не спасет). Защита по портам гарантирует, что проблемы с драйвером коснутся только устройства, для которого он устанавливался - а все остальное будет работать. Цитата А владение портами как? Т.е. МД - итак один в системе. До сих пор не вижу причин запрещать порты всем драйверам (они будут доступны только на RING 0-1); Ведь запрет портов драйверам(их устанавливал админ) надежности вообще не прибавляет. Только лишнии проблемы и ухудшение архитектуры. Или приведите доводы, жизненные примеры, почему вы считаете, что драйверам их надо запретить. Случайно (как к неправильной памяти) к ним не обратишься. Вот это как раз запросто. Драйвер может вообще ошибиться в выборе портов. Можно вообще по ошибке установить два драйвера одного устройства. А предложенная защита портов все эти возможности пресекает в корне. Насчет архитектуры, есть разные критерии, что лучше. ИМХО, обойтись одним типом приложений, вместо двух - это большой плюс. Также, если систему невозможно "свалить" или подвесить даже вирусом в драйвере - если только это не драйвер системного диска - это еще большой плюс. Цитата Вирусы... это же админ устанавливает, при защите по портам админ то же самое сделает. Если драйвер имеет доступ ко всем портам, то вирус в нем сможет обратиться к диску. А при защите портов - сможет глючить только свое устройство. Кроме того, на платформах, где всего два режима процессора, драйвера, работающие в привилегированном режиме, получат доступ и к управлению памятью. |
Сообщ.
#164
,
|
|
|
Цитата Вот это как раз запросто. Драйвер может вообще ошибиться в выборе портов. Можно вообще по ошибке установить два драйвера одного устройства. А предложенная защита портов все эти возможности пресекает в корне. Т.к. решили, что пользоваться портами МД будет позволять всем, то это не решение проблемы. А ручное вбивание разрешенных портов администратором(бедный администратор. Он же не будет помнить все порты всех устройств) может так же привести к установке драйвера одного и того же устройства. Эту проблему надо решать другим способом (В Win такого у меня еще никогода не было. В Lin - только если очень постараться, то можно. Но это уже умышленная ошибка). Цитата Если драйвер имеет доступ ко всем портам, то вирус в нем сможет обратиться к диску. А при защите портов - сможет глючить только свое устройство. В нынешних системах вирусы попадают в RING0 2-мя способами. Используют дыру, выходят без оборудования в RING0 и устанавливают левый драйвер. Рассмотрим нашу ОСь как устойчивую к этой атаке (по рассмотрении будет понятно, делать ли такое нам с портами). В первом случае - если будет быра и вирь выйдет в RING0 - он откроет сам себе доступ к оборудованию Во втором - если ему удастся запустить драйвер, он его может подделать подо что угодно(HDD). Исключительность по портам невозможна. и Тоже что-то испортит. Поэтому надо не усложнять жизнь добрым программерам, а закрывать эти дыры. Первую - это уже реализация. Вторая - продуманные правила установки драйверов(только администратором и т.п.) и записи на диск. (Именно учитывая это получилось, что в *nix вирусы не приживаются). |
Сообщ.
#165
,
|
|
|
Цитата rcz, 17.09.03, 00:41:27 Т.к. решили, что пользоваться портами МД будет позволять всем, то это не решение проблемы. А ручное вбивание разрешенных портов администратором(бедный администратор. Он же не будет помнить все порты всех устройств) может так же привести к установке драйвера одного и того же устройства. Это кто и когда решил??? Во-первых, МД - вовсе не обязательный компонент системы. Я утверждаю, что и без него система будет 100\% защищенной. Это только если админа не устраивает стандартная политика установки драйверов - тогда он САМ пишет МД и реализует такую политику, какую заблагорассудится. Конечно, какой-нибудь стандартный вариант МД в дистрибутив включать желательно - но скорее ради доп. сервиса, напр. мониторинга драйверов, или смены драйвера в процессе работы системы (кстати, какой *nix может похвастаться сменой драйвера системного диска без перезагрузки? 8)). Во-вторых, установить один драйвер дважды или два драйвера на одни порты (если это не предусмотрено схемой их работы) невозможно в принципе. Я же сделал уточнение, что ядро "раздает" "всем желающим" только ИСКЛЮЧИТЕЛЬНЫЕ права на владение портом. Уже это практически гарантирует безопасность, так как к моменту запуска первой пользовательской программы (в т. ч. ПП) все порты будут "разобраны" драйверами, которые запускаются непрерываемым autoexec-ом. Поэтому МД нужен разве что для подстраховки (проверить, все ли драйвера нормально запустились). Теперь если двум драйверам нужен один порт. Драйвер, запустившийся первым, получает исключительное право владения (у него нет выбора - более "скромных" прав ядро не раздает). Второй драйвер вынужден обращаться уже не к ядру (то его "пошлет", будь он хоть root-ом), а к первому драйверу, который предоставляет право пользования (без права распоряжаться). право пользования не исключительно, и его могут иметь сколько угодно приложений. Естественно, в такой схеме драйвера, работающие с одним портом, должны уметь "общаться" - по-минимуму, знать ключи друг друга. Но взаимодействие драйверов в такой ситуации - неизбежность в любой архитектуре. Цитата Во втором - если ему удастся запустить драйвер, он его может подделать подо что угодно(HDD). Исключительность по портам невозможна. Вот потому я и настоятельно рекомендую все драйвера, какие возможно, запускать в пользовательском режиме привилегий. Об исключительности см. выше. Если вирус запустит поддельный драйвер - никакого доступа тот все равно не получит, просто потому что все порты уже "приватизированы" настоящими драйверами. Цитата Поэтому надо не усложнять жизнь добрым программерам, а закрывать эти дыры. Первую - это уже реализация. Вторая - продуманные правила установки драйверов(только администратором и т.п.) и записи на диск. (Именно учитывая это получилось, что в *nix вирусы не приживаются). Для того и предлагается привилегированный режим ограничить рамками ядра, размером 30 кб, которое можно "вычистить" на 100\%. В вашем варианте, вирус в драйвере всегда поимеет систему - никакие правила не спасут. А у *nix-е вири не живут еще и (может, в основном) потому, что чайники под ним не работают... |