Связь между драйвером и приложением

[sinsin]

Доброго времени суток.
Переделываю пример passthru из DDK (пользуюсь http://www.wd-3.com/archive/ExtendingPassthru2.htm). Требуется оповещать приложение о каждом принятом с запрещенного ip пакете. На мой взгляд использовать для этой цели событие, оповещающее приложение, и IOCTL будет медленно, поэтому хочу использовать для этого pipe или файлы, проецируемые в память, но возникает такая проблема - обработка пакета идет на  IRQL DISPATCH_LEVEL (например в функции PtReceivePacket), а zwCreateFile, IoCreateFile и т.д. требуют PASSIVE_LEVEL.
Нет ли функций, для  работы с файлами, проецируемыми в память и pipe для DISPATCH_LEVEL?
Как лучше организовать такое оповещение?

[resource]

Я бы не стал в ядре разгуливаться. Информация о ИП это совсем не много (по размеру). Я бы буферизовал блоки такой информации и дальше то самое Событие + IOCTL. Не вижу никаких проблем.
По поводу ZwCreateFile (и иже с ним). Да работает только на PASSIVE_LEVEL. А как ты хотел. Ты в ядре парень, тут шутить не любят  

[sinsin]

А примера кода такого обмена нигде нет?

[Ochkarik]

resource, +1
а насчет использования файлов.. можно в принципе подумать. для простоты реализации со стороны приложения. но это точно не будет быстрее.
я тут все никак руки не доходят разобраться, что надо сделать чтобы под Vista/Seven DeviceIOCintrol без полных админских привилегий проходили)

sinsin,
и кстати с чего вы решили что pipe - это быстро?
и каким образом использование отображаемого файла решает все вопросы синхронизации?) там даже для асинхронного чтения тот же KeSetEvent используется)
насчет примера... я тут кусками выкладывал кое что... поищите по KeSetEvent  и ObReferenceObject. и еще вам потребуется что то типа MmMapLockedPages. - это тоже все было на форуме.
и DDK) потому, что я, к сожалению,  не знаю  аналоги этому среди NDIS функций.

[resource]

что надо сделать чтобы под Vista/Seven DeviceIOCintrol без полных админских привилегий проходили

Я вот знаете ли, как старый дедушка, на XP сижу пока . Не в том смысле, что так и надо. Хорошо это или плохо - просто так вот есть.

с чего вы решили что pipe - это быстро?

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

не знаю  аналоги этому среди NDIS функций

Ну, если KeSetEvent и ObReferenceObject тоже имелись ввиду, то тут NdisSetEvent есть, а для второй мне кажется ndis аналога нет (правельнее сказать - я такого не знаю). Что касается MmMapLockedPages, которая, кстати говоря, на сегодня считается устаревшей (MmMapLockedPagesSpecifyCache), то я почти уверен что для нее нет ndis обёртки (этож всё макросы которые вызывают оригинальные функции). По крайней мере на странице DKK по NdisAllocateMdl создается именно такое впечатление.

По поводу моего предложения буферизовать блоки данных. Тут главное используй Lookaside list (не люблю переводить этот термин). Не забудь, для них ndis-варианты есть, как например NdisAllocateFromNPagedLookasideList, и всё будет быстро и круто.

[sinsin]

Ochkarik, resource большое спасибо!

[Ochkarik]

resource, я тоже на XP... но к будущему готовлюсь)
MmMapLockedPages - это я для поиска по форуму написал) чаще встречается.

Lookaside это хорошо... только вот куда коня то запрягать) в том смысле как данные в приложение отдать? опять через отображаемый файл?
я тоже не нашел аналогов ObReferenceObject и  MmMapLockedPages. видимо подразумевается что NDIS не должен напрямую общатся с приложениями)

есть еще WMI инструментарий... но я им никогда не пользовался. копать надо)

[resource]

в том смысле как данные в приложение отдать?

IOCTL или Read/Write если хочется. Если драйвер складирует блоки данных, то на мой взгляд вопрос о молнеиносной передачи этих данных в приложение отпадает сам собой. В этой ситуации суетиться надо уже не драйверу а приложению. В том плане, что событие надо ждать всегда.

Но если поставить вопрос по другому: какой вариант будет наибыстрейшим на отрезке от вызова функции (для получения данных) приложением, до того момента как функция вернет управление, с буффером, полным счастья (считаем что данные у драйвера, уже лежат и ждут когда их заберут)? Думаю, что быстрее мапинга тут врядли что-то будет. Тут и вызывать то ничего не потребуется, когда данные уже в памяти, к которой открыт доступ. Но приложению еще надо узнать начало и конец новых данных в этом буфере. Такие указатели можно записывать в этот же буфер, в несколько первых (или последних) байт. Но тут, как вы понимаете, остро встает проблема их синхронизации. И тут уже получается не самая простая ситуация. Я, честно говоря, даже не знаю как такое синхронизировать: события как-то не в тему, мьютексы на свалку, спинлоков в юзермоде нет, да и дело то не том, что их нет, а в том что драйверу нельзя ждать если нужно писать данные в буфер.

 В реальной ситуации надо конечно серьезно подумать, мапить или не мапить (вот в чем вопрос). Есть свои плюсы и минусы (как банально). Мне кажется для блоков таких малых объемов это лишняя суета. в общем по ситуации. Универсальных решений не существует (наверное).

P.S. Я WMI тоже не пользовался никогда в жизни

[sinsin]

Ochkarik, resource, если нет аналога ObReferenceObject, получается, что никак нельзя передать событие? А как тогда  можно сообщить приложению о том, что  имеются данные для чтения?

[resource]

Если нет аналога ObReferenceObject это не значит, что нельзя использовать саму ObReferenceObject   

[sinsin]

Я  знаю, что можно, но в неё передается  Object, который   the caller obtained this parameter either when it created the object or from a preceding call to ObReferenceObjectByHandle after it opened the object, а ObReferenceObjectByHandle действует только на Passive_Level. Я создаю событие в приложении и пытаюсь передать его в драйвер по Handle. Как можно получить указатель на событие по Handle без ObReferenceObjectByHandle?  И как лучше здесь будет передать событие?

[resource]

Во первых: за чем тебе вообще нужна ObReferenceObject? Ведь, как я полагаю, ObReferenceObjectByHandle тоже увеличивает счетчик ссылок.
Во вторых: ну и вызывай себе ObReferenceObjectByHandle на PASSIVE_LEVEL, что тебе мешает?

[sinsin]

Мешает то, что я передаю Handle по ioctl,  и в процедуре обработки пытаюсь получить событие, а эта процедура выполняется  на DISPATCH_LEVEL. Я в драйверах новичок, поэтому вопрос: кроме ioctl через что можно передать данные?

[resource]

Многие ирпы, в том числе и IRP_MJ_DEVICE_CONTROL (твой ioctl) приходит на PASSIVE_LEVEL. Там и получай событие. Посмотри в DDK Dispatch Routines and IRQLs. Максимум на чем может прийти IRP_MJ_DEVICE_CONTROL это APC_LEVEL, но тебе это вряд ли грозит. Чтоб спокойнее было, можешь проверять текущий  IRQL

[sinsin]

Спасибо. Понял.

[Ochkarik]

resource, в ring-3 spinlock-ов нет) но почему все забывают о interlocked функциях? это ж так сказать "нативная" синхронизация на уровне команд процессора(-ов)
все объекты блокировки и синхронизации ядра в конечном счете на них построены)

[resource]

Ochkarik, согласен.

Кстати какой вариант лучше подойдет в такой ситуации (два 32х-битных числа, лежат рядом), например так?

Код:

Happiness = InterlockedAnd64(Address, 0xFFFFFFFFFFFFFFFF);

Я вот подумал. Всё равно, как-то нехорошо получается. Что если буфер наполнится (драйвером) гораздо быстрее, чем считается (приложением). Теоретически такое возможно, особенно если учесть, что ProtocolReceivePacket может быть вызвана на DISPATCH_LEVEL. Сам буфер-то не сблокирован (это была бы жесть). А тут уже может получиться что угодно. Сделать большой буфер? Можно, но это из серии - надежда на удачу, т.е. теоретически гарантий не дает.

И еще, возвращаясь к изначальному посту автора топика, я не пойму причем тут файлы, проецируемые....блабла. Мапить надо память (память в память) а не файл.

[Ochkarik]

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

а размер буфера обычно выбирается исходя из максимального потока деленного на частоту опроса + запас)

[resource]

 Ну а какую interlocked функцию вы бы порекомендовали в данной ситуации. Напомню: надо прочитать два 32х-битных числа, которые лежат рядом.
 Просто я, было дело, записывал значение "интерлоками", но вот читать не читал, поэтому не знаю, что тут лучше, ведь они все пишут/обменивают. Или InterlockedAnd вполне то, что надо и тут вопрос только в поддержке/неподдержке x64 ?
 Кстати InterlockedAnd64 помоему без проблем должен поддерживаться на x32.

Код:

LONGLONG __cdecl InterlockedAnd64(
  __inout  LONGLONG volatile* Destination,
  __in     LONGLONG Value
);

а LONGLONG это как известно (из того же SDK)

Код:

#if !defined(_M_IX86)
 typedef __int64 LONGLONG; 
#else
 typedef double LONGLONG;
#endif

так что хоть и через ж... дабл, но поддерживается. В юзермоде наверное не супер критично дабл или не дабл, а в ядре, сами понимаете  .

кстати есть в winbase.h и такое

Код:

#if !defined (InterlockedAnd)

#define InterlockedAnd InterlockedAnd_Inline

FORCEINLINE
LONG
InterlockedAnd_Inline (
    __inout LONG volatile *Target,
    __in    LONG Set
    )
{
    LONG i;
    LONG j;

    j = *Target;
    do {
        i = j;
        j = InterlockedCompareExchange(Target,
                                       i & Set,
                                       i);

    } while (i != j);

    return j;
}

#endif

такая вот замануха. Но там же есть и нормальный прототип.

[Ochkarik]

я не совсем об этом. строго говоря что есть "полноценная" interlocked функция? - это ОДНА машинная команда, выполнение которой, самим процессором выполняется "атомарно" независимо от уровня привелегий, IQRL и аппаратных/программных прерываний.
такие операции могут быть реализованы аппаратно на основе следующих машинных команд x86 архитектуры (к примеру)
InterlockedCompareExchange
CMPXCHG - команда может быть 8/16/32 битной.
или CMPXCHG8B  - делает  "Compare EDX:EAX with m64. If equal, set ZF and load ECX:EBX into m64. Else, clear ZF and load m64 into EDX:EAX."

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

причем приведенные выше инструкции:
"This instruction is not supported on Intel processors earlier than the Intel486 processors." и "This instruction is not supported on Intel processors earlier than the Pentium processors" соответственно!

реализация моей любимой InterlockedExchangeAdd, основана на команде XADD с префиксом LOCK.
для нее, как мы видим, существует только 32 битная реализация. но зато она есть и в ring-0 и в ring-3, чем очень удобно пользоваться.

а вот очень похожая команда ядра ExInterlockedAddLargeInteger (для 64 битных аргументов) в kernel уже реализована через дополнительный SpinLock (что в пользовательском режиме - просто невозможно... ну или довольно проблематично) и оно понятно - нет соответствующей команды процессора!

 Упомянутая вами InterlockedAnd64 существует только для архитектур IPF и x64 по той же причине. и аналога в kernel - для нее нет...
что до ее реализации в Winbase.h...  честно говоря наверно ребятам виднее. возможно они играют на тонкостях оптимизации и особенностях переключения нитей. честно скажу - не знаю) поэтому не использую, во избежание) да и надобности не было.

вот такая катавасия)
кстати я тут может быть, немного ошибок в описании наделал. но в качестве иллюстрации - все выглядит как-то так)
PPS строго говоря я с этим довольно давно разбирался... но кажется реализация именно такая) если у кого стоит отладчик ядра - поставьте бряки на указанные функции (в SoftIce это было можно, посмотрите глазами?)


PPS еще один момент. для interlocked функций ядра надо внимательно смотреть на строчку типа
"Interlocked operations cannot be used on non-cached memory." (для InterlockedAnd) - что означает то, что в случае свопируемой памяти, будет сгенерировано исключение с последующей подгрузкой недостающих страниц в оперативную память. что нарушит атомарность выполнения функции.

или "InterlockedCompareExchange is designed for speed and, typically, is implemented inline by a compiler. InterlockedCompareExchange is atomic only with respect to other InterlockedXxx calls. It does not use a spin lock and can be safely used on pageable data." - - что означает что оба процесса должны использовать доступ к переменной с использованием префикса lock.

таким образом я для себя выделил два основных момента:
атомарная interlocked функция над одной переменной может быть использована(для синхронизации доступа из приложения и драйвера) только в случае:
1. не свопируемой переменной.
2. только в случае если реализация функции может быть выполнена машинной командой с префиксом LOCK. (без используется дополнительного spinLock-а).
я примерно так и поступаю)

[PredatorAlpha]

Но приложению еще надо узнать начало и конец новых данных в этом буфере. Такие указатели можно записывать в этот же буфер, в несколько первых (или последних) байт. Но тут, как вы понимаете, остро встает проблема их синхронизации. И тут уже получается не самая простая ситуация.

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

[Ochkarik]

PredatorAlpha, да проблем никогда нет) есть только поиски оптимальных решений)

[Ochkarik]

в догонку моему посту про interlocked-функции.
раньше делал их вручную))) пока в DDK не нашел))

Код:

void __inline
InterlockedAdd( unsigned long ptr_value,  unsigned long  value)
{
    _asm {                                      
        mov edi, dword ptr[ptr_value];
        mov edx, value;    
        lock add dword ptr[edi],edx;   
    };
    return;
};

или еще вот так делал:

Код:

    
_asm
    {
        mov edx, lpSpinLockBlockCount;
        lock mov dword ptr[edx], 123;
    };
//какой то код для защиты
    _asm
    {
        mov edx, lpSpinLockBlockCount;
        lock mov dword ptr[edx], 0;
    };

[alkor]

Я бы не стал в ядре разгуливаться. Информация о ИП это совсем не много (по размеру). Я бы буферизовал блоки такой информации и дальше то самое Событие + IOCTL. Не вижу никаких проблем.

можно поподробнее 

[resource]

можно поподробнее 

А насколько подробнее? 

Всё, что вам надо:
1. Знать, что такое двусвязный список и как им пользоваться
http://msdn.microsoft.com/en-us/library/ff563802(VS.85).aspx
2. Уметь выделять память
http://www.wasm.ru/series.php?sid=9 - 6я и 7я части