А сегодня вообще рабочий день-то?

The documentation for QueueUserApc states "an APC cannot be queued from a 64-bit process to a 32-bit process or vice versa."

However on Vista Ultimate x64, we can queue a user APC from a 32-bit process to a 64-bit process. In our test application the 64-bit recipient crashes, we haven’t explored why just yet, but the point is that the operation should not succeed and the 64-bit application’s APC queue should never have the APC inserted.

Is it an OS bug?

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

Однако на Vista Ultimate x64 мы можем выполнить асинхронный вызов пользовательского режима из 32-х битного процесса в 64-х битном процессе. В нашем тестовом приложении 64-х битный получатель падает и мы еще не выяснили почему, но дело в том, что операция (QueueUserApc) не должна завершаться успешно и асинхронный вызов не должен вставляться в очередь вызовов 64-х разрядного процесса.

Это баг ОС?

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

Для начала разберемся, что такое асинхронные вызовы процедур (APC). Те кто знает могут смело пропустить этот абзац. Windows NT поддерживает специальное состояние заблокированного потока – “alertable wait”. Чтобы переключиться в это состояние поток может использовать “Ex” версии “WaitFor” функций или функции асинхронного ввода-ввода. Это состояние примечательно тем, что поток может быть в любой момент разбужен, при этом управление будет передано по произвольному (заранее согласованному) адресу. Эта возможность используется ядром для уведомления приложения о завершении операции ввода-вывода. К примеру, если в NtWriteFile передан не нулевой ApcRoutine, то по завершении операции ядро вызовет ApcRoutine именно с помощью механизма асинхронных вызовов.

Функция QueueUserApc позволяет воспользоваться этим механизмом в своих корыстных целях. Эта функция ставит запрос на выполнение APC процедуры в определённом потоке. Процедура будет вызвана (возможно, вместе с другими процедурами) в контексте целевого потока, как только тот переключиться в состояние alertable wait. Небольшая, по важная тонкость заключается в том, что адрес процедуры может быть любым. Функция никак не гарантирует его правильность. Если адрес процедуры неверен, то целевой поток, скорее всего, упадет с кодом access violation. При этом поток, вызвавший QueueUserApc, продолжит работу, как ни в чем не бывало.

Далее, поскольку 32-х и 64-х битные процессы используют разную ширину адреса, то с вызовом 64-х разрядных процедур из 32-х битного кода возникают вполне понятные сложности. 32-х битный код просто не имеет возможности передать 64-х битный адрес в QueueUserApc. Передать 32-х адрес возможно, но возникают другие сложности. Например, как отличить адрес 32-х битного кода от адреса 64-х битного также расположенного ниже границы 4GB.

Полезная ссылка для тех, кто интересуется деталями: http://www.nynaeve.net/?p=202

Вернемся теперь к оригинальному вопросу. Формально, тот факт, что QueueUserApc позволяет поставить вызов в очередь потока с другой разрядностью, можно назвать ошибкой. Хотя на самом деле это скорее ошибка в документации, которая должна была бы утверждать, что “ что асинхронный вызов процедуры (APC) не следует запрашивать из 64-х битного процесса для выполнения в 32-х битном и наоборот.” Небольшая разница, но какой эффект.

Дело в том, что QueueUserApc просто не имеет возможности проверить разрядность целевого потока во всех случаях. Чтобы это было возможно процесс целевого потока должен быть доступен с уровнем доступа PROCESS_QUERY_INFORMATION или PROCESS_QUERY_LIMITED_INFORMATION. Проверить соответствие разрядности можно в ядре, но там мешает тот факт, что система как раз должна уметь вызывать 32-х битные APC из 64-х разрядного кода. В результате, разработчики Wow64 решили, что овчинка не стоит выделки, и такая проверка не была реализована. Текущая реализация этой функции такова, что вызов процедуры в потоке другой разрядного практически гарантированно приводит к падению целевого потока.

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

На снимке виден Фомальгаут B – планета, вращающаяся вокруг звезды Фомальгаут, и пояс обломков и пыли – остатки формирования планет.

Но и это еще не всё. Другая группа исследователей с помощью 8-ми метрового телескопа Gemini North 8 сфотографировала две планеты, вращающиеся вокруг другой звезды.

И наконец, 10-ти метровый Keck смог увидеть третью планету с этой же системе:

 

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

• Выравнивание типов и структур;
• Правила использования регистров процессора;
• Порядок передачи параметров;
• Точный формат кадра стека (stack frame);
• Виды функций, пролог и эпилог функций;
• Порядок обработки исключений и алгоритм «раскрутки» стека.

Чем это лучше того, что твориться в мире x86 кода? Стандартный формат кадра стека позволяет получать достоверную трассировку стека в любой момент времени, при условии, конечно, что компилятор генерирует код соответствующий соглашению о вызовах и если информация о состоянии процессора корректна. При этом абсолютно не используются символы (.pdb). Сравните это с x86, где совершенно корректный код может запросто свести с ума любой отладчик.

Далее, все функции делятся на два типа: «frame» и «leaf». К первым относится любая функция вызывающая другие функции, сохраняющая nonvolatile регистры или использующая исключения. Функции, динамически выделяющие память в стеке с помощью _alloca, также относятся к этой категории. Все остальные – это «leaf» функции. Для каждой «frame» функции компилятор генерирует её описание (function entry), где подробно описываются все действия, выполняемые в прологе функции: от выделения места в стеке до списка сохраняемых регистров вместе с их смещениями в стеке. Пример можно посмотреть, выполнив в отладчике команду “.fnent <symbol>”:

0:000> .fnent notepad!WinMain
Debugger function entry 00000000`01f48250 for:
(00000000`ff296dd4)   notepad!WinMain   |  (00000000`ff296fd0)   notepad!UpdateStatusBar
Exact matches:
    notepad!WinMain = <no type information>

BeginAddress      = 00000000`00006dd4
EndAddress        = 00000000`00006fc9
UnwindInfoAddress = 00000000`0000dcc0

Unwind info at 00000000`ff29dcc0, 14 bytes
  version 1, flags 0, prolog 14, codes 8
  frame reg 0, frame offs 0
  00: offs 14, unwind op 4, op info 6
  01: offs 12, unwind op 0, op info 0
  02: offs 14, unwind op 4, op info 5
  03: offs 11, unwind op 0, op info 0
  04: offs 14, unwind op 4, op info 3
  05: offs 10, unwind op 0, op info 0
  06: offs 14, unwind op 2, op info d
  07: offs 10, unwind op 0, op info 7

Более подробно об этом можно почитать здесь. Имея подобное описание «раскрутчик» стека может достоверно определить границы кадров функций в стеке и восстановить значение non-volatile регистров в каждом кадре в любой момент времени.

Интересна мнемоника этой команды. Суффикс «2» подразумевает, что есть еще и как минимум UD1 или UD, но ни Intel ни AMD не описывают такой инструкцию. Поиск по интернету показывает, что некоторые компиляторы поддерживают (или поддерживали) три варианта этой команды:

• UD0 (0F FF)
• UD1 или UD2B (0F B9)
• UD2 или UD2A (0F 0B)

Ни одна из этих команд не является корректной командой, но все они по-разному описывается в документации Intel и AMD. Инструкции UD0 (0F FF) соответствует пустая ячейка в таблице двухбайтных команд. Т.е. эта инструкция не определена сейчас, но может быть переопределена в будущем.

Мнемоника UD1 не упоминается в “Programmer’s Manual”, но комбинация 0F B9 указана в таблице двухбайтных инструкций как «Undefined instruction opcode» и, соответственно, она не может быть переопределена впоследствии. Кроме этого указывается, что за 0F B9 должен следовать ModRM байт, определяющий расширение этой инструкции. Впрочем, все возможные комбинации ModRM байта в сочетании с кодом инструкции 0F B9 всё равно объявлены как «Undefined instruction». Закавыка правда в том, что в примерах, найденных в интернете, за 0F B9 не следует ничего. Кому верить – не понятно.

UD2, похоже, наиболее полно описанный вариант «неопределенной инструкции». Она занимает ровно два байта, её мнемоника легализована и она прочно занимает свою ячейку в таблице двухбайтных команд.

Выполняя поток команд, процессор проверят возможность выполнения каждой инструкции, корректность её аргументов и все остальные факторы, влияющие на корректность выполнения кода. В случае если команда не может быть выполнена (деление на ноль, обращение к несуществующей странице, несоответствие уровня привилегий и т.д.), процессор генерирует исключение – вызывает один из обработчиков, зарегистрированных операционной системой в IDT (Interrupt Dispatch Table).

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

Получив контроль, обработчик исключения сохраняет остальные регистры процессора в стеке и выполняет действия, специфичные для конкретного исключения. Например, обработчик Page Fault Exception запрашивает подкачку страницы у Memory Manager. Если обработчику удалось разрешить проблему, вызвавшую генерацию исключения, обработчик восстанавливает сохраненное состояние процессора и выполняет возврат в пользовательский код (Ring 3). В противном случае, в дело вступает диспетчер исключений.

Диспетчер исключений размещает структуру CONTEXT в пользовательском стеке и копирует туда сохранённое состояние регистров из ядерного стека. Туда же сохраняется текущее состояние Floating Point регистров. Информация об исключении записывается в структуру EXCEPTION_RECORD. Далее, диспетчер подменяет адрес возврата в пользовательский код адресом диспетчера исключений пользовательского режима и выполняет возврат в Ring 3.

Windows поддерживает специальную структуру, TEB (Thread Environment Block), где хранятся локальные данные потока. Эта структура доступна из Ring 3 через сегмент FS (или GS для x64). В самом начале этой структуры хранится указатель на список вложенных блоков “__try” и соответствующих им блоков “__except” и “__finally”. Компилятор генерирует код, добавляющий элемент в этот список при входе в блок “__try” и удаляющий при выходе из блока. (Примечание: справедливо только для x86. 64-х битный код “раскручивает” стек пользуясь сгенерированным компилятором описанием кода.)

Получив управление, диспетчер исключений пользовательского режима по очереди опрашивает обработчики из списка, позволяя каждому из них обработать данное исключение. Найдя обработчик, согласившийся обработать исключение, диспетчер исключений выполняет «раскрутку» стека (Stack Unwinding) и передает управление выбранному обработчику. Этот механизм довольно детально описывался во всевозможных статьях о том, как работает SEH (Structured Exception Handling) (например здесь или здесь), так что я не буду останавливаться на этом детально. «Раскрутчик» стека отслеживает текущее состояние (указатель стека и команд, состояние регистров) в локальной копии структуры CONTEXT. По окончанию обработки исключения, состояние из структуры CONTEXT загружается в процессор, завершая обработку исключения.

И это только поверхностное описание.

Эх, накопить бы немного деньжат – в космос слетать. Или маленький остров в Тихом океане купить. :-/

Поясняю - прямой угол плоскости одной точки - это такой угол (в частности) , для которого выплняется условие равенства одного n-мерного объекта, получающегося ЕДИНСТВЕННО пересечением двух одноразмерных объектов одного порядка и оба объекта пересечения не относится к данному углу одновременно, которые выше порядка объекта угла ровно на 1 единицу, другому объекту одного с углом порядка размерности, получаемого ЕДИНСТВЕННО пересечением двух одноразмерных объектов одного порядка и оба объекта пересечения не относится к данному углу одновременно, которые выше порядка объекта угла ровно на 1 единицу и эти 2*N объектов должны быть НЕ РАВНЫ между собой (как частный вариант - все 4 объекта НЕ равны между собой).

Во как! 8-/

Update: Там еще и иллюстрация есть: