куплю код детекта вм машин без црт

UbIvItS,

> в много-потоке сравниваются счётчики между потоками.

Какой принцип, тоесть что именно замерять ?

 

в каждом потоке тупо счётчик а-ля "х++;" и чекаешь дельты меж потоками. эти дельты на хосте и под виртой различаются. балансировка загрузки ядер проца под виртой лажует, пч вирта всего лишь один из кучи процессов в хосте.

 

UbIvItS,

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

Как реализовать, сейчас попробую ?

Два потока инкрементят переменные ?
Переменные разные, что бы небыло блокировок(иначе можно сбалансировать inc/dec) ?
Какая проц маска, тоесть на одном проце ?
Что именно замерять, разницу в переменных за постоянный интервал ?

 

он не может быть как на одном == в идеале счётчики должны показывать примерно равные числа на циклах равного "веса", но на деле загруженность ядер проца неравномерна (особенно под виртой).

самый простой вариант..

thread1:
while (x < n){
x++;
}
thread2:
while(y < n)y++;
return y-x;

вирта и хост должны бегать на одном проце == у многопроцных машин вирта может получать монопольный доступ к проц(у/ам) и там от таких замеров толку мало == вирта начинает балансировать нагрузку на уровне хоста.

 

Хост, адр переменной/inc's:

403000 1452A6F4
403020 1434FC4A

403000 146574D6
403020 1456B7A4

vmw:

403000 32654A43
403020 218B9B15

403000 3453EC32
403020 1F847B6D

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

Если выравнить на страницу:

403000 58FAE48B
404000 36A8E783

403000 54E2EA1D
404000 34BF66C5

Потоки одинаковые

--- Сообщение объединено, 24 мар 2020 ---

2 проца ^

 

пч начинает играть кэш.

 

https://app.any.run/tasks/a3d47919-5fdf-4571-9849-515e8cc60f82

Там вообще не работает. Можно диагност сообщений насыпать, посмотреть чего оно повисло.

--- Сообщение объединено, 24 мар 2020 ---

UbIvItS,

> пч начинает играть кэш.

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

--- Сообщение объединено, 24 мар 2020 ---

На варе короче разница в счётчиках есчо зависит от числа копий апп или консолей

Оно глючит на простейших двух циклах. Нужны сотни тестов что бы понять чего вирты глючат. Походу детект можно строить на чём угодно, но главное что бы это было два цикла

 

TermoSINteZ,

И как это сделать в юм, это что сарказм ?

Такую же статистику снимать как при тестах melt&spectre, если помните тогда был анстаб на хосте. На вирте это вообще будет работать рандомом. Замер в двух циклах стабильно даёт результаты, зачем какой то сомнительный анстаб нужен.

 

TermoSINteZ,

cupid эмулируется виртой. clflush - это получится рандом тест, хотя можно попробовать.

 

никаких глюков там нет == это просто Вопрос балансировки нагрузки на ядра проца и кэш, мало-мальски прилично балансировать можно лишь на уровне хоста и вынь в этом плане совсем унылая, ибо там гадят профайл её теневые сервисы. Касательно циклов, их можно делать сколько хошЪЪЪ и вирту при росте их кол-ва будет хорошо плющить. Особенно такой подход помогает щимить виртуальные ядра/процессоры.

такое можно нормально проделывать только под кастомным ядром линя/бсд. А в выне кэш гадит теневая активность керна.

 

можно и без много-потока отловить вирту..

T=Nz

т -- время затраченное на цикл.
энн -- кол-во итераций.
z -- время одной итерации.

В итоге можно так..

start rdtsc

while(x < n)x++;

T = end rdtsc

То бишь z = T/x == если z слишком шустрый, значит rdtsc эмулят (оное есмь стигмата вирты). ежли показания соответствуют, считаем процент по времени доступа к процу. Под виртой он заметно (в разы, если не на порядок) ниже в сравнение с хостом. Вообще, вирта с показателями труЪЪЪ жЫзЪтянки вполне возможна, но на практике такое гонять зачастую бессмысленно. Ибо отдельная машина тупо дешевле и даже рестарт/запуск у неё более быстрый.

 

UbIvItS,

Тут был тест https://wasm.in/threads/avanguard-the-win32-anti-intrusion-library.33212/page-11#post-416300

Код (Text):

1. rdtsc
2. 3.75
3. 3.67

Тайминг как на хосте, в пределах погрешности.

Абсолютный предел нельзя задать, так как не получится в диапазон уложиться. Если тайминг просядет из за эмуляции, как например cupid, то всё равно нужно эталонное время что бы найти отношение.

Мне первый вариант нравится с эталонным циклом, жаль тестить негде. Можно тему создать с просьбой потестить, тогда получится нужная статистика. В начале нужно составить несколько тестов. Надо посмотреть что с кэшем, вот тут я что то тестил https://wasm.in/threads/meldown-spectre-hardware-vulnerability.32461/page-4#post-396098 мне результаты с кэшем не понравились, так как ничего не вышло. Как реализовать с clflush ?

Что выше в тесте какая то аномалия при выборке была, так это случайно было найдено.

--- Сообщение объединено, 25 мар 2020 ---

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

 

его можно прикинуть: лаг тика умножить на кол-во тиков на операцию. лаг тика == 1 делить на частоту проца.

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

--- Сообщение объединено, 25 мар 2020 ---

это всего лишь маскировка эмулем.

 

UbIvItS,

> это всего лишь маскировка эмулем.

Нет, это хостовый счётчик. Из за аппаратной вирты(vmx).

> его можно прикинуть: лаг тика умножить на кол-во тиков на операцию. лаг тика == 1 делить на частоту проца.

Я не всегда понимаю о чём вы говорите, что за лаги/тики.. проще формулой как выше

> под вынькой никак..

Был анстаб на тестах M&S, я там тоже самое утверждал, ядро нт не предназначено для таких атак.

Что думаешь на счёт атомиков ?
Как лучше провести замер ?

Допустим есть два треда выбирающих асинхрон в не выравненную переменную. На хосте будет взаимный простой, на вирте сложно предположить что произойдёт..

--- Сообщение объединено, 25 мар 2020 ---

https://wasm.in/threads/meldown-spectre-hardware-vulnerability.32461/page-2#post-395880

Тут я уже тестил clflush и ничего кроме шума не получил, я просто забыл.

--- Сообщение объединено, 25 мар 2020 ---

TermoSINteZ,

А почему ты не вспомнил те тесты, тоже забыл ?

 

TermoSINteZ,

А зачем предложил если знал что это не работает и уже проверялось.. впрочем не важно, я есчо раз проведу тест, только нужно продумать как это сделать что бы не получить в результате рандом.

 

TermoSINteZ,

Линуксы не рассматриваются. Можно исключить ось между прерываниями/планированием. Так что это в принципе не важно какая ось.