Перейти до вмісту

Тіньові стеки CET

Архітектурний довідникFeex

Також називається CET-SS

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

Що потрібно знати

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

Як це працює

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

Де це корисно

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

Як перевірити підтримку та активацію

CPUID.07H.00H:ECX біт 7 перераховує можливості тіньового стека. Використовуйте задокументований інтерфейс статусу ОС для кожного процесу або потоку, щоб переконатися в активності функції. Непояснене аварійне завершення роботи вимагає перевірки підтримуваних оновлень програмного забезпечення та сумісності перед зміною політики захисту.

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

Чого ця функція не гарантує

Тіньові стеки не підтверджують підтримку IBT, не захищають усі дані програми та не усувають кожну атаку на потік керування. Позначення процесора не доводить, що кожен виконуваний файл і завантажена бібліотека охоплені політикою сумісності ОС.

Сумісність і продуктивність на практиці

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

Практичний контрольний список для верифікації

  1. Зафіксуйте точну модель процесора або платформи, а також версії використовуваної програми, ОС і середовища виконання. Збережіть точне формулювання фактичної помилки або вимоги.
  2. Звіртеся з документацією виробника для цієї точної моделі, потім перевірте фактичні можливості та стан активації в середовищі, де виконується програма.
  3. Порівняйте кожну вимогу вибраного двійкового файлу або бекенда. Схожої назви функції, псевдоніма чи загального позначення технології недостатньо.
  4. Переконайтеся, що програма вибрала призначену реалізацію. Використовуйте її задокументовані засоби діагностики та підтримуваний резервний варіант, якщо вимоги не виконуються.
  5. Вносьте по одній підтримуваній зміні за раз і повторюйте те саме робоче навантаження. Зберігайте оригінальну конфігурацію та можливість відновлення.

Якщо функція вказана, але програмне забезпечення не може її використати

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

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

Джерела та межі застосування цього пояснення

Intel 64 and IA-32 Architectures Software Developer's Manual · Ядро Linux: тіньовий стек Control-flow Enforcement Technology

Ці довідкові матеріали визначають архітектурну поведінку та вимоги до програмного забезпечення. Вони не перевіряють незалежно кожне значення функції на сторінці пов'язаної моделі обладнання. Щодо підтримки моделі використовуйте дані виробника на цій сторінці та перевіряйте фактичну конфігурацію системи. Ця стаття не містить бенчмарків, сертифікації чи дат незалежного огляду.

Джерела та верифікація

Власник авторських прав: Feex. Дата незалежної перевірки не зафіксована. Як ми проводимо дослідження.

  • Intel 64 and IA-32 Architectures Software Developer's Manual · Томи 1 і 2 описують зазначені сімейства інструкцій і CPUID; Том 3 описує стан, сторінкову організацію пам'яті, VMX і засоби захисту. Документація з архітектури не підтверджує підтримку для конкретної моделі.
  • Ядро Linux: тіньовий стек Control-flow Enforcement Technology · Розрізняє апаратну підтримку, бінарні маркери, увімкнення завантажувачем та активний захист на рівні потоків. Описує IBT та тіньові стеки як окремі засоби.

Чи була ця стаття корисною?

Достатньо відповісти "так" або "ні". За бажанням виберіть причину або додайте коротку примітку.

Чи була ця стаття корисною?