Pull to refresh
42
0

Senior Software Engineer

Send message

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

2.Запутывающее определение для Memory Ordering, Memory Ordering не является барьером. Само понятие барьера обозначает совершенно другое, существует два вида барьеров.
На уровне CPU - барьеры MFENCE, LFENCE, SFENCE, открываете AMD64 Architecture Programmer's Manual Volume 3: General Purpose and System Programming Instructions (PUB) (24594), находите mfence на 237 странице, lfence на 231 странице, sfence на 338 странице. В ARM архитектуре это инструкции dmb, dsb, isb
https://developer.arm.com/documentation/dui0802/b/A32-and-T32-Instructions/DMB--DSB--and-ISB?lang=en

На уровне компиляции барьеры нужны для предотвращения оптимизаций компилятора по доступу к памяти, например _ReadWriteBarrier у MSVC или asm volatile("": : :"memory") в GCC и Clang. Пример кода который вы можете исследовать и понять, что такое барьер на уровне компиляции прилагаю ниже.

// Компилируем с O3, смотрим в сгенерированный ассемблерный код.
#include <cstdint>
#include <cstdio>

uint8_t a[256] = {};

__attribute__((noinline)) void f() {
    for (int i = 0; i < 256; ++i) {
        asm volatile("" ::: "memory"); // <---
        a[i]++;
    }

}

int main() {

    f();

    uint8_t sum = 0;
    for (int i = 0; i < 256; ++i)
        sum += a[i];

    printf("sum = %d\n", sum);
}

3. Следующее вводит читателя в заблуждение: "Когда использовать seq_cst: когда нужна максимальная простота рассуждения о коде, либо для отладки. Это самый медленный режим."

Правильнее: "каждый поток видит все атомарные операции с seq_cst в одном и том же порядке".
Если вы используете seq_cst для "отладки" это скорее значит, что ваш код запутан и вы сами не можете понять как он работает, либо фундаментально не понимаете для чего нужен Memory Ordering.

4. Вот это утверждение на мой взгляд неверное: "Memory ordering позволяет точно контролировать синхронизацию и производительность"

Правильнее было бы: "Ограничивает видимость операций и переупорядочивание между потоками, что в свою очередь влияет на производительность."

Проект скомпилированный при помощи -O3 может работать медленнее -O2, случаи и обсуждения легко найти в Google. Идеальный вариант смотреть флейм графы и иметь механизм трейсинга по горячим путям, тогда достаточно легко понять какие опции для конкретного проекта приносят бОльший прирост.

Спорт это хорошо и кровь надо разгонять периодически. По тексту получается, что мозг это отдельное существо живущее своей жизнью, какие-то отмазки придумывает он, а лично вы его не контролируете. Лично для меня это уже не очень здоровая концепция.

Может взглянуть на это под другим углом? Например, что это перенос ответственности?

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

Общался некоторое время с ним по телескопам, давал мне несколько советов, за что ему спасибо.

avdx, Вы правильно считаете, но наличие сохраненного состояния не гарантирует вам хорошей рандомизации если за основу взят неправильный принцип его генерации, состояние — это только одна важная часть PRNG. Передо мной не стояла задача сохранять стейт xorshift256, в данном случае просто получить вменяемые compile time значения, чтобы не получать повторения одних и тех же инструкций на большОм количестве операций.
Можно делать и так как вы говорите, но качество рандома будет хуже чем у xorshift256, это основная причина почему сделано именно так, можете провести эксперимент с TestU01 если есть возможность и интерес. Так же посмотрите макрос SEED в проекте.
Спасибо, воспринимайте это как POC, для людей кто не хочет модифицировать конкретный backend LLVM :)
Описанные вами методы недостаточны для параноидальных программ. Как правило авторы коммерческого ПО используют по 3-4 метода детекта виртуальной машины, неговоря уже про malware.
VMware может быть задетектирована:
1) Проверками диапазона MAC адресов
2) Наличием sys файлов на диске (в случае установки VMware Tools)
3) Через WinAPI опросом конфигурации ОС и прочей системной информации (FirmwareTable)
4) Низкоуровневыми трюками.
5 п. Сейчас популярно передавать обфусцированный код оптимизирующему компилятору и на выходе получить вполне читабельный код.
Вот схема работы на LLVM:
1) Чтение обфусцированного кода.
2) Трансляция в LLVM bitcode.
3) Построение CFG.
4) Оптимизация.
5) Генерация оптимизированного кода.

Есть несколько попыток реализации:
а) Fracture
b) Dagger
c) Opticode online
На данный момент взламывается всё, в том числе инлайн патчинг возможен из-за допущенных ошибок, нужно понимать, что виртуализация кода не панацея.
не тратит тактов на nop?
nop = exchange eax,eax
pastebin.com/5cHFBbuf
Последний вариант по мне будет лучшим
Не работает даже используя стандартную тему оформления?
Appearance->Highlighting->Jump and calls
этот недостаток можно исправить написав расширение которое будет делать простой rebind клавиш.
если не вызывает дополнительных проблем, то конечно стоит.
спасибо, добавлю
да x86SwitchTo64BitMode надо фиксить, совместно с KiFastSystemCall на х64
защитится можно, как и детектировать перехваты в нашем приложении, но kernel драйвер порой не то решение, которое хочется использовать.
1

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity