Windows обрабатывает в ядре по сравнению с системой
2 ответа
A good primer for this topic would be found at: http://www.codinghorror.com/blog/archives/001029.html
As Jeff points out for the user mode memory space:
"In User mode, the executing code has no ability to directly access hardware or reference memory. Code running in user mode must delegate to system APIs to access hardware or memory. Due to the protection afforded by this sort of isolation, crashes in user mode are always recoverable. Most of the code running on your computer will execute in user mode."
So your app will have no access to the Kernel Mode memory, infact your communication with the driver is probably through IOCTLs (i.e. IRPs).
The kernel however has access to everything, including to mappings for your user mode processes. This is a one way street, user mode cannot map into kernel mode for security and stability reasons. Even through kernel mode drivers can map into user mode memory I would advise against it.
At least that's the way it was back before WDF. I am not sure of the capabilities of memory mapping with user mode drivers.
Каждый процесс имеет «контекст», который, среди прочего, содержит сопоставления виртуальных машин, относящиеся к этому процессу (обычно <2 ГБ в 32-битном режиме). Когда поток, выполняющийся в пользовательском режиме, переходит в режим ядра (например, из системного вызова или запроса ввода-вывода), тот же поток все еще выполняется в процессе с тем же контекстом. PsGetCurrentProcessId в этот момент вернет то же самое, что и GetCurrentProcessID только что в пользовательском режиме (то же самое с идентификаторами потоков).
Отображения пользовательской памяти, которые пришли с контекстом, являются остается на месте после входа в режим ядра: вы можете получить доступ к пользовательской памяти напрямую из режима ядра. Однако для этого нужно сделать особые вещи: Использование ни буферизованного, ни прямого ввода-вывода . В частности, попытка доступа к недопустимому адресу в диапазоне пользовательского пространства вызовет исключение SEH, которое необходимо перехватить, а содержимое пользовательской памяти может измениться в любое время из-за действия другого потока в этом процессе. Доступ к недопустимому адресу в диапазоне адресов ядра вызывает проверку ошибок. Поток, выполняющийся в пользовательском режиме, не может получить доступ к памяти ядра.
Адресное пространство ядра не является частью контекста процесса, поэтому оно отображается одинаково между всеми ними. Однако любое количество потоков может быть активным в режиме ядра в любое время, поэтому это не похоже на однопоточное приложение. Как правило, потоки обслуживают свои собственные системные вызовы при входе в режим ядра (в отличие от выделенных рабочих потоков ядра для обработки всех запросов).
Базовые структуры, которые сохраняют состояние потока и процесса, доступны в режиме ядра. Сопоставление виртуальной машины другого процесса лучше всего выполнять заранее из другого процесса, создавая MDL из этого процесса и отображая его в адресное пространство системы. Если вы просто хотите изменить контекст другого потока, это можно сделать полностью из пользовательского режима . Обратите внимание, что поток должен быть приостановлен, чтобы изменить его контекст без состояния гонки. Загрузка модуля в процесс из режима ядра не рекомендуется; все API-интерфейсы загрузчика предназначены для использования только в пользовательском режиме.
Каждый процессор имеет текущий IRQL , на котором он работает. Он определяет, что может прервать текущую работу процессора. Только событие с более высоким IRQL может прервать текущую активность ЦП.
PASSIVE_LEVEL- это место, где выполняется весь пользовательский код и большая часть кода ядра. Многие API ядра требуют, чтобы IRQL былPASSIVE_LEVELAPC_LEVELиспользуется для APC ядраDISPATCH_LEVELпредназначен для событий планировщика (известного как диспетчер в терминологии NT). Запуск на этом уровне не позволит вам быть вытесненным планировщиком. Обратите внимание, что на этом уровне небезопасно иметь какие-либо ошибки страницы; возможна тупиковая ситуация, когда менеджер памяти пытается получить страницы. Ядро немедленно выполнит проверку ошибок, если у него будет ошибка страницы наDISPATCH_LEVELили выше. Это означает, что вы не можете безопасно получить доступ к выгружаемому пулу, сегментам выгружаемого кода или любой пользовательской памяти, которая не была заблокирована (например, MDL).- Выше этого находятся уровни, связанные с уровнями прерываний аппаратных устройств, известный как
DIRQL. - Самый высокий уровень -
HIGH_LEVEL. Ничто не может вытеснить этот уровень. Он используется ядром во время проверки ошибок для остановки системы.
Я рекомендую прочитать Планирование, контекст потока и IRQL