Есть ли когда-нибудь преимущество отладки в пользовательском режиме перед отладкой в ​​режиме ядра?

Насколько я понимаю, на высоком уровне отладка в пользовательском режиме предоставляет вам доступ к частному виртуальному адресу процесса. Сеанс отладки ограничен этим процессом, и он не может перезаписывать или изменять виртуальное адресное пространство / данные другого процесса.

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

Исходя из этого, я прихожу к выводу, что отладка в режиме ядра кажется более надежной, чем отладка в пользовательском режиме. У меня возникает вопрос: есть ли время, когда доступны оба варианта режима отладки, когда имеет смысл выбрать пользовательский режим вместо более надежного режима ядра?

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


person mattkgross    schedule 07.10.2015    source источник


Ответы (1)


Следующее в основном относится к фону Windows, но я думаю, это должно подойти и для Linux. Концепции не такие уж и разные.

Сначала некоторые встроенные ответы

Насколько я понимаю, на высоком уровне отладка в пользовательском режиме предоставляет вам доступ к частному виртуальному адресу процесса.

Правильный.

Сеанс отладки ограничен этим процессом

Нет. Вы можете подключиться к нескольким процессам одновременно, например с помощью команды WinDbg _1 _ / _ 2_.

и он не может перезаписывать или изменять виртуальное адресное пространство / данные другого процесса.

Нет. Вы можете изменить память, например с помощью команды ed WinDbg.

Насколько я понимаю, отладка в режиме ядра обеспечивает доступ к другим драйверам и процессам ядра, которым требуется полный доступ к множеству ресурсов,

Правильный.

в дополнение к исходному адресному пространству процесса.

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

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

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

У меня возникает вопрос: бывает ли время, когда доступны оба варианта режима отладки, что имеет смысл выбирать пользовательский режим вместо более надежного режима ядра?

Если вы отлаживаете только приложение и никакие драйверы не задействованы, я предпочитаю отладку в пользовательском режиме.

ИМХО, отладка в режиме ядра не шустрее, а хрупче - действительно можно все сломать на самом нижнем уровне. Отладка в пользовательском режиме обеспечивает типичную защиту от сбоев ОС.

Я просто замечаю, что многие люди стараются избегать отладки ядра.

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

Я не совсем уверен, почему, так как он кажется более надежным.

Что ж, действительно можно все взорвать в режиме ядра.

Отладка в пользовательском режиме

Отладка в пользовательском режиме используется по умолчанию в любой среде IDE. Интеграция обычно хорошая, в некоторых IDE она кажется вполне естественной.

Во время отладки в пользовательском режиме все просто. Если вы обращаетесь к памяти, выгружаемой на диск, ОС все еще работает и просто загружает ее, чтобы вы могли читать и записывать ее.

У вас есть доступ ко всему, что вы знаете из разработки приложений. Есть цепочки, и вы можете приостановить или возобновить их. Знаний, полученных вами при разработке приложений, будет достаточно для работы с отладчиком.

Вы можете устанавливать точки останова и проверять переменные (если у вас есть правильные символы).

Некоторые виды отладки доступны только в пользовательском режиме. Например. расширение SOS для WinDbg для отладки приложения .NET работает только в пользовательском режиме.

Отладка ядра

Отладка ядра довольно сложна. Обычно вы не можете просто выполнить локальную отладку ядра - если вы остановитесь где-нибудь в ядре, как вы управляете отладчиком? Система просто зависнет. Итак, для отладки ядра вам понадобится 2 ПК (или виртуальные ПК).

Во время отладки в режиме ядра все довольно сложно. Пока вы находитесь внутри приложения, через миллисекунду происходит какое-то прерывание, которое делает что-то совершенно другое. У вас есть не только потоки, вам также необходимо иметь дело со стеками вызовов, которые находятся за пределами вашего приложения, вы увидите содержимое регистров ЦП, указатели инструкций и т. Д. Это все вещи, о которых «нормальный» разработчик приложений не хочет заботиться.

У вас есть доступ не только ко всему, что вы реализовали. У вас также есть доступ ко всему, что разработали Microsoft, Intel, NVidia и многие другие компании.

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

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

Вывод

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

И, конечно же, специалисты по безопасности и взломщики хотят отладки в режиме ядра, потому что им нужны привилегии.

person Thomas Weller    schedule 07.10.2015
comment
Красиво выложен. Спасибо. - person mattkgross; 08.10.2015