Сплайсинг в нулевом кольце на новых версиях ядра (Виста, Вин7)

Нашел откуда ноги растут? "Виснет" ведь не объяснение. Для дедлоков не вижу причин.

Естесно, я уже говорил об этом - все эксепшены забираем себе, в хэндлере выставляем TF и вперед в оригинальный хэндлер.
Про реальное железо вряд ли актуально, не вижу причин, по которым микросекунды на обработку DB# могут повлиять на работу с железом. Самое быстрое железо это local APIC, при работе с ним траблов не увидел.

 

medstrax1

Видимо обьяснение. Не хватает камню быстродействия(P4). Возможно на новых процессорах виснуть не будет. Дедлоки возникают наверно при доставке межпроцессорных прерываний. Вобще это худшее решение которое тут описали.

 

medstrax1
Один вопрос. Зачем предлагать сделать то, о чем не знаешь + доказывать свою правоту.

Есть мнение что вы не сходя с места объясните как сделать "солнечный двигатель" и на все возражения ответите фразой "вам нада - делайте. я вам подсказал, один фиг скоро квантовые двигатели придумают".

 

Хорошо, если ты грешишь на многопроцессорность - проверь на одно-процовом камне.
А лучше код в студию

 

То, что я предлагаю, я знаю много лучше большинства участников. Я предложил концепт, если есть возражения, как у клерка, - с радостью готов обсудить. Если есть чистое опровержение - буду рад узнать что-то новое. А вот на нубские реплики отвечать больше нет желания.

 

medstrax1
Коды не паблик. Темболее что всё ядро не трассируется, только части нтос. Напишите простенький трейсер - перчисляем IDT или доставляем IPI и ставим заглушку на #DB во всех IDT, в которой проверка Cs/Ss(CPL), обращение к памяти и возврат.

 

И почему нельзя трассировать все ядро?

Потому что вопервых есть достаточно большое количество кода которое синхронизировано по времени, и даже добавление 3-х лишних mov способно положить всю систему.
Во вторых дебаг механизм не идеален, и для трассировки "всего ядра" требуется много ресурсов
В третьих попробуйте протрассировать один из продвинутых пакеров хотябы чтобы догадаться до простой истины: "зае*мучае*шься трассировать".
В четвертых инструмент который был почти на это способен - SoftIce. Но он использовал много приемов помимо стандартного debug механизма винды, но и с его помощью это было не реально.
В пятых если вы считаете что вокруг вас одни нубы - задумайтесь... это полезно.
В шестых переход на личности которых в жизни не видел (мож. это двухлетний дибил из интерната) - глупая штука.

 

Не понял зачем проверять CPL, в любом случае CPL = DPL шлюза (хотя про конформные сегменты надо глянуть, не уверен). Обращение к памяти - куда, в любое место? В любом случае такой трейсер не юзабелен, по первому же тику таймера TF теряется

 

Теоретизируем. Кусок кода с указанием системы плиз.

Это каких же? Пару сотен тактов вместо единиц тактов? Нифига несущественно.

Если пакер активно борется с трейсом то трудно. Те же замеры RDTSC уже гемор, который так и не понятно как решать.

Я никогда не считал что здесь только нубы, однако НЕнубы снисходят до предметной дискусии, клерк вам в пример

За переход на личности - сори

 

Оп, неверно выразился, CPL = DPL селектора в шлюзе конечно же

 

medstrax1
Я в общем сказал. Вы ведь ядро трассировать хотели, вот проверим кпл. Память - по [Eip]. По таймеру - ну да, я говорил что TF при переходе через шлюз сбрасывается. Есчо быстрые вызовы на себя перенаправить и взводить TF. Остальное вы ведь всё описали, заглушки на ISR, по Iret взводить TF если CPL не меняется.. Для тестов весьма простая реализация. Я знаю что работать не будет, так что даже пытаться создавать подобное смысла нет. Разве что поломать концепт
Wizard109
Тут немного другое, механизм отличен от того, что отладчики юзают. Это "быстрая" автоматическая трассировка через ISR.

 

Ок, попробовать можно. Критерий работоспособности кода? Если ты из ринг0 выполнишь sidt и получишь фейковый адрес - это катит за критерий? Без юзанья антитрейсовых фич, типа RDTSC, PERFORMANCE-MONITORING COUNTERS(эти вобще хрен сэмулируешь), брекпойнтов, MOV ss (их эмулировать не самая простая вещь). На одном ядре, второго у меня нет

 

medstrax1

Я выполняю mov eax,0x12345678 в ядре и получаю ~0x12345678.

 

И не зависает впридачу

 

Ну это я тебе обещаю)))

 

По крайней мере насчет 12345678 )

 

medstrax1
Посмотрим.

 

medstrax1
По поводу 1-го пункта... только пришел с массовой попойки, но перед этим думал пошаманить над кодом HAL, и был(/есть до сих пор) уверен что найду подобные траблы. Насчет того что теоретизирую - вы правы. Не сталкивался, а времени на исследование нет.

Смотря в каких масштабах...

Трудно разбираться в.т.ч. с многопоточностью. А в ядре есть еще прерывания и IRQL который при просмотре ассемблерного кода неслабо затрудняет восприятие...

З.Ы. Не обижайтесь если что. Я с удовольствием прочитаю все что вы напишете ибо в вашей области я ниже специализацией. Пост #63 написан скорее потому, что вы кроме доказательства собцтвенной правоты не возжелали объяснить популярнее, что в обещем было воспринято как флейм.

Clerk
Спс. Новая тема для изучения.

 

Забавно, уже столкнулся с нежеланием некоторых драйверов апдейтить IDT. Щас долго ловил почему падает система, однако выяснилось что драйвер хаспа сверяет рез-т sidt с какими-то своими внутренними переменными. Удивился, хасп ломал многократно и разными способами, однако же контроль IDT вижу впервые, причем контролирует не свой дескриптор (06), а именно базу IDT

 

medstrax1
Чтоб не менять базу(idtr), можно отобразить на этот адрес другую физическую страницу.