[NT] Деление на ядро и исполнительную систему - довольно условное [upd2]12.07.04 13:53 Число просмотров: 1906 Автор: amirul <Serge> Статус: The Elderman Отредактировано 12.07.04 14:27 Количество правок: 3
Гораздо более значимым является деление на модули (каждый из которых имеет свой префикс) или как их еще называть (в аглицком называются менеджерами).
> Например я хочу открыть файл на чтение, то куда идет > запрос? Вначале в исполнительную часть и там вызывается > объект исполнительной системы, а потом уже он вызывает > объект ядра – файл, который уже работает с физическим > файлам. Когда ты делаешь NtCreateFile (native подсистема) он сразу уходит в менеджер ввода/вывода IoCreateFile, после валидирования аргументов настройки кучи параметров IoCreateFile уходит в ObOpenObjectByName, который в свою очередь уходит в ObpLookupObject (обе функции - части менеджера объектов). Если объект-файл уже есть, то он возвращается, если нет - то создается новый (объект-файл связан с объектом-устройством, которому будут посылаться все IRP для обращения к этому файлу, например \Device\HarddiskVolume1 и т.д.). Когда указатель на объект-файл найден, для него создается хендл в таблице вызывающего процесса ObpCreateHandle, который опять таки уходит в другой модуль - ExCreateHandle
По ходу работы менеджера объектов выполняется куча вызовов монитора безопасноти (Reference Security Monitor) для проверки имеет ли ACCESS_TOKEN вызывающего процесса права на доступ к файлу с данным SECURITY_DESCRIPTOR-ом.
> И какие запросы доходят только до исполнительной системы и > не доходят до ядра, а какие объекты создаются напрямую в > ядре, не создаваясь в исполнительной части(что с > синхронизацией вроде)??? > И чем отличается представление того же файла в файловой > системе, исполнительной системе и в ядре???? Представление файла в файловой системе - ее личное дело. Она может хранить его как в памяти, так и на диске в любом виде, а исполнительная система работает с объектом FILE_OBJECT (который описан в DDK), а в ядре вообще нет файлов.
------------------
Немного поправлюсь. Деление на исполнительную систему и ядро не условное. Просто часть менеджеров относится к исполнительной системе, а часть - к ядру. Объекты, которые есть и в ядре и в исполнительной системе (например процесс, поток и пр.) создаются по аналогии с ООП-шным наследованием.
Обрати внимание, что в начали executive процесса лежит НЕ указатель на kernel-процесс, а сам kernel-процесс. Таким образом любой указатель на executive процесс будет одновременно и указателем на kernel.
У ntoskernel.exe есть 2 уровня исполнительная система на верхнем и само ядро на нижнем. В них реализованы разные функции и объекты. Так вот вопрос чем отличаются объекты ядра от объектов исполнительной системы? Как они друг от друга зависят, и как проходит какой-либо запрос от пользователя?
Например я хочу открыть файл на чтение, то куда идет запрос? Вначале в исполнительную часть и там вызывается объект исполнительной системы, а потом уже он вызывает объект ядра – файл, который уже работает с физическим файлам.
И какие запросы доходят только до исполнительной системы и не доходят до ядра, а какие объекты создаются напрямую в ядре, не создаваясь в исполнительной части(что с синхронизацией вроде)???
И чем отличается представление того же файла в файловой системе, исполнительной системе и в ядре????
[NT] Деление на ядро и исполнительную систему - довольно условное [upd2]12.07.04 13:53 Автор: amirul <Serge> Статус: The Elderman Отредактировано 12.07.04 14:27 Количество правок: 3
Гораздо более значимым является деление на модули (каждый из которых имеет свой префикс) или как их еще называть (в аглицком называются менеджерами).
> Например я хочу открыть файл на чтение, то куда идет > запрос? Вначале в исполнительную часть и там вызывается > объект исполнительной системы, а потом уже он вызывает > объект ядра – файл, который уже работает с физическим > файлам. Когда ты делаешь NtCreateFile (native подсистема) он сразу уходит в менеджер ввода/вывода IoCreateFile, после валидирования аргументов настройки кучи параметров IoCreateFile уходит в ObOpenObjectByName, который в свою очередь уходит в ObpLookupObject (обе функции - части менеджера объектов). Если объект-файл уже есть, то он возвращается, если нет - то создается новый (объект-файл связан с объектом-устройством, которому будут посылаться все IRP для обращения к этому файлу, например \Device\HarddiskVolume1 и т.д.). Когда указатель на объект-файл найден, для него создается хендл в таблице вызывающего процесса ObpCreateHandle, который опять таки уходит в другой модуль - ExCreateHandle
По ходу работы менеджера объектов выполняется куча вызовов монитора безопасноти (Reference Security Monitor) для проверки имеет ли ACCESS_TOKEN вызывающего процесса права на доступ к файлу с данным SECURITY_DESCRIPTOR-ом.
> И какие запросы доходят только до исполнительной системы и > не доходят до ядра, а какие объекты создаются напрямую в > ядре, не создаваясь в исполнительной части(что с > синхронизацией вроде)??? > И чем отличается представление того же файла в файловой > системе, исполнительной системе и в ядре???? Представление файла в файловой системе - ее личное дело. Она может хранить его как в памяти, так и на диске в любом виде, а исполнительная система работает с объектом FILE_OBJECT (который описан в DDK), а в ядре вообще нет файлов.
------------------
Немного поправлюсь. Деление на исполнительную систему и ядро не условное. Просто часть менеджеров относится к исполнительной системе, а часть - к ядру. Объекты, которые есть и в ядре и в исполнительной системе (например процесс, поток и пр.) создаются по аналогии с ООП-шным наследованием.
Обрати внимание, что в начали executive процесса лежит НЕ указатель на kernel-процесс, а сам kernel-процесс. Таким образом любой указатель на executive процесс будет одновременно и указателем на kernel.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
