Как отследить исполнение CPUID

Всем привет.
Существует ли способ отследить исполнение инструкции CPUID ?
Может в MSR есть биты какие для запрета её исполнения.
Использовать трассировку, полную эмуляцию всего кода и микрокод патчить не подходит.
Какие у кого мысли есть ?

 

Можно задействовать технологии виртуализации - AMDшная SVM позволяет перехватывать CPUID, Intelовские возможности не смотрел. Но это не пойдёт на старых процессорах. Без виртуализации и трассировки/эмуляции - afaik никак.

 

Нужно именно для интел(P4).

 

Clerk
Какие то последние модели пня 4 уже снабжались vt-x. Если поддержки аппаратной в проце нет, тогда только борщ. т.е. полный эмулятор.

 

k3internal
> vt-x
Где в манах об этом почитать можно, может у меня это тоже есть надеюсь ?

 

Трёхтомник интела, том 3, главы 19-27. Проверка на поддерживаемость: cpuid.1:ecx.vmx[bit 5] = 1.

 

Спасибо.

 

FEATURE_VMX equ 100000b ;VMX Virtual Machine Extensions The processor supports Intel® Virtualization Technology.
Сброшен, мой проц это не поддерживает.

 

Clerk
ну тагда песец. пакупать тебе новыйпроц.новую мать... бп..

 

k3internal
ИБП полкиловатный, думаю достаточно, мама тоже норм, вот проц кривой немного.
Может есть недокументированые MSR, где этим можно управлять, наверно единственное решение.

 

Получилось изменить результат, кот возвращается в EBX, ECX, EDX при EAX = 0. Вместо GenuineIntel - моя строка. НО это только на тех процах, где есть VT-x( все последние + Pentium D 920-960)

 

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

 

Clerk
Посмотри в сторону Рекомпиляции. На кряклабе выкладывали исходники vx_dll.
h__p://cracklab.ru/f/index.php?action=vthread&forum=6&topic=11513

 

PaCHER
Ахаха угарал от смеха как прочитал этот топик на кряклабе.

 

Ну попробуй пересобрать self/cross -modifying код.

 

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

 

Не понял, что ты имеешь в виду под "всеобщим заблуждением" ? Может оно не всеобщее, а твое собственное ?

 

Это не моё, предыдущий пост это обьясняет. Каждый кто был спрошен утверждали - имеет место быть замедление исполнения кода при трассировке. Это не так.

 

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

 

Ежу понятно, что замедление есть в любом случае, т.к. вместо единиц-долей такта на выполнение каждой инструкции при трассировке тратится как минимум десятки-сотни-тысячи тактов процессора. Поэтому тут вопрос только в том, чем и как измерять время выполнения кода. "Предыдущий пост это объясняет" только для замера больших интервалов, на которых сказывается планирование. А если натыкать rdtsc или QueryPerf.. через каждые 10-100 инструкций критичного участка кода, то никакой запрет планирования тут "время не остановит". Остановить его может перехват rdtsc, но вот что дальше делать с этим перехватом - большой вопрос, т.к. тупой сброс или установка фикс.дельты как в OllyAdvanced, Phantom и т.п. это чистый наивняк, который палится на первой же ловушке

PS: Неоценимый вклад в дело борьбы с rdtsc внесли интелы, со своим дебильным HT, из-за которого приходится или загрублять или усложнять измерения - штоб он сдох, собака