Meltdown & Spectre - чи виправлення ядра гостя незавершеного гіпервізора запобігає витоку пам’яті між VM?

Через 24 години після широкомасштабного звільнення вразливості, Rackspace замовчує про Spectre та Meltdown. У них немає плану виправлення всіх своїх гіпервізорів Xen. Всі їх новіші сервери платформи - це сервери HVM, які є вразливими. Старіші PV-сервери не вразливі.

Я оновив ядро ​​Linux моїх гостей HVM, але Rackspace не оновлював жодного їх гіпервізора. Чи буде оновлення гостьового ядра на незавершеному гіпервізорі перешкоджати ВМ «поганому хлопцю» отримати доступ до пам'яті, що просочилася з мого виправленого хоста?

З того, що я розумію вразливості, ні - спекулятивні атаки кешування обходять усі захисні сили процесора проти процесу захоплення пам'яті з будь-якої довільної адреси.

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

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

Привид і розвал.

З чого ми починаємо? погано, я маю на увазі дуже поганий прес-реліз про те, що може або не вплине на ваш комп’ютер, робочу станцію, сервер або сервер у хмарі. Так, це повністю, але ви повинні мати локальний доступ до пов'язаного з процесором, це може бути ПК або телефон, здається, Apple зробила приклад, але дозволяє подумати про свій процесор ARM, так що це кожна мобільна платформа, яка підтримує (функція / експозиція мікрокоду / занадто великий контроль над процесором з ОС / тощо / тощо)

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

Наразі єдиний відомий спосіб використовувати ці вразливості - це через локальний / безпосередній доступ до центрального процесора (знову ж можна віддалено, коли у вас SSH / VNC тощо)

Нижче наведені патчі, які я знайшов поки що.

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm л

Зараз це має бути найкращою відповіддю на питання, яке зараз існує

Що сказали наші друзі з BSD?

Поганий google; (

перевірка Powershell на те саме;)

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

Я можу / повернусь і відредагую цю публікацію. Я впевнений, що невипуск (поки в дикій природі) не буде справжньою проблемою довгий терн. Google справді повинен дотримуватись дат оприлюднення тут! -1 для Google