Spectre-патч для Windows Server с Retpoline: тестируем на Hyper-V, смотрим на производительность

Windows-серверов в наших managed-проектах меньше, чем Linux - но они есть, и несколько клиентов держат на Hyper-V серьёзную нагрузку. Когда Microsoft выкатил первые KB-шники с поддержкой Retpoline, стало интересно: как это выглядит на практике, и правда ли что виртуализованные среды отделаются дешевле?

Спойлер - в нашем случае отделались. Но расскажем по порядку и с методикой, потому что «всё нормально» без цифр - это не ответ.

Что пришло в первых обновлениях

Microsoft закрывал Meltdown и Spectre поэтапно. Первая волна патчей в начале января закрывала Meltdown (CVE-2017-5754) через изоляцию адресного пространства ядра, примерно как KPTI на Linux; в ней использовался IBRS. С Spectre Variant 2 (CVE-2017-5715) история дольше: нужны и микрокод процессора, и поддержка со стороны ОС.

Retpoline - это компиляторный трюк, альтернатива IBRS. Вместо того чтобы на каждый системный вызов включать IBRS (что дорого по производительности), retpoline заменяет непрямые переходы конструкцией, которая не может быть использована branch predictor'ом для спекулятивного выполнения в нужную атакующему сторону. Microsoft собрал с retpoline обновлённые компоненты ядра Windows и включил их в кумулятивный апдейт для Windows Server 2016.

Важная деталь: retpoline работает вместе с микрокодом, но не требует IBRS для базовой защиты. Это меняет картину с производительностью - IBRS на каждом входе в ядро был главным источником overhead'а в ранних митигейшнах.

Методика: что и как мерили

У нас два типа стендов под Windows Server 2016:

Первый - Hyper-V хост с несколькими гостевыми ВМ: две Windows Server 2016 (одна под AD DS, одна под SQL Server 2016) и пара Linux-гостей для сравнения. Железо - двухсокетный Xeon E5-2680 v4 (Broadwell), 256 ГБ RAM.

Второй - bare metal Windows Server 2016, SQL Server 2016, нагрузка - тот же воркload, чтобы сравнить поведение с гипервизором и без.

Методика намеренно простая - не синтетика ради синтетики, а то что реально гоняется в production:

• SQL Server: HammerDB с TPC-C воркload'ом, 5 warehouses, 10 минут прогрев + 30 минут замер. Метрика - TPM (transactions per minute).
• Дисковая нагрузка: DiskSPD - утилита Microsoft для стресс-теста хранилища. Паттерн: 70% чтение / 30% запись, размер блока 8KB, 16 потоков. Смотрим latency и IOPS.
• CPU baseline: CoreInfo до и после - убеждаемся что mitigation флаги появились.

Снимали три замера до патча, три после, брали среднее. Патч устанавливали через WSUS, перезагружали хост и все гостевые ВМ.

Проверка что mitigation реально включён:

Get-SpeculationControlSettings

Этот командлет из модуля SpeculationControl (Microsoft публиковал его отдельно) показывает какие именно защиты активны - KVAS, IBRS, Retpoline. Без этой проверки «поставил патч» не равно «защита работает» - мало ли какой антивирус не выставил нужный registry key.

Что получилось

На Hyper-V стенде разница в SQL Server TPM оказалась в пределах погрешности замеров - несколько процентов в одну и другую сторону между прогонами. DiskSPD на гостевых ВМ: latency практически не изменилась, IOPS аналогично. Субъективно - ничего не заметили.

Это согласуется с механикой retpoline: если IBRS не включается на каждом переключении контекста, а только retpoline защищает непрямые переходы - overhead на syscall'ах существенно ниже, чем в ранних вариантах митигейшна.

На bare metal картина немного отличалась: под SQL Server нагрузка с высоким числом коротких транзакций дала заметную - но не критичную - просадку TPM. Меньше, чем мы видели на Linux с KPTI без PCID, но ощутимее чем на VM.

Почему на VM лучше? Вероятно, потому что в виртуализованной среде часть syscall'ов уходит через гипервизорные механизмы, которые уже оптимизированы. Hyper-V сам обновился, и взаимодействие гость-хост работает через enlightenment API, а не чистые VM exits. Точную причину мы не копали - это наблюдение, а не утверждение.

Что с Broadwell и микрокодом

Как писали раньше, мы заморозили обновление микрокода для Broadwell/Haswell из-за нестабильного патча Intel. На нашем тестовом стенде с E5-2680 v4 микрокод обновлять не стали - retpoline работает и без него для базовой защиты Spectre V2. IBRS-путь без retpoline с проблемным микрокодом был бы хуже по обоим параметрам: и по стабильности, и по производительности.

Revised microcode от Intel для Broadwell пока не вышел. Как выйдет - обновим и перепроверим.

Практический вывод

На Hyper-V среде с Windows Server 2016 январские патчи прошли практически без заметного влияния на производительность - если правильно проверить что retpoline действительно включился, а не просто патч установлен.

Самое важное в методике - не верить на слово что «патч поставлен = защита работает». Get-SpeculationControlSettings обязателен, как cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 на Linux. Иначе получается что вы несёте overhead от мер безопасности, которые по факту не включились из-за какого-нибудь несовместимого антивируса.

Клиентам на managed-инфраструктуре прогнали апдейты централизованно через WSUS, проверили статус mitigation на каждом хосте. Если у вас Windows Server без проверки - стоит убедиться что всё не просто «обновлено», а именно работает.