А>Так чем не устраивает ксор я нулём я не понял.
Сравните поведение вышеупомянутого кода с ксором с префиксом lock перед ксором и без. Потом подумайте.

Здравствуйте, ononim, Вы писали:

А>>Так чем не устраивает ксор я нулём я не понял.
O>Сравните поведение вышеупомянутого кода с ксором с префиксом lock перед ксором и без. Потом подумайте.


Во первых если адрес выравнен на 4, то лок вообще пропускается камнем. Во вторых проверяющий поток не собирается использовать синхронизации на переменной, накой тогда нужно проверять её на запись. Да и никакой разницы в поведении для ксора нет, что с локом, что без. Атомарность не нужна, ибо переменная не изменяется и не читается.

А>>>Так чем не устраивает ксор я нулём я не понял.
O>>Сравните поведение вышеупомянутого кода с ксором с префиксом lock перед ксором и без. Потом подумайте.
А>Во первых если адрес выравнен на 4, то лок вообще пропускается камнем. В
Выравнен. Более того — он выравнен на 0x10000 ибо таков granularity файлмапингов.

А>о вторых проверяющий поток не собирается использовать синхронизации на переменной, накой тогда нужно проверять её на запись. Да и никакой разницы в поведении для ксора нет, что с локом, что без. Атомарность не нужна, ибо переменная не изменяется и не читается.
Плохо думали.
xor [ptr], 0 читает переменную, затем записывает ее прочитанное значение в память. В момент исполнения этой инструкции другой процессор может ее изменить, потому мой код показывает проблему на многопроцессорных/ядерных системах
Разница: lock лочит шину доступа к памяти на время исполнения инструкции и другие ядра не могут во время исполнения инструкции доступиться к памяти. Что решает проблему, но бьет по перфомансу.

O>ЗЫ а давайте не флеймить, если нечего сказать по теме — как "потрогать" память на запись, не записывая в нее ничего?

Для проверки сегмента есть инструкция VERW. Для проверки региона нужно запросить инфу у ядра, NtQueryVM etc, в зависимости от мода и прочих условий. Можно напрямую дт потыкать.

O>>ЗЫ а давайте не флеймить, если нечего сказать по теме — как "потрогать" память на запись, не записывая в нее ничего?
А>Для проверки сегмента есть инструкция VERW.
VERW видел, как юзать его в защищенном режиме в flat model для проверки доступности страница не понял. Похоже никак. Если скажете как — буду премного благодарен.

А>Для проверки региона нужно запросить инфу у ядра, NtQueryVM etc, в зависимости от мода и прочих условий. Можно напрямую дт потыкать.
Сисколл позвать — много ума не надо. Но это же ваще ппц как медленно, даже хуже чем с lock'ом.

Здравствуйте, ononim, Вы писали:

O>>>ЗЫ а давайте не флеймить, если нечего сказать по теме — как "потрогать" память на запись, не записывая в нее ничего?
А>>Для проверки сегмента есть инструкция VERW.
O>VERW видел, как юзать его в защищенном режиме в flat model для проверки доступности страница не понял. Похоже никак. Если скажете как — буду премного благодарен.

Страница к сегменту в данном случае никакого отношенья не имеет.

А>>Для проверки региона нужно запросить инфу у ядра, NtQueryVM etc, в зависимости от мода и прочих условий. Можно напрямую дт потыкать.
O>Сисколл позвать — много ума не надо. Но это же ваще ппц как медленно, даже хуже чем с lock'ом.

Медленно это если миллионы раз сисколы дёргать в секунду. Реально же такая проверка может быть однократной, иначе придётся миллионы раз ремапить какие то секции, чего никто не делает и сделать не может. Задача и проблемы в сферическом вакууме.

O>>>>ЗЫ а давайте не флеймить, если нечего сказать по теме — как "потрогать" память на запись, не записывая в нее ничего?
А>>>Для проверки сегмента есть инструкция VERW.
O>>VERW видел, как юзать его в защищенном режиме в flat model для проверки доступности страница не понял. Похоже никак. Если скажете как — буду премного благодарен.
А>Страница к сегменту в данном случае никакого отношенья не имеет.

O> как бы мне проверить адрес
A> зырь, есть VERW
O> VERW не катит наверное
A> какой нафиг VERW, он ваще тут не пойдет

кэп, вы ведете себя как марковский тролль

А>>>Для проверки региона нужно запросить инфу у ядра, NtQueryVM etc, в зависимости от мода и прочих условий. Можно напрямую дт потыкать.
O>>Сисколл позвать — много ума не надо. Но это же ваще ппц как медленно, даже хуже чем с lock'ом.
А>Медленно это если миллионы раз сисколы дёргать в секунду. Реально же такая проверка может быть однократной, иначе придётся миллионы раз ремапить какие то секции, чего никто не делает и сделать не может. Задача и проблемы в сферическом вакууме.
Проверка неоднократно вызывается при вызове практически любого сисколла и добавление 3..10 NtQueryVirtualMemory на каждую Nt*** и многие NtGdi*** весьма плачевно скажется на перфомансе, что бы вы сами поняли если бы немного подумали над тем зачем она нужна. Но вместо того вы лишь троллите в попыках доказать, что анонимы тоже бывают круты... Но увы, пока у вас получается совершенно наоборот

O>Проверка неоднократно вызывается при вызове практически любого сисколла и добавление 3..10 NtQueryVirtualMemory на каждую Nt*** и многие NtGdi*** весьма плачевно скажется на перфомансе, что бы вы сами поняли если бы немного подумали над тем зачем она нужна. Но вместо того вы лишь троллите в попыках доказать, что анонимы тоже бывают круты... Но увы, пока у вас получается совершенно наоборот

ProbeForWrite() etc обычно юзается. Либо вообще память не чекается, а возможный фолт откатывается в сех. Фолт в любом случае будет, атомарно или нет. А в таком случае зачем проверка нужна ?

Могу предположить что это аверский фильтр будет, но зачем в нём выполнять синхронизации на пользовательском буфере опять же не понятно. Ядро к примеру так не делает, если нужно память лочится(MmLockUserBuffer() etc, ремап через мдл). Я не припомню ни одного сервиса(в шадове тоже), где такие синхронизации имеются. В любом случае такие механизмы внесут нестабильность и дров ваш(клиф наверно ?) будет есчо дырявее.

O>>Проверка неоднократно вызывается при вызове практически любого сисколла и добавление 3..10 NtQueryVirtualMemory на каждую Nt*** и многие NtGdi*** весьма плачевно скажется на перфомансе, что бы вы сами поняли если бы немного подумали над тем зачем она нужна. Но вместо того вы лишь троллите в попыках доказать, что анонимы тоже бывают круты... Но увы, пока у вас получается совершенно наоборот
А>ProbeForWrite() etc обычно юзается. Либо вообще память не чекается, а возможный фолт откатывается в сех. Фолт в любом случае будет, атомарно или нет. А в таком случае зачем проверка нужна ?
А>Могу предположить что это аверский фильтр будет, но зачем в нём выполнять синхронизации на пользовательском буфере опять же не понятно. Ядро к примеру так не делает, если нужно память лочится(MmLockUserBuffer() etc, ремап через мдл). Я не припомню ни одного сервиса(в шадове тоже), где такие синхронизации имеются. В любом случае такие механизмы внесут нестабильность и дров ваш(клиф наверно ?) будет есчо дырявее.
Нет не клиф, и не дров вообще.. Хуки все в юзермоде. При обращении в ядре к невалидному юзерскому буферу SEH в юзермоде не придет.
Блин ну точно марковский тролль

Здравствуйте, ononim, Вы писали:

O>Потому сделано следующее — обхукана туева хуча системных сервисов, и все подозрительные буфера которые передаются им в параметрах предварительно "облапываются" в нужных местах, что приводит к срабатыванию VEH и все работает правильно.
O>Так вот я озадачился вопросом оптимизации облапывания.

Любопытно, а не может ли в этой реализации случиться так, что уже облапанный буфер снова станет невалидным внутри системной фнукции?

O>>Потому сделано следующее — обхукана туева хуча системных сервисов, и все подозрительные буфера которые передаются им в параметрах предварительно "облапываются" в нужных местах, что приводит к срабатыванию VEH и все работает правильно.
O>>Так вот я озадачился вопросом оптимизации облапывания.
A>Любопытно, а не может ли в этой реализации случиться так, что уже облапанный буфер снова станет невалидным внутри системной фнукции?
нет