Інженер Google запропонував програмний захист процесорів від атаки типу LVI

Якийсь час тому стало відомо про нову вразливість спекулятивної архітектури процесорів Intel, яку назвали Ін'єкція значення навантаження (LVI). У компанії Intel є своя думка про небезпеку LVI та рекомендації щодо її пом'якшення. Свій варіант захисту від подібних атак запропонував інженер компанії Google. Але за безпеку доведеться розплатитися зниженням продуктивності процесора в середньому на 7%.

Раніше ми відзначали, що небезпека LVI криється не в конкретному механізмі, виявленому дослідниками, а в самому принципі LVI-атаки по побічним каналам, який був показаний вперше. Тим самим було відкрито новий напрямок для загроз, про які раніше ніхто не підозрював (принаймні, про це не йшлося у публічному просторі). Тому цінність розробки спеціаліста Google Золя Бріджерса (Zola Bridges) полягає в тому, що його латка пом'якшує небезпеку ще навіть невідомих нових атак за принципом LVI.

Раніше в асемблер проекту GNU (Ассемблер GNU) було внесено зміни, які знижували небезпеку вразливості LVI. Ці зміни полягали у додаванні бар'єрних інструкцій LFENCE, які встановлювали строгу послідовність між зверненнями до пам'яті до та після бар'єру. Тестування патчу на одному із процесорів Intel покоління Kaby Lake показало зниження продуктивності до 22%.

Розробник Google запропонував свій патч з додаванням інструкцій LFENCE до набору компіляторів LLVM, а захист назвав SESES (Speculative Execution Side Effect Suppression). Запропонований варіант захисту пом'якшує як загрози LVI, так і інші подібні, наприклад, Spectre V1/V4. Реалізація SESES дозволяє компілятору додавати інструкції LFENCE в потрібних місцях у процесі генерації машинного коду. Наприклад, підставляти їх перед кожною інструкцією для читання з пам'яті або запису в пам'ять.

Інструкції LFENCE забороняють попереджувальне виконання всіх наступних інструкцій, поки попередні операції читання з пам'яті не будуть завершені. Очевидно, що це впливає на продуктивність процесорів. Дослідник з'ясував, що в середньому захист SESES знижував швидкість виконання завдань із використанням захищеної бібліотеки на 7,1 %. Розкид зниження продуктивності у своїй становив від 4 до 23 %. Початковий прогноз дослідників був песимістичнішим, припускаючи зниження продуктивності до 19 раз.

Джерело: 3dnews.ru