Визначення поняття «нестабільне» є цим нестійким, або GCC має деякі стандартні проблеми відповідності?

Question 1

Мені потрібна функція, яка (наприклад, SecureZeroMemory з WinAPI) завжди нульову пам’ять і не оптимізується, навіть якщо компілятор вважає, що пам’ять після цього більше ніколи не буде доступна. Здається, ідеальний кандидат на нестабільність. Але у мене є деякі проблеми, насправді змушуючи це працювати з GCC. Ось приклад функції:

void volatileZeroMemory(volatile void* ptr, unsigned long long size)
{
    volatile unsigned char* bytePtr = (volatile unsigned char*)ptr;

    while (size--)
    {
        *bytePtr++ = 0;
    }
}

Досить просто. Але код, який GCC насправді генерує, якщо ви його викликаєте, сильно відрізняється залежно від версії компілятора та кількості байтів, які ви насправді намагаєтесь обнулити. https://godbolt.org/g/cMaQm2

GCC 4.4.7 та 4.5.3 ніколи не ігнорує нестабільність.
GCC 4.6.4 та 4.7.3 ігнорують нестабільність для розмірів масивів 1, 2 та 4.
GCC 4.8.1 до 4.9.2 ігнорує мінливість для розмірів масивів 1 і 2.
GCC 5.1 до 5.3 ігнорувати летючі для розмірів масивів 1, 2, 4, 8.
GCC 6.1 просто ігнорує його для будь-якого розміру масиву (бонусні бали за послідовність).

Будь-який інший перевірений мною компілятор (clang, icc, vc) генерує сховища, які можна очікувати, з будь-якою версією компілятора та будь-яким розміром масиву. Отже, на даний момент мені цікаво, чи це (досить стара і серйозна?) Помилка компілятора GCC, чи визначення нестабільного у стандарті неточне, що це насправді відповідає поведінці, що робить по суті неможливим написання портативного " Функція SecureZeroMemory "?

Редагувати: Кілька цікавих спостережень.

#include <cstddef>
#include <cstdint>
#include <cstring>
#include <atomic>

void callMeMaybe(char* buf);

void volatileZeroMemory(volatile void* ptr, std::size_t size)
{
    for (auto bytePtr = static_cast<volatile std::uint8_t*>(ptr); size-- > 0; )
    {
        *bytePtr++ = 0;
    }

    //std::atomic_thread_fence(std::memory_order_release);
}

std::size_t foo()
{
    char arr[8];
    callMeMaybe(arr);
    volatileZeroMemory(arr, sizeof arr);
    return sizeof arr;
}

Можливий запис із callMeMaybe () змусить усі версії GCC, крім 6.1, генерувати очікувані сховища. Коментування в паркані пам'яті також змусить GCC 6.1 генерувати сховища, хоча лише в поєднанні з можливим записом із callMeMaybe ().

Хтось також запропонував очистити кеші. Microsoft взагалі не намагається очистити кеш-пам’ять у "SecureZeroMemory". Кеш-пам'ять, імовірно, буде втрачено чинність досить швидко, тому це, мабуть, не є великою проблемою. Крім того, якщо інша програма намагалася перевірити дані або якщо вона збиралася бути записана у файл сторінки, це завжди була б обнулена версія.

Є також деякі занепокоєння щодо GCC 6.1 із використанням memset () у автономній функції. Компілятор GCC 6.1 на godbolt може зірватися, оскільки GCC 6.1, здається, генерує звичайний цикл (як 5.3 робить на godbolt) для автономної функції для деяких людей. (Прочитайте коментарі відповіді zwol.)

Question 2

Поведінка GCC може відповідати, і навіть якщо це не так, ви не повинні покладатися на volatileте, що хочете робити у таких випадках. Комітет С призначений volatileдля відображених у пам'яті апаратних регістрів та змінних, модифікованих під час ненормального потоку управління (наприклад, обробники сигналів та setjmp). Це єдине, для чого це надійно. Небезпечно використовувати як загальну анотацію "не оптимізуй це".

Зокрема, стандарт незрозумілий щодо ключового моменту. (Я перетворив ваш код на C; тут не повинно бути розбіжностей між C і C ++. Я також вручну зробив вбудовування, яке відбулося б перед сумнівною оптимізацією, щоб показати, що компілятор "бачить" на той момент .)

extern void use_arr(void *, size_t);
void foo(void)
{
    char arr[8];
    use_arr(arr, sizeof arr);

    for (volatile char *p = (volatile char *)arr;
         p < (volatile char *)(arr + 8);
         p++)
      *p = 0;
}

Цикл очищення пам'яті отримує доступ arrчерез летке значення lvalue, але arrсам не оголошений volatile. Отже, принаймні, безперечно, дозволяється компілятору С зробити висновок про те, що сховища, створені циклом, "мертві", і взагалі видалити цикл. У обґрунтуванні C є текст, який передбачає, що комітет мав намір вимагати збереження цих магазинів, але сам стандарт насправді не вимагає цієї вимоги, як я прочитав.

Для більш детального обговорення того, що стандарт вимагає чи не вимагає, див. Чому мінлива локальна змінна оптимізована інакше, ніж мінливий аргумент, і чому оптимізатор генерує цикл відмови від останнього? , Чи надає доступ до оголошеного енергонезалежного об'єкта за допомогою енергонезалежного посилання / покажчика привласнення нестабільних правил при згаданих зверненнях? та помилка GCC 71793 .

Щоб отримати докладнішу інформацію про те, для чого комітет думав volatile , знайдіть обґрунтування C99 для слова "мінливе". Документ Джона Регера " Летючі речовини неправильно скомпільовані " детально ілюструє, як volatileкомпілятори виробництва не можуть задовольнити очікування програмістів . Серія есеїв команди LLVM " Що повинен знати кожен програміст C про невизначену поведінку " не торкається конкретно, volatileале допоможе вам зрозуміти, як і чому сучасні компілятори C не є "портативними складальниками".

На практичне питання про те, як реалізувати функцію, яка робить те, що ви хотіли volatileZeroMemoryзробити: Незалежно від того, що вимагає стандарт, чи було призначено, було б найрозумнішим припустити, що ви не можете використовувати volatileдля цього. Там є альтернативою , яку можна покладатися на роботу, так як це порушило б занадто багато інших речей , якщо це не робота:

extern void memory_optimization_fence(void *ptr, size_t size);
inline void
explicit_bzero(void *ptr, size_t size)
{
   memset(ptr, 0, size);
   memory_optimization_fence(ptr, size);
}

/* in a separate source file */
void memory_optimization_fence(void *unused1, size_t unused2) {}

Тим не менш, ви повинні бути абсолютно впевнені, що memory_optimization_fenceце не вказується ні за яких обставин. Він повинен бути у власному вихідному файлі і не повинен піддаватися оптимізації часу посилання.

Є й інші варіанти, покладаючись на розширення компілятора, які можуть бути корисними за певних обставин і можуть створити жорсткіший код (один із них з’явився в попередній редакції цієї відповіді), але жоден з них не є універсальним.

(Я рекомендую викликати функцію explicit_bzero, оскільки вона доступна під цим іменем у більш ніж одній бібліотеці C. Є ще щонайменше чотири претенденти на це ім’я, але кожен прийнятий лише однією бібліотекою C.)

Ви також повинні знати, що навіть якщо ви зможете змусити це працювати, цього може бути недостатньо. Зокрема, розглянемо

struct aes_expanded_key { __uint128_t rndk[16]; };

void encrypt(const char *key, const char *iv,
             const char *in, char *out, size_t size)
{
    aes_expanded_key ek;
    expand_key(key, ek);
    encrypt_with_ek(ek, iv, in, out, size);
    explicit_bzero(&ek, sizeof ek);
}

Припускаючи апаратне забезпечення з інструкціями прискорення AES, якщо воно expand_keyі encrypt_with_ekє вбудованим, компілятор може мати можливість ekповністю зберігати у файлі векторного реєстру - до виклику explicit_bzero, що змушує його копіювати конфіденційні дані у стек, щоб просто їх стерти, і, гірше, нічого не робить щодо клавіш, які все ще сидять у векторних регістрах!

Question 3

Мені потрібна функція, яка (наприклад, SecureZeroMemory з WinAPI) завжди нульова пам’ять і не оптимізується,

Для цього призначена стандартна функція memset_s.

Що стосується це поведінка з нестійкими відповідно чи ні, це трохи важко сказати, і летючий було сказав , що давно страждає від помилок.

Одне питання полягає в тому, що в специфікаціях сказано, що "Доступ до летких об'єктів оцінюється суворо за правилами абстрактної машини". Але це стосується лише `` летких об'єктів '', а не доступу до енергонезалежного об'єкта через покажчик, до якого додано летючі об'єкти. Отож, мабуть, якщо компілятор може сказати, що ви насправді не отримуєте доступ до летючого об’єкта, тоді зрештою не потрібно розглядати об’єкт як летючий.

Question 4

Я пропоную цю версію як портативний C ++ (хоча семантика дещо відрізняється):

void volatileZeroMemory(volatile void* const ptr, unsigned long long size)
{
    volatile unsigned char* bytePtr = new (ptr) volatile unsigned char[size];

    while (size--)
    {
        *bytePtr++ = 0;
    }
}

Тепер ви маєте доступ до запису до летючого об’єкта , а не просто до енергонезалежного об’єкта, зробленого через нестабільний вигляд об’єкта.

Семантична відмінність полягає в тому, що тепер вона формально закінчує час життя будь-якого об’єкта (об’єктів), що займав область пам'яті, оскільки пам’ять використана повторно. Отже, доступ до об’єкта після обнулення його вмісту тепер, безумовно, невизначений (раніше він у більшості випадків був би невизначеним, але деякі винятки, безумовно, існували).

Щоб використовувати це занулення протягом життя об'єкта, а не в кінці, абонент повинен використовувати розміщення, newщоб повернути новий екземпляр вихідного типу назад.

Код можна зробити коротшим (хоча і менш зрозумілим) за допомогою ініціалізації значень:

void volatileZeroMemory(volatile void* const ptr, unsigned long long size)
{
    new (ptr) volatile unsigned char[size] ();
}

і на даний момент він є одноклассником і ледь взагалі гарантує допоміжну функцію.

Question 5

Має бути можливість писати портативну версію функції, використовуючи леткий об'єкт праворуч і змушуючи компілятор зберігати сховища масиву.

void volatileZeroMemory(void* ptr, unsigned long long size)
{
    volatile unsigned char zero = 0;
    unsigned char* bytePtr = static_cast<unsigned char*>(ptr);

    while (size--)
    {
        *bytePtr++ = zero;
    }

    zero = static_cast<unsigned char*>(ptr)[zero];
}

Оголошено zeroоб'єкт, volatileякий гарантує, що компілятор не може робити жодних припущень щодо його значення, навіть якщо він завжди вважається нульовим.

Вираз остаточного присвоєння читає з мінливого індексу в масиві і зберігає значення в нестабільному об’єкті. Оскільки це читання не може бути оптимізовано, це гарантує, що компілятор повинен генерувати сховища, зазначені в циклі.