Про БЖД и тесты (правда, рукописные. В то время компы были только «на информатике») у нас в группе был мега-случай. Был вопрос что-то типа:
«Вы один у подножия горы, с вершины горы идет лавина, убежать от горы вы не можете — вам пригрождает путь река. Что вы будете делать?»
Этот вопрос всех поверг в ужас (надо вписать правильный ответ). Самый лучший ответ дал мой друг. Он вписал: «молиться».
Препод послал всех на пересдачу. (А правильный ответ (как говорил препод) был очевиден — «спрятаться за дерево»)
я говорю только про 3-е кольцо.
1. Zw вполне относится к winapi (ms говорит в msdn, что вызывать можно)
2. Зачем драйвер? 1 jmp и фильтры. Когда приложение хочет реестр, оно доходит до входа в ядро (Zw), там наш обработчик перенаправляет на фильтр, фильтр пускает (или не пускает) в ядро.
никаких холиваров, сугубо практика.
Если потребуется перехватить api, то я найду самое «узкое» место и поставлю самый надежный (== самый простой) хук. Далее уже можно сосредоточится на реализации фильтра и т.д.
P.S. Это скорее эволюция. WDM жив, его нельзя убивать, слишком много софта его использует… (правда, winapi использует намного больше софта и его тоже нельзя убивать)
да, переписали. А почему они это сделали? Потому что держать gui в 3-ем кольце это суицид. Постоянные прыжки «туда-обратно» губят всю производительность. Те, кто до сих пор используют их, не могут удивит юзера скоростью реакции на действия пользователя.
Zw уже «устоялись» — с NT 4.0 по 2008 не изменилось ничего (никто не знает что будет завтра с ms, может они вообще win32 прикроют :)).
Перехват стоит делать в самом прямом месте. (тут заменив всего 1 jmp получаем _thread safe_ фильтр. Красота! :))
О какой конкретно driver model речь? (изменения прошли мимо :\)
Zw не может поменяться просто так, для этого ms придется переписать:
1. все апи 3-го кольца.
2. поменять параметры для sysenter (рутина)
3. поменять интерфейс для драйверов.
Zw — нормальные ядерные функции и если надо что-то контролировать, то перехват Zw в ядре или на границе входа в ядро — самый лучший и самый надежный способ.
Zw == прямые jmp в ядро. (9x не рассматриваем? Если рассматриваем, то возможно надо писать драйвер для 9x, потому что Advapi32.dll может быть read-only)
ZwCreateKey, ZwDeleteKey, ZwEnumerateKey, ZwEnumerateValueKey, ZwFlushKey, ZwQueryKey, ZwQueryValueKey, ZwSetValueKey. (В первый раз хабр не пропустил список)
я задумался на тему «что дать почитать». Вспомнил отличные и прозрачные материалы Николая Радовского. Если надо более серьезное, то могу посоветовать почитать «Архитектуру микропроцессоров» г. 1998 Питер (автора не помню, очень давно было :( ).
«То, что скармливать» проистекает из
1. какой объем кешей.
2. какая разрядность у шины
3. какая задержка/частота у шины
4. какое время поиска/открытия ячейки памяти
Это уже не «черный ящик»… В крайнем случае «серый прозрачный» :)
Сейчас посмотреть оптимизацию для Intel можно наглядно с помощью их компилятора (он развернет циклы “как надо”, слегка оптимизирует алгоритмы (если возможно), может немного поменять логику работы с памятью). Всё что делает компилятор описано в соответствующих спеках. Логика работы в общем виде всегда была доступна, чтобы программер точно понимал где горлышко и почему все тормозит из-за жутких пенальти. Я довольно далеко ушел от архитектур, последним процем за которым я следил был AMD K7.
Многозадачность — это особенная фишка, которая заставляет постоянно перезагружать данные в кеш. :) При смене контекста, естественно, данные сбрасываются в кеш нижнего уровня (“ниже” нижнего уровня кеша – медленная RAM). Чем больше поток потребляет памяти, тем дороже его переключение, при желании или большой удаче можно “подвесить” поток – вся его работа будет заключатся в ожидании ответа от памяти, а когда ответ придет, квант времени будет исчерпан и уже другой поток запросит свою область.
Расскажут и с удовольствием! На этом держатся все ресурсоемкие приложения (от типа и версии процессора выбирается оптимальная для него функция, иногда встречаются даже разные exe и инсталлер создает ярлык на тот exe, который оптимизирован под CPU).
Скорость для ReverseManualHalf упала потому, что дергаются постоянно разные участки памяти. Подготовка данных просто обламывается (готовится один блок, а дергается из другого, идет переподготовка, и опять облом).
Чтобы максимально ускорить копирование, надо копировать несколько байт или (хотя бы) последовательно:
dest[i] = src[j];
dest[i+1] = src[j-1];
dest[i+2] = src[j-2];
dest[i+3] = src[j-3];
«Вы один у подножия горы, с вершины горы идет лавина, убежать от горы вы не можете — вам пригрождает путь река. Что вы будете делать?»
Этот вопрос всех поверг в ужас (надо вписать правильный ответ). Самый лучший ответ дал мой друг. Он вписал: «молиться».
Препод послал всех на пересдачу. (А правильный ответ (как говорил препод) был очевиден — «спрятаться за дерево»)
1. Zw вполне относится к winapi (ms говорит в msdn, что вызывать можно)
2. Зачем драйвер? 1 jmp и фильтры. Когда приложение хочет реестр, оно доходит до входа в ядро (Zw), там наш обработчик перенаправляет на фильтр, фильтр пускает (или не пускает) в ядро.
Note If the call to this function occurs in user mode, you _should_ use the name «NtOpenKey» instead of «ZwOpenKey».
Это почти 99% гарантия, что апи менятся не будет. И прямые прыжки в ядро разрешены (раз ms считает что user mode может вызывать ядро).
P.S. NtOpenKey == ZwOpenKey (только что проверил в дебагере)
Если потребуется перехватить api, то я найду самое «узкое» место и поставлю самый надежный (== самый простой) хук. Далее уже можно сосредоточится на реализации фильтра и т.д.
P.S. Это скорее эволюция. WDM жив, его нельзя убивать, слишком много софта его использует… (правда, winapi использует намного больше софта и его тоже нельзя убивать)
Zw уже «устоялись» — с NT 4.0 по 2008 не изменилось ничего (никто не знает что будет завтра с ms, может они вообще win32 прикроют :)).
Перехват стоит делать в самом прямом месте. (тут заменив всего 1 jmp получаем _thread safe_ фильтр. Красота! :))
О какой конкретно driver model речь? (изменения прошли мимо :\)
1. все апи 3-го кольца.
2. поменять параметры для sysenter (рутина)
3. поменять интерфейс для драйверов.
Zw — нормальные ядерные функции и если надо что-то контролировать, то перехват Zw в ядре или на границе входа в ядро — самый лучший и самый надежный способ.
1. какой объем кешей.
2. какая разрядность у шины
3. какая задержка/частота у шины
4. какое время поиска/открытия ячейки памяти
Это уже не «черный ящик»… В крайнем случае «серый прозрачный» :)
Многозадачность — это особенная фишка, которая заставляет постоянно перезагружать данные в кеш. :) При смене контекста, естественно, данные сбрасываются в кеш нижнего уровня (“ниже” нижнего уровня кеша – медленная RAM). Чем больше поток потребляет памяти, тем дороже его переключение, при желании или большой удаче можно “подвесить” поток – вся его работа будет заключатся в ожидании ответа от памяти, а когда ответ придет, квант времени будет исчерпан и уже другой поток запросит свою область.
Тема очень обширна для коммента. :(
Чтобы максимально ускорить копирование, надо копировать несколько байт или (хотя бы) последовательно:
dest[i] = src[j];
dest[i+1] = src[j-1];
dest[i+2] = src[j-2];
dest[i+3] = src[j-3];