Что случилось?
Исследователи Google опубликовали исследование «Reading privileged memory with a side-channel», в котором они описывают найденную ими аппаратную уязвимость, которая затрагивает практически все современные и устаревшие процессоры вне зависимости от операционной системы. Строго говоря, уязвимостей целых две. Одной подвержены многие процессоры Intel (на них проводилось исследование). AMD с ARM также уязвимы, но атаку реализовать сложнее.
Атака позволяет получить доступ к защищенной памяти из кода, который не обладает соответствующими правами.
Пожалуй, самое вероятное и неприятное применение на данный момент — получение дампа системной памяти во время выполнения JavaScript.
Другой интересный вариант — эскалация прав чтения памяти из виртуальной машины. Как вам VPS, который ворует данные из других машин хостера?
Эксплуатация уязвимости не оставляет следов.
Насколько это серьезно?
Это очень серьезно. Мир разделится на «до» и «после». Даже если у вас вообще нет компьютера, отдельные последствия косвенно могут догнать вас в офлайне.
Как защититься?
Установить последние обновления системы и браузера. Если вы не уверены в том что дыра точно закрыта и ваша система совершенно точно в безопасности, лучше отключите JavaScript даже при посещении безопасных сайтов — они могут быть скомпроментированы. Некоторые эксперты считают, что программным образом полностью обезопаситься нельзя и единственный способ решить проблему — сменить процессор на
Прекрасные новости, это всё?
Не все. Судя по тестам, патчи сильно повлияют на производительность существующих систем. Тесты показывают падение на 10-30% в некоторых задачах. Да-да, вы все правильно поняли, ваш мак может навсегда стать медленнее, а AWS заметно дороже.
Дополнительные данные
- Оригинальное исследование Google Project Zero
- Описание атаки Meltdown
- Описание атаки Spectre
- Комментарии ARM
- Комментарии AMD
- Комментарии Google
- Комментарии команды Chromium
- Обновления Android
- Экстренный патч для Windows 10
Будьте здоровы!
Комментарии (514)
VioletGiraffe
04.01.2018 09:14Как-то вообще не объясняется серьёзность проблемы. Сдампить чужую память — это одно, а вот найти в ней что-то полезное — совсем другое.
Интересно, можно ли на Windows отказаться от изменений, вызывающих замедление работы. На Linux, вроде бы, можно будет.
CryptoPirate
04.01.2018 11:01Пароли и ключи шифрования в памяти найти относительно просто.
Пароль можно просто подбирать из найденного в памяти. У ключей энтропия выше чем у остальных данных обычно, если при этом мониторить трафик, то можно проверять гипотетические ключи.
С таким объяснением достаточно серьёзно проблема выглядит?VioletGiraffe
04.01.2018 11:04И это всё сможет делать javascript в браузере? Да, я понимаю, что если скомпрометировать популярный сайт, на который зайдёт 100 миллионов пользователей, то у кого-то что-то удастся найти, но в целом — нет, выглядит не очень серьёзно.
CryptoPirate
04.01.2018 11:13+5Из статьи про SPECTRE:
Attacks using JavaScript. In addition to violating process isolation oundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by ounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.
В части номер 4.3 есть больше объяснений.
Не нужно компрометировать популярный сайт, я прямо сейчас на своём сайте пишу яваскрипт (и даю на него ссылку) который из брауера будет таскать всё что может. У вас несколько вкладок открыто? Даже может быть несколько програм (одна из них — менеджер паролей?), так?
А на ссылку, которую я дал, вы нажали? :-)
kekekeks
04.01.2018 11:52-4Вообще в том же хроме JS вкладки крутится в её собственном процессе. Отдельном.
CryptoPirate
04.01.2018 12:31Дело в том, что уже не в процессах дело. Атака Meltdown позволяет добыть данные из ядра и из других процессов (с некоторыми мелкими оговорками). Без разницы где конкретно данные лежат, в отдельном процессе или в том же самом.
VEG
04.01.2018 12:37+1Meltdown и Spectre — разные уязвимости. Возможность что-то сделать из JS заявлена только для Spectre (и то, судя по всему, целенаправленно получить какие-то полезные данные именно с использованием JS там практически нереально). Для Meltdown такого не заявлено.
kekekeks
04.01.2018 12:41+4Она позволяет добыть данные из ядра при условии возможности дёргать нужные сисколы и выполнять нужные инструкции CPU в контролируемых условиях. Из JS этого сделать нельзя, но можно сформировать код, который будет через другую уязвимость из перечисленных читать память своего процесса. Разберитесь в механизме работы, а потом делайте заявления.
VioletGiraffe
04.01.2018 13:45Нужно компрометировать популярный сайт, потому что у вашего сайта посещаемость будет несколько ниже. Это понятно, что можно читать память любого процесса в ОС.
Voenniy
04.01.2018 19:41+2При чем тут посещаемость?
Атака может быть на конкретную группу лиц с использование сайта с нулевой посещаемостью (созданного как раз только для этой атаки).
chicagoist
04.01.2018 09:34Старик Столман был всё же прав.
Dimchansky
04.01.2018 09:55Напомните, в чем именно.
olartamonov
04.01.2018 14:48-1В том, что опенсорс безопасен. Не может в опенсорсе годами жить незакрытая критическая уязвимость.
Был прав.
Был.
Года так до 2014-го.maxzhurkin
04.01.2018 19:06+3Во-первых, Столман говорил о том, что проприетарщина небезопасна. Это не то же самое, что говорить, что опенсурс безопасен. А во-вторых, есть несколько примеров многолетних уязвимостей в опенсурсе
VioletGiraffe
04.01.2018 22:26Вы о HeartBleed?
olartamonov
04.01.2018 23:19+2Да, как наиболее ярком примере.
Разговоры о сранвительной безопасности опенсорса и коммерческой разработки вообще бессмысленны — практика показывает, что и то, и другое может иметь дыру с амбарные ворота размером, которую могут не замечать месяцами, а то и годами. Впрочем, всёрьез слушать Столлмана, особенно когда он опять забывает таблетки принять, тоже не очень осмысленное действие.
Применительно к процессорам же опенсорс — это и вовсе смешно, будет примерно как опенсорсные ноутбуки: очень дорого, очень громоздко и по производительности способно на равных конкурировать со средним вайфай-роутером.Jamdaze
05.01.2018 15:23Вы говорите о малосерийном производстве, когда цена еденицы продукции высока, причём тут опенсорс.
poznawatel
04.01.2018 10:26+3Да, Столман-гений (я абсолютно серьёзно). А процессоростроители заигрались с бекдорами и неустойчивыми архитектурами. Я надеялся, что хотя бы на APM/AMD сбежать получится, но некуда бежать, Карл! Получается, даже Байкал дырявый, остался только Эльбрус? На Байкал у моей фирмы денег ещё хватит, а на Эльбрус — не наскребу :(
EvilBeaver
04.01.2018 11:06+1А Байкал почему дырявый?
poznawatel
04.01.2018 12:24Он на лицензированном ARM-е сделан. Кстати, к вопросу «зачем изобретать велосипед своей архитектуры?»
olartamonov
04.01.2018 14:49Вообще-то на MIPS P5600.
poznawatel
04.01.2018 15:04Посмотрел — действительно, рано я запаниковал, Байкалу Т1 пока можно доверять. Тяжело это, когда в ИТ не работа, а ходьба по трясине, нервы ни к чёрту становятся. Спасибо, что поправили меня.
LeonidY
04.01.2018 23:45На Байкале-Т1 все эти баги не работают с гарантией если первые 128МБ памяти (там только 128МБ из первых 512МБ распределены под память) НЕ используются для user приложений. А к user страницам доступ либо через EVA, либо через HIGHMEM. В текущем ядре используется HIGHMEM, осталось только запретить рапсределять первые 128МБ под страницы user.
Такой запрет, кстати, ускорит работу с DMA, так как не нужен будет второй cache flush.
poznawatel
04.01.2018 18:00+1Разобрался.
Есть Байкал-Т1 MIPS P5600 www.baikalelectronics.ru/products/T1
а есть Байкал-М, он на ARMv8-A www.baikalelectronics.ru/products/M
Второй для меня, естественно, теперь умер.
Infra_HDC
04.01.2018 20:25в тырнете есть кучи проектов процов, например, на основе ПЛИС, только кто для них будет оськи адаптировать… есть сайты, где ссылки на такие проекты собраны десятками, если не сотнями, у каждого проца своя разрядность, программная модель, аппаратная архитектура и система команд.
kahi4
04.01.2018 22:04+1opencores.org и там не все так плохо. Многие ядра пытаются поддерживать wishbone и быть хоть с чем—то совместимым. Вон, OpenRISC даже в космосе побывал и для него есть полноценный тулчеин, даже сборка линукса, а он вроде как даже не самый продвинутый среди открытых архитектур. Проблема в другом — если говорить про асик— нет гарантий, что на заводе ничего в него не дошьют, да и это очень дорого. Если говорить про плис — либо чертовски медленно, либо чертовски дорого (как правило, и то, и другое, если говорить про построение архитектуры общего назначения на плис), да ещё и не на каждую плисину влезет полноценная soc. Но я давно мечтаю собрать на основе маленькой платы с плис типа такой какой-нибудь openphone с чертежами для 3D принтера
dmpalets70
04.01.2018 11:37SPARC наше всё :)
andy_p
04.01.2018 11:54А разве SPARC не всё?
equand
04.01.2018 12:39RISC наше всё :)
svanichkin
04.01.2018 12:48+1ARM тоже уязвимы окзались
kalininmr
04.01.2018 13:27вроде бы не все. только относительно свежие.
сильно древние неуязвимы
beeruser
04.01.2018 22:52Cortex-A55 свежее некуда. Проблем нет. В то время как древний Cortex-A8 уязвим.
SantaCluster
05.01.2018 19:31как Неуловимый Джо :)
khim
05.01.2018 22:04Нет, тут другая история. ARM только недавно занялся спекулятивным исполнением, которое на x86 появилось в Pentium Pro в 20 лет назад.
dmpalets70
04.01.2018 22:50как говорил Егор Гайдар: «Отнюдь»… нынешний М8 только вышел и ещё лет 3-5 будет в теме, а там и ещё что нибудь появится, плюс Фуджи свой 12-й выкатили тоже недавно, так что мои заказчики вполне себе интересуются возможностями SPARC/Solaris, поддержка официально до 2030+
Daniyar94
04.01.2018 13:10Что насчёт IBM Power?
cro Автор
04.01.2018 14:07+1Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian).
access.redhat.com/security/vulnerabilities/speculativeexecution
olartamonov
04.01.2018 14:51+1Есть такой анекдот про поручика Ржевского и оральный секс.
В общем, если у процессора кэш и предсказание ветвлений есть, то Spectre ваш.khim
04.01.2018 14:59В общем, если у процессора кэш и предсказание ветвлений есть, то Spectre ваш.
Спекулятивное исполнение и точный таймер нужны…
RaTT
04.01.2018 17:39Напомните, плз)
olartamonov
04.01.2018 17:49+9— Господин поручик — вы, говорят, большой специалист в этих делах. Скажите, вон та дама в рот берет?
— Которая? — переспрашивает Ржевский.
— Вон та, в желтом платье.
— Ну, я со спины сказать не могу, — пожимает плечами поручик. В этот момент дама поворачивается, поручик Ржевский пристально смотрит ей в лицо и говорит:
— Эта — берет.
Корнет подходит к даме, они о чем-то беседуют и удаляются. Через некоторое время корнет возвращается, довольный:
— Действительно, берет! Но как вы определили, поручик?!
— Послушайте, корнет, — веско произносит поручик Ржевский, — Рот есть — значит берёт!
Примерно та же история с процессорами и Spectre.LeonidY
04.01.2018 23:51> Примерно та же история с процессорами и Spectre.
Если права доступа к страницам ядра проверяются ДО запуска подгрузки в кэш, то остается только eBPF, который сам по себе бяка (JIT в ядре!). К тому же он кажется требует привелегий. Гуглы вроде не нашли в текущем коде ядра Linux подходящих последовательностей помимо возможности сформировать их через eBPF.olartamonov
05.01.2018 00:33Тут два момента.
Во-первых, ядро большое, а подходящие для атаки последовательности могут быть разными, так что что там найдётся в конкретной версии ядра, собранной конкретным компилятором с конкретными настройками — это ещё бабка надвое сказала. Там не очень-то много надо.
Во-вторых, авторы второй работы, не гуглевской, вообще с ядром не заморачивались, а просто взяли DLL'ки, используемые их софтиной, и поискали нужную последовательность в них, резонно предположив, что эти же DLL'ки с большой вероятностью будут шариться с другими процессами.
Так что eBPF просто радикально облегчает задачу, но не более того.LeonidY
05.01.2018 01:25DLL? С учетом того, что их пишет кто попало… там и просто так можно такой код зафигачить, что никакого meltdown/spectre наверно и не надо.
encyclopedist
05.01.2018 02:27Имеется ввиду, что системные и широкораспространённые DLL уже содержат нужные последовательности инструкций. Злоумышленнику даже не нужно свой код на вашу машину тащить, всё нужное там уже есть.
Kolbasyatin
05.01.2018 03:15и вдруг в этот момент шутки про Эльбрус уже не так смешны. И получается что оборонка в РФ, где используется Эльбрус работает, а остальной мир — нет (конечно я про фантастический рассказ).
sova
05.01.2018 06:21о том какие косяки есть в оборонке и Эльбрусе просто меньше народу знает также как и меньше народу вообще их там ищет. Так что шутки актуальны
OnYourLips
04.01.2018 12:24+1Конечно прав.
Но недостаточно быть правым, надо и альтернативу предлагать, причем не абы какую, а экономически жизнеспособную.
Более того, Столлман сам использует закрытое железо: Thinkpad T400s.
И процессор у него Core 2 Duo SP9400, который тоже может быть подвержен этой уязвимости.si1n3rd
04.01.2018 13:43Верно, Столлман критиковал Intel за ME, которого в его процессоре нет. Об этой уязвимости он не говорил, но и его процессор попал под раздачу.
poznawatel
04.01.2018 16:54Столлман не пользуется JS.
si1n3rd
04.01.2018 18:01Да он и браузером толком не пользуется. У него вообще там какой-то странный выход в Интернет.
potan
04.01.2018 15:38Помню он заявлял, что использует китайский ноутбук на MIPS с открытым BIOS.
dartraiden
04.01.2018 15:46Проапгрейдился. По ссылке же написано:
Before that, I used the Lemote Yeeloong for several years.
UksusoFF
04.01.2018 09:54А где-то есть список подверженных этому CPU?
blind_oracle
04.01.2018 09:58+5Все интел, выпущенные за последние 10 лет :)
qwert_ukg
04.01.2018 11:14Кроме Атомов до 2013 и Итаниумов
asdoc
04.01.2018 12:16Т.е. если машина старше 10 лет, то 100% проблемы нет? И если АМD до 13-го года?
Jeditobe
04.01.2018 13:40На АМД нет Мелтдауна, только Спектра
perfect_genius
06.01.2018 07:12Вам теперь тоже придётся реализовать защиту?
Jeditobe
06.01.2018 15:29Пока в этом нет особой необходимости.
Спектра исправляется\локализуется на стороне каждой прикладной программы в отдельности. А Мелтдаун опасен в основном для многопользовательских систем с множественным доступом различных субьектов, между которыми нет доверия. У РеактОСа же в самой ближайшей перспективе наиболее реалистичные сценарии использования предполагают однопользовательский доступ в изолированных сегментах инфраструктуры.
Еще важно отметить, что в РеактОС существующие средства доставки и инжекции вредоносного ПО на данный момент не способны выполнить свою функцию.
Безусловно, в дальнейшем определенные механизмы безопасности будут внедрены, а пока мы посмотрим, как с этим справятся остальные вендоры и воспользуемся их опытом.
encyclopedist
05.01.2018 02:32Там пишут, что предположительно вообще все когда либо выпущенные 86 процессоры Интел с спекулятивным исполнением. А это с 95 года. Просто в стоей работе авторы продемонстрировали уязвимость на сравнительно новых процессорах.
UksusoFF
04.01.2018 13:02Еще бы помнить когда он выпущен.
blind_oracle
04.01.2018 13:51+1ark.intel.com поможет.
Но, на самом деле, сложно выяснить есть ли в том или ином процессоре этот баг т.к. потроха процессора закрыты и как он обрабатывает инструкции — покрыто мраком.
Единственный выход, который мне видится — запускать PoC эксплоит (найти бы его еще) на каждом из них и смотреть результат.
BubaVV
04.01.2018 12:11+29Вот например на П4 дыру вообще видно невооруженным взглядом:
MacIn
05.01.2018 00:11+1Для того, чтобы произвести запись в
write-protectedзащищенную область, отверстие надо заклеить изолентой?
un1c0de
05.01.2018 00:08Вот единственная конкретика, которую удалось найти на сайте intel.
Which Intel-based platforms are affected by or vulnerable to the issue?The following Intel-based platforms are impacted by this issue. Intel may modify this list at a later time.
Please check with your system vendor or equipment manufacturer for more information regarding your system.
Intel® Core™ i3 processor (45nm and 32nm)
Intel® Core™ i5 processor (45nm and 32nm)
Intel® Core™ i7 processor (45nm and 32nm)
Intel® Core™ M processor family (45nm and 32nm)
2nd generation Intel® Core™ processors
3rd generation Intel® Core™ processors
4th generation Intel® Core™ processors
5th generation Intel® Core™ processors
6th generation Intel® Core™ processors
7th generation Intel® Core™ processors
8th generation Intel® Core™ processors
Intel® Core™ X-series Processor Family for Intel® X99 platforms
Intel® Core™ X-series Processor Family for Intel® X299 platforms
Intel® Xeon® processor 3400 series
Intel® Xeon® processor 3600 series
Intel® Xeon® processor 5500 series
Intel® Xeon® processor 5600 series
Intel® Xeon® processor 6500 series
Intel® Xeon® processor 7500 series
Intel® Xeon® Processor E3 Family
Intel® Xeon® Processor E3 v2 Family
Intel® Xeon® Processor E3 v3 Family
Intel® Xeon® Processor E3 v4 Family
Intel® Xeon® Processor E3 v5 Family
Intel® Xeon® Processor E3 v6 Family
Intel® Xeon® Processor E5 Family
Intel® Xeon® Processor E5 v2 Family
Intel® Xeon® Processor E5 v3 Family
Intel® Xeon® Processor E5 v4 Family
Intel® Xeon® Processor E7 Family
Intel® Xeon® Processor E7 v2 Family
Intel® Xeon® Processor E7 v3 Family
Intel® Xeon® Processor E7 v4 Family
Intel® Xeon® Processor Scalable Family
Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
Intel Atom® Processor C Series
Intel Atom® Processor E Series
Intel Atom® Processor A Series
Intel Atom® Processor x3 Series
Intel Atom® Processor Z Series
Intel® Celeron® Processor J Series
Intel® Celeron® Processor N Series
Intel® Pentium® Processor J Series
Intel® Pentium® Processor N Seriesdenis-isaev
05.01.2018 02:13Странно, у меня Skylake (14нм) и уязвимость есть, судя по тесту вот этой штукой: gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6
Varim
05.01.2018 03:08denis-isaev
05.01.2018 03:40Точняк, только я запутался тогда, а чем отличаются в списке выше пункты:
Intel® Core™ i5 processor (45nm and 32nm)
2nd generation Intel® Core™ processors
claygod
05.01.2018 22:03Пока из не подверженных риску я вижу только Атомы серии D (D2700, D2550, D2500), есть что-то ещё?
Idot
04.01.2018 10:11+4лучше отключите JavaScript даже при посещении безопасных сайтов
Нормально пользоваться Хаброй с отключённым JS — возможно?
(не говоря уже об обычных сайтах сплошь увешанных js)ZaitsXL
04.01.2018 11:01-7Тут уже вы сами решайте что вам надо — рюшечки на сайтах или безопасность
Mingun
04.01.2018 11:06+12Проблема в том, что js — уже давно далеко не «рюшечки на сайтах», а основной функциональный элемент, отключение которого смерти подобно (этого самого сайта).
ZaitsXL
04.01.2018 11:30-5Опять же — сами решайте что вам важнее
Akuma
04.01.2018 13:51+1В нашем мире можно удалить браузер, а не выключать JS. Эффект будет примерно одинаковым. Вы даже комментарии здесь писать не сможете без JS
SADKO
04.01.2018 21:10А чего все докопались до JS? Его то как раз таки можно быстренько из
поганитьправить :-)
Что видимо и произойдёт в ближайшие дни.
Caravus
04.01.2018 21:16-2Ох, я очень надеюсь что эта ситуация выдаст пинка проблеме с JS и его наконец выпилят и заменят на что-то современное, ах мечты-мечты…
VEG
04.01.2018 21:20+1Проблема же не в JS.
Massacre
05.01.2018 05:59Так-то да, проблема в принципе в коде, который может исполняться просто от открытия веб-страницы, но JS — самое распространённое зло здесь (менее распространённые — Flash, Java, к примеру).
А без JS хабр вполне возможен, если напишут отдельную версию — сделать простую форму для написания статьи/комментариев.
FoxNULL
04.01.2018 12:36+1Для хрома Google вроде как рекомендует включить chrome://flags/#enable-site-per-process если у вас версия ниже 64
equand
04.01.2018 12:41-1И как это спасет?
Это как для защиты от ядерной бомбы используйте бронежилет.VEG
04.01.2018 12:45+1Спасёт от теоретической возможности утечки данных чужих сайтов с использованием атаки Spectre из JS на каком-нить сайте. Разве что сам у себя сайт сможет что-то подглядеть случайно :)
olegator99
04.01.2018 10:35-1Интрига дня/недели: подвержены ли процессоры Apple?
Tippy-Tip
04.01.2018 10:48+5Разве Apple вернулась на Motorolla в своих дескотпах/ноутбуках?
olegator99
04.01.2018 10:53+3Речь про iPhone/iPad — Apple для них пилит свои ARMv8 -совместимые процессоры. У оригинальных ARM Cortex-Axx самой опасной уязвимости (чтение памяти ядра/других процесов) подвержены только Cortex-A75.
Информации об наличии/отсутствии проблем в процессорах Apple-A пока нет. Ждем!
progressor7
04.01.2018 10:53+1У Apple те же самые интеловские процессоры — поэтому да, конечно.
olegator99
04.01.2018 10:54+2https://ru.wikipedia.org/wiki/Apple_Ax я про эти.
progressor7
04.01.2018 13:12Одна из атак (Spectre) работает на ARMах тоже, но я не знаю про те конкретные которые iPhone/iPad.
olegator99
04.01.2018 14:22Spectre с большой вероятностью работает на всех ipad/iphone. Практически все современные ARM ядра ей подвержены.
Meltdown подвержены только ядра ARM Cortex-A75 (на них еще нет выпущенных процессоров)
Однако, Apple не использует готовые ядра Cortex, а разрабатывает ядра сама. На текущий момент нет информации об атаке Meltdown на ARM ядра Apple. Вот ждемс информацию.
ZaitsXL
05.01.2018 00:41думается Pentium MMX и прочие древности наверное не подвержены, но что нам с того?
VEG
04.01.2018 10:37+5Пожалуй, самое вероятное и неприятное применение на данный момент — получение дампа системной памяти во время выполнения JavaScript.
Больше похоже на заявление от представителей жёлтой прессы. Низкоуровневые операции (типа получения данных по произвольному указателю), которые скорее всего будут нужны для эксплуатации уязвимости, из JS недоступны. В общем, или покажите рабочий пруф, или не распространяйте сомнительную информацию и не нагнетайте бесполезную панику.olegator99
04.01.2018 10:48+1В первоисточнике есть JS сниппет, который читает память процесса браузера https://spectreattack.com/spectre.pdf, эта ссылка есть в статье...
VEG
04.01.2018 11:43+3Во-первых, рабочего кода там нет. Там есть только вот эти 5 строк, которые лишь маленький кусочек необходимого кода (содержимое остального кода там описано словами и очень примерно):
Во-вторых, чтение памяти своего процесса (где живёт вкладка) и получение дампа всей системной памяти — разные вещи. В-третьих, не заявлено, что можно целенаправленно прочитать всю память своего процесса из JS. Как я вижу, с использованием этой методики максимум могут быть сделаны выводы о содержимом каких-то случайных блоков памяти своего процесса, в зависимости от того куда при выполнении JS была физически помещена переменная массива.if (index < simpleByteArray.length) { index = simpleByteArray[index | 0]; index = (((index * TABLE1_STRIDE)|0) & (TABLE1_BYTES-1))|0; localJunk ^= probeTable[index|0]|0; }CryptoPirate
04.01.2018 11:49+5Полного рабочего кода там быть и не может по определению, у white hat исследователей не принято эксплоиты такой величины публиковать чтобы каждый дурак мог копировать и использовать.
VEG
05.01.2018 09:07Вчитался в доку Spectre. Рабочего кода на JS там нет, но описания достаточно, чтобы его повторить. Тем более, что в конце дока есть рабочий код на C, демонстрирующий основную идею.
Итого у нас есть возможность узнавать содержимое байтиков за пределами выделенного JS-массива. Его физический адрес мы не знаем, но изучив как JS-движок хранит переменные в куче, возможно где-то рядом с массивом мы сможем найти какой-нибудь указатель, который подскажет где мы вообще физически находимся. С этим, возможно, дальше будет немного проще плясать.
Но вообще активная эксплуатация всё ещё выглядит сомнительной. Скорость «чтения» будет очень маленькой. Как я понимаю, даже пример на C читает где-то 1000-2000 байт в секунду. Всё адресное пространство не прочитаешь с такой скоростью за разумное время, явно нужно точно знать куда смотреть относительно того куда в памяти попал этот JS-массив.
Плюс на 64-битных системах у нас вырисовывается ограничение, что мы можем «смотреть» только в окошко размером в 4 гигабайта, поскольку инты в JS 32-битные. Таким образом, использование Meltdown из браузера также сильно осложнено — весьма вероятно, что до интересных системных структур мы просто не сможем дотянуться, даже если сможем прикинуть где они относительно нашего массива находятся.
Не в курсе как там в JS, а для выполнения WebAssembly на 64-разрядных системах слышал что намеренно резервируется адресное пространство размером в 4 гигабайта, потому что указатели внутри WebAssembly 32-разрядные, и уверенность что они не могут выйти за пределы своего окошка позволяет делать меньше проверок во время выполнения.
olegator99
04.01.2018 11:59+1Согласен, сейчас пример кода на уровне "proof-of-concept", и читать всю системную память он не сможет by design/
Однако, в голову приходит такое практическое применение дырки — найти в памяти куки (в памяти сандбокса вполне могут остаться куки от ранее посещенных во вкладке страниц), и утащить себе валидные session_id/token-ы от чужих сервисов.
Конечно, задача не тривиальная, но увы, кажется решаемая.
khim
04.01.2018 15:08Во-вторых, чтение памяти своего процесса (где живёт вкладка) и получение дампа всей системной памяти — разные вещи.
После установки вот того самого патча, который обещает всё замедлить на 30% — да.
Сейчас операционки устроены так, что в них сразу вся физическая памяти размапирована в таблицах всех процессов — просто к ней нет доступа из-за соотвествующих прав на память. Но спекулятивное исполнение на это плюёт!
То есть любой процесс может потихоньку-полегоньку прочитать всю память всех процессов на всей системе.DistortNeo
04.01.2018 16:06Насколько я понимаю, единомоментно в таблицах сидит только память текущего процесса и ядра. То есть читать можно только ядро, а в чужие процессы попасть получится, только если получится поднять привелегии до рута по результатам чтения памяти из ядра.
interprise
04.01.2018 16:08Это актуально, только для 32 битных операционных систем. Для x64 немного сложней и как я понимаю это приводит к тому, что можно читать и соседний процесс.
MooNDeaR
04.01.2018 16:45В 64х битных Linux-ах, например, вся память смаплена в ядро, соотвтетсвенно имея доступ к памяти ядра, можно иметь доступ к любой странице
khim
04.01.2018 17:56+1В 32-битных также было долгое время. Когда память перевалила за 950MB — начались пляски с бубнами и замедлением. В 64-битных системах от них отказались.
MacIn
04.01.2018 19:19Когда память перевалила за 950MB
Что вы имеете в виду?khim
04.01.2018 23:40На «старых» операционных системах (Windows 9X, Linux 1.x, NT не помню до какой версии) адресное пространство делилось 3GB/1GB и в том 1GB, которое доставалось ядро ко всему прочему жил ещё и полный линейным маппинг физической памяти. Это никого не напрягало, так как тогда 64MB — было огромным обьёмом, а об 1GB можно было только мечтать. Реально система могла стартовать где-то с 950MB с простенькой видеокартой и с 750-800MB если использовался продвинутый ускоритель.
Потом объёмы памяти росли, 64бита всё никак не приходили и пришлось пристраивать костыли… когда 64бита, наконец, пришли, от костылей, разумеется, отказались.MacIn
05.01.2018 00:09Ясно, спасибо. Я теперь вспомнил про старую технику чтения физической памяти, которая работала в старых NT как раз из-за этой особенности.
khim
04.01.2018 17:59Насколько я понимаю, единомоментно в таблицах сидит только память текущего процесса и ядра.
Ага. Только «память ядра» по умолчанию включает в себя, в том числе, прямой доступ ко всей физической памяти системы.
Так просто удобнее и быстрее. На 32-битных системах с более, чем гигабайтом памяти, приходится плясать. На 32-битных системах с 950MB памяти (и менее), можно «не париться»… вернее «можно было».
MacIn
04.01.2018 19:17Это происходит только в плоской модели? В случае сегментации, насколько я понимаю, такой трюк не прокатит.
mayorovp
04.01.2018 21:26+2В long mode отказались же от сегментации.
MacIn
04.01.2018 22:16Я знаю. И спрашиваю конкретно про модель с сегментацией. Ведь если для чтения ядерной памяти надо загружать ядерный же селектор из GDT с DPL=0, что выкинет исключение при RPL=3, то до спекулятивного доступа к «запрещенной» ячейки памяти черед не дойдет. Верно?
qw1
04.01.2018 22:30Игнорирует ли чтение при спекулятивном выполнении ограничение на размер сегмента? Вероятно, игнорирует, раз игнорирует защиту страниц.
Практическая ценность этого вопроса какая? В известных мне ОС не делают разделение kernel и user с помощью непересекающихся сегментов. Проверять не на чем.MacIn
04.01.2018 22:32Игнорирует ли чтение при спекулятивном выполнении ограничение на размер сегмента?
Сегмент может быть расположен «вверху», а данные ядра — внизу. Теоретически. Не все АП может быть смаппировано. Ну, допустим, не проверяет, но там сверху — просто дыра, не мапированная на физическую память.
Практическая ценность этого вопроса какая? В известных мне ОС не делают разделение kernel и user с помощью непересекающихся сегментов. Проверять не на чем.
Думаю о своей хоббийной ОС, где такое разделение есть.
Я бы проверил из любопытства, но пока еще детально не понял механизм эксплуатации, только косвенно по вашим комментариям про array1 и данные кеша, буду читать техническое описание уязвимости позже.qw1
04.01.2018 22:52Сегмент может быть расположен «вверху», а данные ядра — внизу. Теоретически.
In 64-bit mode, segmentation is generally (but not completely) disabled, creating a flat 64-bit linear-address space. The processor treats the segment base of CS, DS, ES, SS as zero, creating a linear address that is equal to the effective address.
© System Programming Guide, Chapter 3.2.4
Получается, ОС 32-битная, раз можно рулить сегментами? Странно вкладываться в умирающую архитектуру, но хобби бывают всякие.MacIn
04.01.2018 22:59Получается, ОС 32-битная, раз можно рулить сегментами? Странно вкладываться в умирающую архитектуру, но хобби бывают всякие.
Да. Ну так и проекту больше 15 лет.
khim
04.01.2018 23:42Ведь если для чтения ядерной памяти надо загружать ядерный же селектор из GDT с DPL=0, что выкинет исключение при RPL=3, то до спекулятивного доступа к «запрещенной» ячейки памяти черед не дойдет. Верно?
Неверно. Всё это проверяется уже потом, при «нормальном» исполнении (вернее при «отставке» операций). Спекулятивное же на всё это плюёт, так как если «случится бяда» — то этого же всё равно никто не увидит.MacIn
04.01.2018 23:55Верно, но при этом у нас будет на одну инструкцию больше — сначала загрузка селектора, что емнип достаточно долгий процесс, потому что надо подгрузить теневую часть из таблицы, и только потом сама инструкция доступа к памяти, спекулятивное выполнение которой можно использовать. Я не уверен, просто кажется, что более долгая цепочка — ве инструкции, которые должны выполнится спеклятивно вместо одной — не позволят или затруднят использование этой уязвимости. Или глубина сп. выполнения намного глубже?
MacIn
05.01.2018 00:14Ах да, я протупил. В таком случае мы можем и локальный селектор использовать, если ничего не проверяется при сп. выполнении и можно «свернуть» память через переполнение.
khim
05.01.2018 01:21Или глубина сп. выполнения намного глубже?
А вы посчитайте. Длина конвеера — 12-14 тактов, одновременно современные CPU могу исполнять 3-4 инструкции за такт… так что теоретически могут исполняться спекулятивно полсотни инструкций и больше, а практически 10-20 — в лёгкую.MacIn
05.01.2018 11:44Логично. Ну, тогда действительно разницы нет.
MacIn
05.01.2018 14:03Хотя, все зависит от того, на какой стадии проверяются права доступа при загрузке селектора. Его же надо загружать из памяти, и последующая инструкция чтения из запрещенной области не может быть исполнена спекулятивно в параллели, потому что надо рассчитать смещение, которое нельзя расчитать до загрузки селектора.
Но да, это неважно, если сработает трюк с переполнением адреса локального сегмента.
mickvav
04.01.2018 21:52Ну, прочитать все же не в едином и консистентном состоянии, конечно — там порядки величин — 1000 байт в секунду, так что это все же на уровне «погрепать в надежде, что попадется что-то интересное». Но при массовой атаке оно у кого-нибудь да найдется…
khim
04.01.2018 23:45Имея доступ ко всем структурам ядра и всей памяти можно много чего найти даже читая со скоростью 1000 байт в секунду…
ushliy
04.01.2018 10:59-1Вот и пруфов подвезли
twitter.com/misc0110/status/948706387491786752/photo/1VEG
04.01.2018 11:04+2Ваш пруф явно выполняется не в браузере.
MooNDeaR
04.01.2018 11:47Сие как бы ни разу не улучшило ситуацию. Процесс-перехватчик запущен не из-под рута, а получил доступ к памяти другого процесса — замечательно.
VEG
04.01.2018 11:51+5В моём изначальном сообщении, на которое вы ответили, я указал, что JS не даёт возможности обратиться за данными по произвольному указателю. Нет такой операции как класс. Вы привели пример совершенно не в тему, поскольку у вас запускается нативный код, у которого проблем с использованием произвольных указателей нет.
lassana
04.01.2018 13:44+2blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack
Our internal experiments confirm that it is possible to use similar techniques from Web content to read private information between different origins.
Я бы не ждал готовых эксплоитов до релизов патчей для всех популярных ОС.
qw1
04.01.2018 19:38+1Низкоуровневые операции (типа получения данных по произвольному указателю), которые скорее всего будут нужны для эксплуатации уязвимости, из JS недоступны
Для атаки нужно иметь код, работающий с массивом, данные в котором мы контролируем (что нам легко сделает jit-компилятор), нужны точные таймеры (например, на web-workers, если обычный таймер загрублён js-движком), и нужно знать адрес буфера в процессе браузера. Последнее есть проблема, хотя её решает другой эксплойт — AnC.
Darknet
04.01.2018 11:02+3Маки пропатчили в 10.13.2, никто даже и не заметил.
vsespb
04.01.2018 11:21+5они думали что просто батарейка на маке стареет и он работает медленне, чтобы неожиданно не выключиться
xlenz
04.01.2018 13:04Заметил, но не знал почему. Субъективно на быстродействие не повлияло, а батарею стало жрать больше практически на 20%
Mingun
04.01.2018 11:03+5От статьи таки ожидал хоть каких-нибудь технических подробностей: что за уязвимость, как обнаружили и т.д., а под катом всего лишь куча ссылок. Нехорошо.
cro Автор
04.01.2018 11:13-2Мне показалось бесполезным портить удовольствие, спойлерить и пересказывать оригинальные документы (вот же, приложены) — там все великолепно раскрыто и описано.
Mingun
04.01.2018 11:21+15Ну, а мне показалось бесполезным читать статью ни о чём.
cro Автор
04.01.2018 14:03+5Вам нужна развернутая лекция и перевод первоисточника? Я с удовольствием дополню статью попозже, когда руки дойдут. Просто события разворачиваются довольно стремительно, на западных площадках все коллективно чешут головы и консолидируют информацию сообща.
Я написал первый быстрый пост за 10 лет на хабре в надежде, что он пригодится хотя бы паре тысяч людей и не ожидал, что приложенного подробнейшего академического документа с примерами будет мало для первичного ознакомления. Если лично вам все это не оказалось полезным, извините что не оправдал ожиданий.bigfatbrowncat
04.01.2018 14:53Было бы полезно сжато, в двух словах, изложить суть уязвимости (разумеется, если вы сами ее понимаете). Так сказать, идею. Для неспециалистов.
А пока что я прочитал весь ваш текст (не ходя по ссылкам на первоисточники) и половину комментариев. И самое интересное, что увидел — это ГИФка в твите, где хоть внешне иллюстрируется, как один процесс тащит данные из другого.
vconst
04.01.2018 19:07+1А я вообще только ради комментариев сюда зашёл, как и ожидал — получил информации намного больше, чем в статье.
pftbest
04.01.2018 11:17+3AMD с ARM также уязвимы, но атаку реализовать сложнее.
AMD уязвим только к первому виду атаки, и закрыть уязвимость можно без потери производительности. Не надо их в одну кучу с интелом и армом смешивать.
kryvichh
04.01.2018 15:50То есть если не хотим на 10-30% замедлять работу системы, дружно топаем на AMD? Благо они в 2017 году выкатили новые приличные процессоры Zen.
Вообще как так вышло, что AMD обошла чаша сия?willyd
04.01.2018 16:00Я почему-то не уверен, что найду достойную рабочую станцию типа ZBook/EliteBook на AMD. :(
phprus
04.01.2018 18:18+1От SUSE пришла рассылка с обновлением kernel-firmware и описанием:
— Add microcode_amd_fam17h.bin (bsc#1068032 CVE-2017-5715)
This new firmware disables branch prediction on AMD family 17h processor
to mitigate a attack on the branch predictor that could lead to
information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715).
17h — это как раз Zen. В свете такого описания мне очень интересно, во сколько раз отключение предсказания переходов уменьшит производительность этих процессоров.khim
04.01.2018 18:35+7Очень надеюсь что отключаются какие-то эвристики, а не предсказание ветвлений целиком.
Без предсказания ветвлений современный процессор — гроб с музыкой, замедление в разы.
LeonidY
05.01.2018 00:44У AMD нету TSX-NI, и заставить через него срабатывать спекулятивную загрузку не получится. Не знаю правда что там с Advanced Synchronization Facility (ASF), может ли он быть тут использован.
Кроме того, такое впечатление, что AMD проверяет доступ до того, как запускает операцию загрузки в кэш.
То есть, остаются только JIT exploit типа eBPF.ToSHiC
05.01.2018 02:13В оригинальной статье про meltdown утверждается следующее:
However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indicating
that out-of-order execution generally occurs and
instructions past illegal memory accesses are also performed.LeonidY
05.01.2018 02:37Toy example будет работать скорее всего везде, на любом процессоре. Но его еще надо запустить в ядре. eBPF — один способ, код для conditional branch с перекодированием — другой. Но их надо еще разместить в ядре, правильно воспользоваться и ухитриться очищать правильно кэш.
AxaRu
04.01.2018 11:26-4Все это очень похоже на большой фейк.
Нет ссылок ни на тестеров ни на объективные результаты.
Скоро напишут, что при открытии двери в туалет замедляется работа кэша второго уровня.
qwert_ukg
04.01.2018 11:33А как же эта «пруф-гифка» twitter.com/misc0110/status/948706387491786752/photo/1 из комента повыше? :)
entze
04.01.2018 21:00Нет, всё это похоже на Heatbleed, когда сначала утверждалось что всёвиврете, а потом вышли очень наглядные пруды и сомнений (надеюсь) не осталось.
Armleo
05.01.2018 00:24Нет не фейк. Обе уязвимости. Почитайте на оф. сайте уязвимостей. Черным по белому, для простых смертных написанно, как эксплуатировать. Как новичок-специалист я могу сказать, что такие уязвимости имеют место быть, иногда даже в менее страшной форме и тем не менее на этот раз оно оказалось в настолько важном месте.
Evgeniy112
04.01.2018 11:27AMD с ARM также уязвимы, но атаку реализовать сложнее.
а можно немного подробнее? насколько сложнее? какие векторы атаки возможны?GalVorbak
04.01.2018 17:55+1В интернетах гуляет эта картинка
poxvuibr
04.01.2018 22:57Из этой картинки следует, что проблем у процессоров AMD под windows нет. И под линукс тоже нет, если ты сам ядро не твикал. Это правда так?
olartamonov
04.01.2018 23:29Про Meltdown — правда (точнее, теоретическая возможность повторить его на AMD есть, но практически она не реализована и даже не показано, что она в принципе реализуема).
Про Spectre — нет.
Вот демонстратор, там в комментариях народ развлекается с самыми разнообразными процессорами, начиная аж с Pentium M, и под разными ОС. В основном интелы, но AMD тоже есть, на них тоже работает.
Кроме того, один из вариантов Spectre AMD официально признаёт как работающий с пометкой «software update to be made available».kryvichh
04.01.2018 23:35Negligible performance impact expected.
В этом вся разница. Ошибки были, есть и будут. Но если они исправляются практически без потери производительности — то это приемлемо. Наверное…olartamonov
05.01.2018 00:00Со Spectre всё сложно, см. spectreattack.com/spectre.pdf (особенно пункт 7).
Объём трудозатрат на исправление софта исходя из имеющихся данных трудно оценить даже по порядку (точнее, попробовать можно, но эта оценка вызывает ужас).kryvichh
05.01.2018 01:13В документе от AMD говорится о патчах ОС / ПО, которых достаточно для нейтрализации Spectre на системах AMD. Непонятно, достаточно ли будет патча ОС и/или браузера, чтобы предотвратить воровство паролей через JS, использующий Spectre. Также непонятно, если в пропатченной ОС будет запущен вирус с правами пользователя, сможет ли он получить доступ ко всей оперативной памяти системы используя Spectre.
olartamonov
05.01.2018 01:34Это вообще не документ, а так, временная затычка.
Фразу «нам необходимо пропатчить всё существующее ПО в неизвестном количестве мест» тоже можно закончить на «и этого будет достаточно для нейтрализации Spectre».encyclopedist
05.01.2018 02:48Для Clang и GCC уже есть патчи которые защищают от SPECTRE
LeonidY
05.01.2018 07:54Где?
encyclopedist
05.01.2018 17:04LeonidY
05.01.2018 23:26Вообще-то я не понимаю, почему они сосредоточились только на переходе по регистру. Простой условный переход, условие которого вычисляется в зависимости от неизвестного в данный момент значения может скорее всего вызвать выдергивание кэш строки по известному адресу в команде загрузки сразу за этим переходом.
Я не силен в x86 ассемблере (забыл его), но что-то типа
— вычисление условия А, например по слову из памяти или как последнее в цепочке вычислений
— условный переход по условию А, который всегда выполняется в нормальной ситуации
— загрузка слова по регистру, который известен задолго до и который содержит «нехороший» адрес.
В нормальном выполнении загрузка никогда не срабатывает, так как условный переход идет нафиг всегда. При спекулятивном выполнении есть большой соблазн запустить эту загрузку на всякий случай заранее, хотя в момент запуска еще не известно значение условия А. Приплыли.khim
06.01.2018 00:12При вашем подходе нужно, чтобы «нехороший код» не только был внутри процесса, но и исполнялся. При переходе по содержимому регистра можно заставить «спекулятивно исполнить» вообще любой код!
LeonidY
06.01.2018 05:26Так такой «нехороший код» гораздо чаще в ядре или программе случается! И защититься от него много сложнее через LLVM/gcc.
Но почитав о чем народ талдычит, складывается впечатление, что якобы Интел не делает speculative пока по коду не проползет несколько раз циклом(!) Очень странная мысль, я сидел на одном семинаре где они хвастались, что они просматривают вперед аж на 3 условных перехода длинным pipeline — нахрена тогда им это делать то?
Или это конкретный процессор такой, а народ и не знает?
Это насчет того, сработает нехороший код или нет.khim
06.01.2018 05:56Это насчет того, сработает нехороший код или нет.
У меня есть ощущение, что вы за деревьями лес потеряли. Intel действительно применяет массу эвристик, чтобы правильно предсказать ветвление — но нам-то нужно, чтобы произошло строго противоположное: весь профит получается на основании спекулятивного исполнения кода, который исполняться не должен.
Вот вы тут пишете:
При спекулятивном выполнении есть большой соблазн запустить эту загрузку на всякий случай заранее, хотя в момент запуска еще не известно значение условия А. Приплыли.
Процессор не исполняет ничего «на всякий случай». Он не пытается «хватать» инструкции «где-то рядом» с потоком исполнения и рандомно их исполнять — это бессмысленно. На некоторых CRAY системах пытались одновременно спекулятивно исполнять команды на обоих ветвях после перехода… идея себя не оправдала. У всех же современных процессоров предсказывается один «магистральный путь движения» программы.
Если загрузка после проверки «спекулятивно сработала» (а потом не понадобилась) — то это значит, что предсказатель переходов сработал неверно. За последние четверть века Intel потратил не один миллиард долларов на то, чтобы снизить вероятность такого события.
А вы предлагаете на это событие, случающееся с ничтожной вероятностью, полагаться. Не надо так.
khim
04.01.2018 23:49Из этой картинки следует, что проблем у процессоров AMD под windows нет. И под линукс тоже нет, если ты сам ядро не твикал. Это правда так?
Нет, неправда. Просто для эксплуатации нужны определённые данные в ядре, которые пока неизвестно как занести. То есть кто-нибудь когда-нибудь, скорее всего, придумает как это сделать — но на это может потребоваться и несколько недель (тогда всем будет очень больно) и несколько лет (тогда это будет просто «сказкой на ночь»).LeonidY
05.01.2018 00:52Ну если можно сделать это — «занести определенные данные в ядро», то никакой meltdown/spectre уже и не нужен, между прочим.
willyd
05.01.2018 01:22Вроде как у людей PoC работает на AMD и на линукс и на win 10, без включения модулей ядра.
gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6LeonidY
05.01.2018 02:08Насколько я понимаю, этот код всего лишь доказывает, что можно использовать определеные последовательности для запуска misprediction load при условном переходе и размещении данных в кэше. Для реальной эксплуатации все еще нужны определённые коды в ядре (victim_function при правильной оптимизации и запуске ), которой можно разбрасывать этот mispredicted load в зависимости от значения читаемого байта по разным кэш строчкам.
Да, это все еще опасно, гарантировать сложно. Некоторый код ядра делает именно эти операции (криптографический хэш, например).
AlexanderS
04.01.2018 11:48Некоторые эксперты считают, что программным образом полностью обезопаситься нельзя и единственный способ решить проблему — сменить процессор на вариант без асбеста заведомо безопасный.
А безопасный — это какой? Я так понял вся линейка от интела болеет этим. Менять вообще всю платформу как-то не хочется. В моём случае получается только патч?
PapaBubaDiop
04.01.2018 12:10+2Вас мотивируют купить новый процессор. В новом же страшилки устранят?
AlexanderS
04.01.2018 12:53+1Вот, кстати, интересный вопрос. Я вот недавно собрал товарищу комп на шестиядерным двенадцатипотоковым Coffee Lake с разблокированным множителем. Процессор явно недешевый. И тут такое дело. Гарантия на процессор — 36 месяцев. Вот если бы наличие подобной уязвимости было гарайтийным случаем… я думаю у интела была бы другая стратегия, а не выкатывание нового ядра раз в пару лет)
theRavel
04.01.2018 11:51-1Я не совсем понимаю: уязвимость в CPU фиксится на уровне ОС. Может тогда это все-таки уязвимость в ОС?
kekekeks
04.01.2018 11:56+11На уровне ОС это "починили" следующим образом: они на выходе из сискола сбрасывают ряд кэшей процессора, через которые "утекают" данные, плюс заанмапили полностью kernel address space, а не только защитили от чтения/записи, так что надо теперь восстанавливать/убирать. Процесс этот небыстрый, что ведёт к нескольким дополнительным сотням циклов на каждый сискол. Отсюда просадка производительности на 30% в том же постгресе.
Naglec
04.01.2018 13:05Вот с PostgreSQL сейчас обидно было. 30% это, блин, 30%.
LeonidY
05.01.2018 00:56А ты не гоняй на машине с ним сторонии приложения (включая браузер), и можешь спать спокойно. Надеюсь PostgreSQL не выполняет Java/JS?
Naglec
05.01.2018 00:58Нет, разумеется. Выключим мы этот патч, ибо сервера железные.
Но если кто-то гоняет PostgreSQL на виртуалках?
bogolt
05.01.2018 02:02Ну тогда патч нужно ставить на железо на котором запущена виртуалка, иначе по идее смысла нет. А на это, если виртуалка в чужом облаке, все равно никак не повлиять.
Naglec
05.01.2018 02:05Так в том и дело, что если патч поставить, то производительность упадет. В случае с железным сервером чисто под СУБД можно обойтись без патча, а в случае с виртуалкой — нет.
MuLLtiQ
04.01.2018 14:10https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.de
ну не 30, а 23, да и то в синтетическом тесте.
Но все равно обидно :(
Mogost
04.01.2018 11:58+8Уязвимость на уровне CPU, но закрыть её на уровне CPU нельзя. Поэтому костыляют на уровне ОС.
awMinor
04.01.2018 12:00Уязвимость фиксится на уровне ОС потому что как вы себе представляете пофиксить её на уровне процессора? Я не думаю, что можно накатить патч на процессор из под Windows.
theRavel
04.01.2018 12:13Это понятно, но значит ли это, что в следующем поколении CPU уязвимость будет устранена и на уровне ОС этот замедляющий код может быть отключен (для соответствующих версий CPU конечно же) ?
CryptoPirate
04.01.2018 12:18Скорее всего, да.
Salabar
04.01.2018 14:56Следующее поколение в разработке уже где-то пару лет, так что, скорее всего, через одно.
tyomitch
04.01.2018 19:59Если речь идёт об «утечке информации через кэши», то аппаратное устранение этой проблемы будет вести к точно такому же замедлению, что и программное.
qw1
04.01.2018 20:24+2Зависит от реализации. Например, можно зарезервировать пару кеш-линий для спекулятивного выполнения, и, пока не поступит подтверждение, что переход предсказан верно, на запись работать только с этими линиями и не писать в другие.
Как только приходит подтверждение предсказания, эти выделенные линии мержаться в кеш. Если приходит неподтверждение, линии отбрасываеются, как и изменения в регистрах.
Всего-то ещё 100500 транзисторов на эту логику. Там и без того намешано чёрт знает сколько, так что чуть усложнить работу процессора не страшно.tyomitch
04.01.2018 22:27Всего-то ещё 100500 транзисторов на эту логику.
Плюс 100500 мкВт на питание этих новых кэшей :-/
sumanai
04.01.2018 22:30Хотел было написать, что в каждом поколении добавляют поддержку новых инструкций, которые жрут больше, но подумал про современные системы управления питанием и отключение частей процессора, которые позволят отключить части кристалла с этими инструкциями. А эти транзисторы будут использоваться постоянно, так что вы, увы, правы.
LeonidY
05.01.2018 01:01Не, не 100500, меньше. На MIPS-е исследовали, правда по другой, соседней причине.
DistortNeo
04.01.2018 20:42Одно из аппаратных решений — огрубление high-resolution таймера до, скажем, 2000 тиков в секунду. Это не решит проблему, но существенно замедлит скорость чтения: до 1 бита в миллисекунду — 128 байт в секунду, что на 3 порядка ниже текущей скорости чтения.
qw1
04.01.2018 20:53Не замедлит.
Если есть доступ к rdtsc, хакер будет просто подгадывать момент, когда rdtsc увеличился, крутить цикл почти до следующего тика, а потом запускать процедуру чтения адреса и смотреть, успел ли счётчик скакнуть, или нет.
Если нет доступа к rdtsc (как в сценарии с web-workers), ничего не меняется. Вспомогательный поток непрерывно делает вычисления и постоянно кладёт результаты в память. Основной поток в интересующий момент просто смотрит, сколько успело навычисляться.DistortNeo
04.01.2018 20:54> Если есть доступ к rdtsc
Вообще-то я его и имел в виду. Огрубить rdtsc до 2000 тиков в секунду.qw1
04.01.2018 21:07Как видите, не решает. Атакующему нужно знать: кусок кода выполнился за 10 тактов или за 200. Для этого он замеряет, сколько нужно крутить пустой цикл, чтобы rdtsc увеличился на 1, затем сразу же крутит этот цикл на 10 итераций меньше, и выполняет интересующее его чтение памяти. Затем смотрит, успело чтение до инкремента rdtsc или нет.
qw1
04.01.2018 21:10А, я понял. Вся эта операция чтения байта потребует крутить эти пустые циклы, что само по себе долго.
0xd34df00d
04.01.2018 21:11А если ещё добавить к rdtsc небольшой рандомный шум с дисперсией порядка задержки кеша…
DistortNeo
04.01.2018 21:24А зачем крутить пустой цикл, когда можно в цикле крутить атаку на один и тот же бит, а потом считать, сколько итераций цикла было выполнено за 1 такт счётчика?
tyomitch
04.01.2018 22:16Таймер для эксплойта необязателен: один поток пусть в бесконечном цикле инкрементирует счётчик, другой поток пусть сравнивает значения счётчика до обращения к памяти и после.
LeonidY
05.01.2018 01:00Не совсем. Чтобы починить текущие проблемы у Интела, надо — делать проверку доступа ДО того, как запускается подкачка кэш-а; разобраться с кривым TSX-NI, или отрубить его совсем — отрубали же на определенных процессорах из-за ошибок.
Ну а eBPF — это все-таки просто что-то типа троянского коня в ядре и больше софтверная проблема.
Efficeon
04.01.2018 14:14Некоторые уязвимости и баги таки фиксятся на уровне процессора — фиксится микропрограмма.
И можно даже из-под Windows накатить обновление — вот пример support.microsoft.com/en-us/help/3064209/june-2015-intel-cpu-microcode-update-for-windows.
sumanai
04.01.2018 15:07+1Я не думаю, что можно накатить патч на процессор из под Windows.
Windows это регулярно делает, как впрочем и Linux. В современных процессорах есть микрокод, который и обновляют ОС либо биос.
P.S. Я буду обновлять комментарии…
Kobalt_x
04.01.2018 17:23А микрокодом пофиксить Интел типо ниасилит?
khim
04.01.2018 18:06Можно. Но придётся кучу самых часто используемых инструкций пустить через микрокод. С соответствующим замедлением раз этак в 5-10.
Оно вам надо? Тут уж дешевле поставить интерпретатор x86 для x86 и пускать всё в эмуляции под QEMU…qw1
04.01.2018 18:26+1Разве QEMU не выполняет бинарную трансляцию? То есть, с большой вероятностью, он скопирует весь вычислительный код (между системными опкодами) один-в-один и запустит.
khim
04.01.2018 18:37Можно это выключить. Но да, замедление будет такое, что всё это — скорее теоретические возможности…
potan
04.01.2018 21:15В него можно добавить верификацию на попытки использовать эксплойт.
qw1
04.01.2018 21:21Можно конкретные сигнатуры ловить, но в общем случае эта задача требует полноценного понимания, что делает алгоритм. В коде нет никакого криминала, особенно если обращение к таймеру заменить на взаимодействие вычислительных потоков. Ну, насчитал алгоритм что-то, а потом на основе этого сделал URL для GET-запроса. Информация утекла.
makaronnikk
04.01.2018 13:45Хороший вопрос. Фиксить нужно гипервизор или виртуальные на нем? VMWare пока молчат.
AMaverick
04.01.2018 14:30VMWare выпустили бюлетень безопастности:
www.vmware.com/us/security/advisories/VMSA-2018-0002.html
Miscrosoft в своем анонсе про Azure пишут, что при обновлении гипервизора, нет необходимости обновлять гостевые ОС:
This Azure infrastructure update addresses the disclosed vulnerability at the hypervisor level and does not require an update to your Windows or Linux VM images. However, as always, you should continue to apply security best practices for your VM images.
azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vulnerability
Возможно и в случаее VMWare тоже можно будет обойтись обновлением гипервизора, но достоверной информации пока нет :(
nikitasius
04.01.2018 11:57+3Отличные новости, ничего не скажешь. 10 лет Карл, 10 лет дырка была. И не в софте, а в железе!
dfm
04.01.2018 19:03-1Да уж, лично я испытал дикий батхерт от этой новости, когда, будучи более 10 лет поклонником AMD, всего полгода назад решил проапргрейдить компьютер и перейти на Intel.
dfm
04.01.2018 23:49-1для тех, кому не понравился мой комментарий, поясню
AMD с ARM также уязвимы, но атаку реализовать сложнее.
сложнее.
Lsh
05.01.2018 00:54Помните, когда-то давно хакер Крис Касперски (мышихъ) обещал раскрыть уязвимость/закладку в процессорах, а потом уехал в штаты. Разные околохакерские ресурсы долго спекулировали на эту тему, мол дыра настолько фундаментальная, что достаточно зайти на сайт и вне зависимости от ОС, антивируса и браузера, можно систему поиметь. Насколько я помню он ничего такого и не рассказал так. Хотя я могу и ошибаться. Чем там дело кончилось?
interprise
05.01.2018 00:55вообще механизм уязвимости настолько просто, что я удивлен что его раньше не нашли
ExplosiveZ
05.01.2018 06:01Прикольно. Интересно, как часто гебня пользовалась этой уязвимостью?
www.securitylab.ru/news/355981.php
unwrecker
04.01.2018 12:05Может ли эта уязмимость грозить сереру, на котором нет недоверенных пользователей и виртуалок, нет браузера и присущих ему скриптов?
interprise
04.01.2018 12:11если нету зловредного кода который будет выполнятся тем или иным обзором, в таком случае конечно нету опасности.
Evgeniy112
04.01.2018 12:16эта уязвимость требует запуска кода на CPU, а значит только в случае исполнения кода = заражение вирусом\установка левого софта
equand
04.01.2018 12:47Может, смотря что делает система. Насколько я понимаю, любая обработка кода может провести эту атаку. Допустим есть эксплоит выполнения кода в ОС на уровне сетевого стека. Написать PoC после этого не проблема, запускаем атаку и параллельно дергаем SSH — SSH подгружает файлы и они проходят через память. Память мы уже выискиваем данные.
Я пример привожу конечно.
qw1
04.01.2018 19:17Допустим есть эксплоит выполнения кода в ОС на уровне сетевого стека
Странное допущение. В Linux и Windows сетевой стек работает в ядре. Если на него есть эксплойт, не надо никаких Spectre/Meltdown.
Jamdaze
04.01.2018 12:38сменить процессор на заведомо безопасный
И в этом проце через пару лет найдут еще одну уязвимость из-за которой надо сменить проц, вот прям сейчас, бегом, покупай, вон тот, новый, а то продажи пк комплектующих падают, заодно и мать купи, вот.
Со стороны выглядит как новая модель по стимулированию продаж.
akrupa
04.01.2018 13:22JavaScript does not provide access to the rdtscp instruction, and Chrome intentionally degrades the accuracy of its high-resolution timer to dissuade timing attacks using performance.now()[1]. However, the Web Workers feature of HTML5 makes it simple to create a separate thread that repeatedly decrements a value in a shared memory location [18, 32]. This approach yielded a high-resolution timer that provided sufficient resolution.
Кажется, отключение WebWorkers должно предотвратить/усложнить использование атаки через браузер.
Alesh
04.01.2018 13:35+1и единственный способ решить проблему — сменить процессор на вариант заведомо безопасный.
С пока еще не скомпрометированной закладкой :)
KirEv
04.01.2018 14:15и единственный способ решить проблему — сменить процессор на вариант заведомо безопасный.
а еще лучше — сделать свой процессор, о котором никто не будет знать, версию 0.1 можно сделать на лампах :)
iXF
04.01.2018 14:15А как там насчет Эльбрусов?
Данная новость теперь будет спекулироваться нашим государством как перевод всех гос. учреждений на процы «свои».poznawatel
04.01.2018 17:12Когда твои конкуренты жидко обделались, указать потребителям на это не является спекуляцией, это — нормальная бизнес-практика. Пример использования — сравнение «Запорожец-Мерседес».
tnsr
05.01.2018 06:20Да, говорят «немцы» после 2009 года выпуска разваливаются после 100k пробега. Все вертаю запорожец. ))
poznawatel
05.01.2018 10:02Не так. Когда ковбой Джон на двадцатый год обнаружил, что у его бронированного банковского мерседеса двери, люки и капот открываются зубочисткой, он начал что-то подозревать…
technic93
04.01.2018 14:34+1Почитал чуть-чуть статью (pdf).
Очередной прикол с асинхроным исполнением. Надо бы в таких случаях применять какие то алгоритмы чтобы формально доказывать корректность работы.
Вообще опасная фича что сначала загружается в регистр запрещенный участок памяти а потом уже идет проверка на то были ли на это разрешения. Похоже дело было так: реализация доступа к страницам памяти была еще с рождения х86, а потом поверх решили добавить out-of-order инструкции новым слоем, и вышло такое комбо.qw1
04.01.2018 18:22+1Надо бы в таких случаях применять какие то алгоритмы чтобы формально доказывать корректность работы.
Математически всё корректно, проблема с физикой. Если бы в системе не было таймера, утечки бы не было. Это примерно как недавняя «уязвимость» функции memcmp(user_input, secret_key, key_size), которая сравнивает user_input и secret_key побайтно. Замеряя время выполнения, можно узнать, на каком байте находится расхождение, и брутфосить только этот байт.0xd34df00d
04.01.2018 20:16Математически всё корректно, проблема с физикой.
Но математика — язык физики. То бишь, на языке математики требования к таймингам тоже можно выразить и проверить корректность соответствующих высказываний.
Жаль, конечно, что математика не может сама там придумать, что доказывать надо.qw1
04.01.2018 20:30+1То бишь, на языке математики требования к таймингам тоже можно выразить и проверить корректность соответствующих высказываний.
Это значит — сразу зарезать кучу оптимизаций. Если есть возможность для некоторых данных выполнить операцию быстрее, этой возможностью категорически нельзя пользоваться, ведь это раскроет данные перед атакой по таймеру.
А если ускорение получается автоматически (как при делении на некоторых делителях), нужно добавлять искуственные задержки, сводя всё к худшему случаю. Определённо, не то, что мы хотим от процессора.0xd34df00d
04.01.2018 20:38Я вот не понимаю, почему после проверки на отсутствие доступа соответствующие кешлайны не инвалидируются. Пока не читал ещё внимательно описание на Google P0, но, судя по всему, это бы починило проблему.
qw1
04.01.2018 20:47Я об этом думал. Это не решение. Хотя чуть бы уменьшило последствия.
Сейчас, в зависимости от секретного байта, подчитывается какая-то кеш-линия. Если кеш-линию инвалидировать, то изменение состояния кеша при выполнении mispredicted branch — это тоже утечка информации. Просто информации утекает меньше и нужно больше раундов атаки.
Полноценное (на мой взгляд) решение я выразил здесь.0xd34df00d
04.01.2018 20:51А что в таком случае утекает? Адрес, к которому вы обращаетесь, известен, права доступа на него и так известны. Ничего нового, по идее.
qw1
04.01.2018 21:03+1Тут идея такая:
Зная адрес в памятиarray1, я делаю чтениеarray1[x]так, чтоarray1+xявляется адресом в недоступной области (в данном баге не проверяется мой доступ к этой области). Обозначим секретное значениеk=array1[x]
Затем я читаюarray2[k*256](ко всему array2 у меня полный доступ, тут никаких ошибок не предвидится) и, в зависимости от k, это чтение загружает в кеш кусок array2 и выбивает из кеша одну из линий. Если затем эту линию инвалидировать, это несильно помешает, я всё равно замечу, какая из линий инвалидирована.
Сама прочитанная линия array2 мне не нужна, я и так знаю данные array2. Важно лишь, какая линия выбита (а для этого я могу весь кеш забить каким-нибудь array3 и проверять, что вылетело).0xd34df00d
04.01.2018 21:10Здесь, я так понимаю, вы опираетесь на то, что номер выбитой линии кеша зависит от адреса? По идее, тогда даже N-way associativity не поможет (корреляции всё равно будут, да и можно несколько кратных адресов просить).
qw1
04.01.2018 21:14Именно, если оригинале проверяется, какая линия array2 попала в кеш, то с инвалидацией придётся проверять, что вылетело.
Атака усложняется, но остаётся возможной.0xd34df00d
04.01.2018 21:20Я вот пытаюсь придумать какую-нибудь умную реализацию работы с имеющимися кешлайнами (без введения новых специально для спекулятивного выполнения) и что-то не придумал пока.
Правда, по идее, выделить отдельные линии тупо под спекулятивное выполнение может быть возможно и обновлением микрокода, надеюсь.tyomitch
04.01.2018 21:50«Отрезать от кэша кусок для особых целей, и после каждого удачного доступа к памяти перегонять кэшлайн из особого кэша в обычный» — нехило так ударит по производительности.
В чём выгода перед патчем ОС тогда?0xd34df00d
04.01.2018 21:53+1Представляется, что кеша под это дело нужно будет не так уж много (порядка нескольких линий на ядро), и что вместо перегонки можно обойтись ремаппингом (примерно как с регистрами).
А в ОС вы что патчить будете?tyomitch
04.01.2018 22:20+1В ОС, как уже написали в каментах, unmap-ят всю «запрещённую память», и принудительно сбрасывают все кэши, при каждом переключении из кернелмода в юзермод.
MacIn
04.01.2018 22:24Теперь будут держать отдельный каталог таблиц, полностью свой CR3 с блекджеком и профурсетками, чисто для ядра, с перегрузкой оного (CR3), инвалидированием TLB при переключениях и так далее?
tyomitch
04.01.2018 22:30Таки да :-/ Выше упоминаются «сотни дополнительных тактов на каждый сискол».
0xd34df00d
04.01.2018 22:52Сдаётся мне, это существенно медленнее.
olartamonov
04.01.2018 23:31Тест на запрос getpid в цикле показывает в районе 4-кратного торможения с анти-Meltdown патчем.
qw1
05.01.2018 01:02+1Это в Linux? А зачем syscall?
В Windows свой PID просто лежит в PEB, доступном из юзермода.
Скрытый текст.text:180001250 ; DWORD __stdcall GetCurrentProcessId() .text:180001250 public GetCurrentProcessId .text:180001250 GetCurrentProcessId proc near .text:180001250 mov rax, gs:30h .text:180001259 mov eax, [rax+40h] .text:18000125C retn .text:18000125C GetCurrentProcessId endp
netch80
05.01.2018 10:43Для текущего времени сделали чисто-юзерлендовое решение через механизм vDSO, а для pid?а, видимо, не было причин — кому его надо читать таким темпом? Теперь могут и сделать, если что-то резко просядет.
Кстати, в старых FreeBSD вызов getpid() кэшировался на уровне libc; fork() просто снимал флаг «а мы знаем свой pid». vDSO тут даже не обязательно.
qw1
04.01.2018 22:01Не после каждого удачного доступа, а только при записи в режиме спекулятивного выполнения, что такой частый сценарий.
Микрокодом это сделать наверное нельзя.
Но если сделать нативно — всего лишь 1-2 новых 512-битных регистра (а такого размера регистров и так уже 32: zmm0-zmm31), которые при коммите изменений запишутся в кеш, а не в регистровый файл (как бы это в современных процессорах не было одной и той же структурой, т.к. конструкции типаadd eax,[ebp+8]работают, как иadd eax,ebx)
LeonidY
05.01.2018 01:15Не перегнять, а переадресовывать. Иметь еще один кэш-маппинг, который назначает адрес в кэше и меняется при подтверждении загрузки. Ну и в этот момент и происходит вытеснение старой строки.
mayorovp
05.01.2018 12:12Да все проще же. Если мы (процессор) знаем физический адрес — значит, мы уже знаем и про ограничения доступа к странице. Достаточно лишь проверять их еще до попытки чтения.
qw1
05.01.2018 12:31Не может раздельно кешироваться трансляция в физический адрес и флаги доступа?
qw1
05.01.2018 12:49Собственно, требования к Spectre:
array1size and array2 are not present in the processor’s cache, but k is cached;
То есть, прочитать недоступное по текущим привилегиям значение k гораздо проще, чем проверить права доступа к нему, т.к. k — в кеше.
olartamonov
05.01.2018 12:43MMU нужно время на проверку адреса, поэтому по факту логичнее запускать такую проверку и спекулятивное выполнение одновременно, иначе резко упадёт эффективность.
Дальше случается гонка между MMU и конвейером, и судя по всему, в Интелах побеждает конвейер, а в АМД — MMU. Но ни там, ни там конвейер не ждёт результата из MMU.mayorovp
05.01.2018 12:54Что есть «проверка» адреса? Логический адрес не надо проверять, его надо преобразовать в физический. Если это преобразование еще не сделано — то прочитать значение по указанному адресу невозможно!
Поэтому конвейер обязан ждать MMU.olartamonov
05.01.2018 18:16Проверка адреса — это проверка двух условий: а) адрес находится в памяти, разрешённой данному процессу и б) у процесса достаточно привилегий для доступа к нему.
Если говорить про Meltdown, там вообще нужный адрес может уже в TLB быть, MMU остаётся только проверить наличие привилегий.
qw1
04.01.2018 18:35+3Вообще опасная фича что сначала загружается в регистр запрещенный участок памяти а потом уже идет проверка на то были ли на это разрешения
Прямого доступа в запрещённый участок всё равно нет. После отрицательного ответа на проверку доступа загруженные данные откатываются обратно.
А вот сторонние эффекты, как то загруженная в кеш линия, зависящая от прочитанного байта (для того там и хитрая конструкцияy = array2[array1[x] * 256]), остаются. И, хотя напрямую нельзя узнать, какие адреса сейчас сидят в кеше, это можно сделать, замеряя время доступа к разным адресам.
Если запретить физическое чтение данных, к которым нет доступа, много теряем в производительности — убираем параллельную загрузку и проверку доступа, придётся делать всё строго последовательно и про выполнение процессором одновременно N инструкций на одном ядре придётся забыть.kryvichh
04.01.2018 23:11Вот мне и интересно: в процессорах AMD не используется параллельная загрузка — проверка доступа, либо они как-то по-другому оптимизируют исполнение подобного кода.
qw1
04.01.2018 23:20Не знаю, может, у AMD оптимизатор не такой продвинутый, чтобы заглядывать настолько вперёд в ветке, которую в конечном итоге по логике программы выполнять не надо.
olartamonov
04.01.2018 23:37Если мы про Spectre, то AMD подвержен.
Если мы про Meltdown, то у AMD немного другая внутренняя логика, в результате которой у атакующего не остаётся достаточного временного окна для собственно атаки.
Это логика, над которой раньше никто явно особо не задумывался, поэтому что у Intel сделано так, а у AMD иначе — обусловлено какими-то иными причинами, возможно, настроением разработчика процессора тем утром, когда он сел этот блок рисовать. У ARM вон вообще часть ядер Meltdown подвержена, а часть — нет.kryvichh
04.01.2018 23:41Да, про Meltdown, спасибо.
Spectre, как я понял, на AMD процессорах лечится программно практически без потери производительности.olartamonov
05.01.2018 00:02Это AMD утверждает, что он лечится программно и без потерь.
Пруфов пока никто не видел, и из оригинальной работы по Spectre никак не следует, что мы их увидим.
Точнее, даже так: да, возможно, он лечится программно и без потерь. В каждом конкретном уязвимом месте каждой используемой на компьютере программы. Теперь умножьте количество таких мест на количество существующих в мире программ.
sigo73
05.01.2018 19:57Обсуждение этого бага на конференции BlackHat 2017 Asia:
www.youtube.com/watch?v=6bCdFmehMSY
Meklon
04.01.2018 14:55На Ubuntu server 16.04 патчи уже есть? Потушил пока виртуальные машины. И, насколько я понимаю, только Meltdown закрывается, а Spectre вообще только аппаратно или на уровне микрокода можно закрыть?
tbl
04.01.2018 15:05микрокод не поможет (он отвечает только за декодер инструкций). Исправление только аппаратное: замена процессора на неуязвимый (на 486 или более старше, либо ждать новые процы, где это будет исправлено, через 1-2 года, думаю)
Meklon
04.01.2018 15:27Садиться и плакать, да?) Меня жаба задавит сейчас обновлять домашний сервер на Core i5 Ivy Bridge. Увы, но он ещё и owncloud хостит для друзей и рабочих задач. Думаю, как минимизировать хотя бы риски атаки.
sumanai
04.01.2018 15:35Думаю, как минимизировать хотя бы риски атаки.
Если ваш сервер не исполняет левые программы, то и уязвимость ему не страшна.
willyd
04.01.2018 15:37Fedora ночью выкатили новое ядро, но у них stable сейчас 4.14.11.
Meklon
04.01.2018 15:46У меня 4.10, кажется. Я на HWE ядра перешёл.
willyd
04.01.2018 16:07Я не думаю, что там будет большая проблема.
Патч сводится к нескольким строчкам. Главный вопрос, что будет с производительностью на реальных системах. Пока на десктопе мне тяжело сказать как она изменилась.Meklon
04.01.2018 16:33Я на Windows 7 отключу этот патч, наверное. Только для игр запускаю.
willyd
04.01.2018 16:47Оценка рисков ;)
Думаю, что его эксплуатация начнется с какого-то webasembly и максимум, что будет подпадать под атаку на широкую аудиторию — это пользовательские данные из браузера.Meklon
04.01.2018 19:37Сейчас думаю, как максимально изолировать все на сервере. У меня почти все только через VPN доступно, но наружу торчит HTTPS с nextcloud. Сам nextcloud внутри KVM.
willyd
04.01.2018 21:07+1Я не специалист в области безопасности.
Но в моем понимании для эксплуатации нужно исполнить код на целевой системе. То есть, если у вас сейчас система в актуальном состоянии, и исполнение кода на VPS в контролируете, то нужна еще одна 0day уязвимость позволяющая запустить эксплойт. Это без того, что еще нужно знать, что искать, или дампить память целиком и потом разбираться в ней.Meklon
04.01.2018 21:45Собственно, задача в том, чтобы максимально усложнить тупую не таргетированную атаку ботами. Против целенаправленной атаки сложно устоять. Поэтому хотя бы больше слоев изоляции.
willyd
04.01.2018 22:13+1Так если вы светите наружу 80 и 443 то боты вас будут штурмовать тем же набором эксплойтов, что и позавчера. Вот, если найдут какую-то открытую уязвимость, то чтобы закрепится на втором этапе добавят этот экплойт. Но опять же, нужно знать, что и где искать. Если у вам в окружении не висит переменная типа MY_SECRET_PASS etc, к примеру, то не особо уверен, что все будет легко для бота из китая.
Поставьте какую-нибудь IDS, ну или, как минимум, fail2ban закрутите до упора.
A c VPS, я не думаю, что вы сможете сделать больше, чем накатить обновление ядра. Нужно новости почитать, но вроде как spectre пока свободно эксплуатируем.Meklon
04.01.2018 22:21Только 443. fail2ban надо агрессивнее сделать, согласен. Тут ещё плюс в том, что по основному домену example.org отдается заглушка nginx. Надо ещё поддомен угадать.
Meklon
04.01.2018 23:44Надо наружу 22 порт выставить и в honeypot его с fail2ban NAT'ом направить. Соберу коллекцию ботов)
Kobalt_x
04.01.2018 17:30Для игр сильные просадки вряд ли будут там же direct rendering без сисколлов
Alesh
04.01.2018 21:19+1Принимая во внимание «теорему Джо», вряд ли ваш домашний сервер пострадает от атаки.
Meklon
04.01.2018 21:47Паранойя) и китайские боты, которые абсолютно автоматически ломятся по всем портам.
Alesh
04.01.2018 22:07Если серьезно, то там достаточно нетривиальные телодвижения надо проделать, к тому же знать что искать. Не скажу про виндовс, но линукс системы все таки более-менее защищены от этого, хотя бы пароли зашифрованы и не принято тянуть из сети и запускать что попало. А поиск чего-то конкретного уже попадает под «теорему Джо». Дыра пробиваемая через javascript, если сервер используется именно как сервер тоже по идее идет мимо. Что касается серверов, то серьезная засада пожалуй ожидает в основном только хостеров виртуалок, ну и конечно тех кто пренебрегает апдейтами в целом.
olartamonov
04.01.2018 16:04+1на 486 или более старше
Ну зачем вы так сразу людей пугаете, можно же Pentium MMX поставить.
rogoz
04.01.2018 16:15на 486 или более старше
Pentium MMX и более старше. Pentium Pro и Pentium II уже уязвимы.
Также есть старые (вроде как до 2013 г) Atom'ы, которые тож не имеют этих всяких конвейеров.
YuriM1983
04.01.2018 18:40+2косо смотрит на процессор 486DX2-66, лежащий в тумбочке.
Пришло твое время!MacIn
04.01.2018 19:21Хе-хе, как раз рядом стоит DX-40. Живем!
dmitry_dvm
04.01.2018 21:02У меня атлон 64 х2 валяется несколько лет, рука не поднималась выбросить, как чувствовал) А серьезно, то видимо придется терпеть это непотребство, ибо 30% слишком дорого.
Goodkat
04.01.2018 15:17Судя по тестам, патчи сильно повлияют на производительность существующих систем. Тесты показывают падение на 10-30% в некоторых задачах.
Это ж отличная новость для всех поставщиков оборудования и особенно производителей процессоров!
Производительности моего уже десятилетнего Core2Quad мне пока на всё хватает, даже прошлогодние игры упираются лишь в видеокарту. А прилетит патчик, комп начнёт наконец-то тормозить, и побегу я и миллионы таких как я в магазин за новым 6-8-ядерным процессором, который потянет за собой апгрейд всего остального компа. А уж как энтерпрайз обрадуется новые компы и сервера покупать!willyd
04.01.2018 15:32Это ж отличная новость для всех поставщиков оборудования и особенно производителей процессоров!
В чем она отличная?
Я думал о покупке ноутбука. Нормальной рабочей станции с расчетом года на три, на уровне EliteBook, ZBook, Precision. Но вот теперь у меня возникает вопрос, покупать ли сейчас ноутбук за 2к, если через год выйдет версия с процессором, который будет на 10-30% мощнее без учета естественного прогресса технологии. И думается мне, что не я один такой. А на AMD выбор не такой большой и выигрыш в производительности тоже не будет значительным.
И вот если этот вопрос будут задавать достаточное кол-во людей, то продажи могут просесть очень сильно.
PS только что накатил новое ядро. Визуально стал несколько медленнее, тестов почти не делал, но в одном проседание на 30%, в остальных все как-было.Goodkat
04.01.2018 16:57Вы и так собирались покупать более новое железо на замену относительно новому — там рост производительности процента три от поколения к поколению, вам действительно лучше подождать хардварного решения проблемы.
А я и куча других людей не собирались покупать, так как нас устраивала имеющаяся производительность. После патча она просядет на 30%, что подстегнёт апгрейды. Даже с учётом штрафа в 30% новые кофе-лэйки намного быстрее старых коре2квадов, хотя бы из-за роста тактовой частоты в полтора раза, не говоря уж о двух дополнительных ядрах, гипертрединге и всех тех новых фич, которые Интел успел сделать за десять лет.willyd
04.01.2018 17:12Меня вполне устраивала производительность на моем далеко не новом i5-4310U. Но она была на приделе, и когда у меня запущенна IDE и пару виртуальных машин, это чувствуется. Вот сейчас буду по работе делать ручные тесты с виртуалками, тогда и посмотрим.
После патча она просядет на 30%, что подстегнёт апгрейды.
Не факт, я уже написал, что у меня она просела только в одном тесте. Если у вас есть какой-то нормальный тест для linux на производительность, я готов его прогнать, чтобы проверить.
dernuss
04.01.2018 19:18Вот и я думаю, уже выбрал yoga 920. Теперь в сомнениях.
Mogost
04.01.2018 19:30Тоже приглядывался к 920, все бил себя по рукам. Теперь уверен, что дождусь линейки процессоров без уязвимости :)
willyd
04.01.2018 19:41Я тешу себя напрасными надеждами, что цены просядут.
В любом случае пару недель нужно подождать. Но сомневаюсь, что ситуация сильно исправится и, скорее всего, нужно будет собирать что-то mini-itx.
YuriM1983
04.01.2018 19:57Изначально не самый удачный выбор в плане security:
www.techdirt.com/articles/20150812/11395231925/lenovo-busted-stealthily-installing-crapware-via-bios-fresh-windows-installs.shtml
vagran
04.01.2018 23:47Я думаю, что основной объём продаж определяется людьми, которые вообще никогда не узнают об этом моменте. И для задач которых потеря 30% производительности ничего не означает, потому как всё равно процессор всё время в idle. Тех, кто реально будет парится на эту тему, хорошо, если один процент наберётся.
dartraiden
04.01.2018 15:51+1Производительности моего уже десятилетнего Core2Quad мне пока на всё хватает, даже прошлогодние игры упираются лишь в видеокарту.
Очень странно, потому что я своими глазами наблюдал обратное при переходе с Xeon E5xxx (по характеристикам идентичен топовому C2Q) на i7-6700. Допустим, Mafia III на старом процессоре не «тормозила» (визуальные подвисания) только на минимальных настройках графики, а с новым процессоров никаких проблем я не увидел даже на средних. Учитывая, что видеокарта осталась прежней, напрашивается вывод, что процессор реально был узким местом.Goodkat
04.01.2018 17:03А это точно не из-за памяти?
dartraiden
04.01.2018 17:40Из-за объёма или частоты? 8 гигабайт (было), в принципе, хватает большинству игр…
Частота, вроде бы, не должна настолько заметно влиять (1066 -> 2133)Goodkat
04.01.2018 19:46Всё может быть, конечно, и для вашей игры старого процессора маловато.
Doom и COD Infinite Warfare у меня летают. Игры позапрошлогодние, конечно же — ещё не привык, что у нас уже 2018.
Eswcvlad
04.01.2018 15:31Security Advisory от Microsoft со ссылками на обновления — https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002
XLOR
04.01.2018 15:33KB4056892 установился уже через Windows Update, могу сказать что мой дохленький i3 просел в играх (даже не самых свежих уже), в WOW Wotlk просадки fps до 25% :( по сравнению с до патчевыми замерами.
Наверное выбор сделаю в сторону производительности на одной машине, где мне не страшно что данные стырят. Как отрубить теперь последствия этого патча? Флаг в реестре не подскажите?dartraiden
04.01.2018 17:44i7-6700 в Cinebench просел на 4-5% в многопотоке.
Skerrigan
05.01.2018 09:44Это хорошие новости и для меня — у самого такой. Хороший ЦП так-то, менять его и не планировал еще года 3-4. А тут что началось… аж скис.
dartraiden
05.01.2018 14:55Мне вот не нравится, что уже дважды после этого обновления система повисала наглухо… Возможно, загвоздка в том, что у меня не серийный процессор, а инженерный экземпляр (ранний степпинг), и на серийных всё будет нормально.
Кстати, вдобавок к обновлениям операционных систем выпущен свежий микрокод для процессоров:
New upstream microcodes to partially address CVE-2017-5715
+ Updated Microcodes:
sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304
qandak
06.01.2018 04:56Тут важно понимать долю IO в тестировании, что, мне кажется, должна быть так же незначительна. Насколько я помню Cinebench больше графический бенчмарк, то есть это почти как сравнивать fps в игрушке, где существенной просадки и так не прогнозируют.
Sergey6661313
04.01.2018 15:46-4И почему всё называют это дырой/уязвимостью, когда это самое натуральное «несоответствие действий процессора со своей спецификацией»? Тут надо не решать какая должна быть «заплатка» на уровне ОС или на уровне процессора. Тут надо пересматривать саму архитектуру проца как такового.
Простым юзверям на это всё равно побоку. У них 3 биткоин майнера в аппдате, 2 маил ру сервиса которые «неизвестно откуда взялись/всегда там были», 20 тулбаров в браузерах, подменёные ярлыки на рабочем столе, зато «красивые часики». Таким юзверям по барабану на эту уязвимость потому что раз в пол года они перестанавливают шиндовс xp и даже не краснеют.
Другие «супер продвинутые» юзвери никогда не сидят под админом, запускают программы только в песочници из под виртуалки. Такие обычно не могут даже распаковать игрушку не говоря уже о запуске потому что вообще у них «белый список»… Таким данная уязвимость не страшна потому что они поддерживают состояние бекапов по 3 раза в день.
Почему я не слова ни сказал о защите личной информации например «пороль от сбербанка»? Потому что всё что хранится в принципе не на вашем компе — не ваша личная собственность. Если захотят спиздить ваши фотки с облака — спиздят. Не через процессор так через терморектальный_криптоанализ всё равно найдут способ… Двух факторная аутификация для того и создавалась чтобы даже скомпрометированная машина не могла ничего получить. Но о безопасности самой машины всё равно не имеет смысла говорить пока процессы в принципе не будут разделены. Какой смысл говорить о безопасности браузера если он хранит свои данные в той же папке в которой и зловред? (я про appdata). И доступ туда имеет вообще любая программа.
На самом деле никто никогда и не был по настоящему защищён.
potan
04.01.2018 15:46Для JS можно сделать верификатор, которые проверяет, что конкретная программа не может использовать эти или другие дыры. Увеличится время загрузки, а на скорости после JIT уже не отразится.
SpyFX
04.01.2018 17:04что бы такой верификатор смог понять что-то, необходимо фактически полностью полностью выполнить код js
vsb
04.01.2018 16:47Проблема преувеличена. Обычных пользователей это практически не коснётся. Самая серьёзная дыра ИМХО была heartbleed.
I-ilya
04.01.2018 17:04+1Вот ты сейчас серьёзно? Не коснётся то, что одно приложение может считывать произвольные места в памяти и полностью нарушиать изоляцию? Может и не коснётся если живешь в лесу отшельником.
vsb
04.01.2018 17:06Считывание произвольных мест в памяти фиксится патчами ОС, которые уже или почти уже прилетели, или заменой процессора.
Если что, на любой десктопной ОС практически любое приложение может читать произвольные файлы пользователя и никого это особенно не волнует. Вот уж где ужас и кошмар, скринсейвер может отправить все мои пароли спамерам или проекты конкурентам. Поэтому любое запускаемое приложение на компьютере уже доверенное, иначе его не стоит запускать. То, что добавился ещё один способ вирусу получить рута (которых и так находят каждый год по нескольку штук), ничего особенно не меняет.Goodkat
04.01.2018 17:12Скринсейвер — не страшно, его ещё нужно установить.
Ужас и кошмар — то, что прямо в данный момент хабр может читать ваши пароли посредством javascript.vsb
04.01.2018 17:15Атаки через JavaScript (по крайней мере известные) уже или практически уже отражены гугл-хромом и фаерфоксом, как минимум.
WST
04.01.2018 17:25+1Или возможность «вылезти за пределы» VPS-ки, ломающая саму идею VPS как таковую.
vsb
04.01.2018 17:27VPS это действительно неприятно, но это проблемы тех, кто их продаёт, а не пользователей. Ну и, опять же, уже есть фикс, хоть и несколько неприятный с точки зрения производительности.
willyd
04.01.2018 17:50Для тех, кто использует много ресурсов, это как раз будет болезненнее чем для операторов, все затраты из-за потери производительности инстансов упадут на плечи пользователей.
FeNUMe
04.01.2018 22:22+1То есть 30% потеря производительности от этих патчей по вашему это «не коснется»?!
Эта уязвимость коснется абсолютно всех, да в разной степени, да кого-то напрямую, кого-то косвенно, но коснется.vsb
04.01.2018 23:06Для обычных пользователей потери будут на грани погрешности, ни о каких 30% речи не идёт.
RussDragon
05.01.2018 23:17Нет, не будет. Можете почитать сообщения человека выше, у которого после патча начал проседать ФПС в играх. 30% – это никак не погрешность.
vsb
06.01.2018 00:09Нет никаких 30%. У меня ничего не просело, например. Есть нормальные тесты от авторитетных изданий, а не «человек выше», если не верите мне, или сами проверьте.
Nick_Shl
04.01.2018 17:55Почему все говорят о "падении производительности"? Производительность не падает — увеличивается загрузка процессора натвыполнение "лишних" операций и падает КПД! И за все это заплатим мы с вами счетами за электроэнергию и укороченным временем работы ноутбуков от батарей!
qw1
04.01.2018 19:04+1Как же не падает, если при каждом переключании режима user/kernel, надо выполнить определённые инструкции, перенастраивающие карту памяти, чтобы удалить страницы ядра из user-пространства (раньше конфигурация карты памяти была одинаковая, а критичные данные были защищены правами доступа, но этот эксплойт их обходит).
Nick_Shl
04.01.2018 19:40+1Инструкции выполняются? Скорость выполнения инструкций падает? Со стороны процессора он работает точно так же — просто ПО которое на нем выполняется начинает передавать ему больше инструкций.
Говорить "снижение производительности" неверно потому, что низкая производительность ассоциируется с низким потреблением энергии. В данном же случае происходит не только замедление выполнения пользовательского кода, но и увеличение потребления энергии.qw1
04.01.2018 19:48+2Падает производительность не CPU, а операционной системы, а вместе с ней и всего компьютера.
ОС выполняет меньше сисколлов в секунду (т.к. больше времени тратит на каждый при том же hardware).
RussDragon
05.01.2018 23:21У меня почему-то низкая производительность наоборот ассоциируется с излишним потреблением энергии.
no1D
04.01.2018 17:56MS Выложило вроде как апдейты
www.catalog.update.microsoft.com/Search.aspx?q=KB4056898 Windows 8.1
www.catalog.update.microsoft.com/Search.aspx?q=KB4056897 Windows 7Jkobs
04.01.2018 18:35+1Касательно 7ки. Если прочесть о чем оно, то не особо похоже под нашу проблему. Но кто знает, что там под капотом
no1D
04.01.2018 20:09
Mur81
04.01.2018 22:17Эти обновления вышли раньше времени (должны были во вторник). Это наводит на мысль, что выкатили их в срочном порядке. Других причин кроме Meltdown/Specte вроде на это не было…
DikSoft
05.01.2018 01:19Т.е. опять спасибо Гуглёвым докладам?
Mur81
05.01.2018 12:57В том смысле, что благодаря им апдейты вышли раньше? Не знаю. Вообще я видел инфу, что производители процов еще в июне были поставлены в известность. А на «официальном» сайте уязвимостей написано, что найдены они были независимо аж тремя (!) командами сразу (касаемо Meltdown). Не думаю, что это прям так вот в один день случилось.
Кстати обновления от MS до сих пор еще не видны через обычный механизм обновления. По крайней мере в Win 7 и 8.1, в десятке — не знаю. Но вот WSUS выкачал первую партию (security only update) 4-го числа и вторую (кумулятивные) — 5-го. Может решили корпоративных клиентов обновить побыстрее, а с обычными подождать до вторника патчей.
На мой взгляд для обычной рабочей станции уязвимость не столь страшна, что бы прямо впадать в панику. Да, несомненно уязвимость очень серьёзная. Но для её успешной эксплуатации всё же надо еще немалую работу проделать. Так что пара-тройка дней просрочки с установкой патча не так страшно думаю. Вот для облачных систем очень опасно, это да.DikSoft
05.01.2018 18:59— Да, я про спешку и торопыг-публикаторов. Эти апдейты уже были в планах у MS на «вторник патчей».
Вот в каком месте у Google чесалось, чтобы опять вывалить всё раньше сроков?
PS: В SCCM всё приехало 4-го. Установку на сервера (Hyper-V и RDSH) аппрувнул руками. Остальные — не горит. Понятно, что длинные «каникулы» это специфика РФ (может и не только наша, конечно), но наверное, можно было и не выкатывать подробности явно раньше обещанных сроков?Mur81
05.01.2018 19:16А, в этом плане. Я честно говоря не интересовался кто первый разгласил. Может и не Гугл это был.
Одно ясно, что об уязвимости было известно уже несколько месяцев (вроде с июня как минимум). И подготовка к внедрению патчей (и соответственно к разглашению) велась долго и планомерно. У кого-то нервы сдали на завершающем этапе наверно. Ну или еще какие-то причины были, оставим их деликатно за кадром.
Любопытный факт: как я понял для установки патчей на Windows, в случае если установлен какой-либо антивирус, нужно что бы этот антивирус в начале проапдейтился до совместимого и выставил флаг в реестре. Т.е. производители антивирусов тоже были заранее уведомлены и готовились. Хотя патч к Kaspersky Endpoint Security вышел только 4-го числа. Не похоже как-то на «подготовились заранее». В общем не знаю.khim
05.01.2018 19:22+1У кого-то нервы сдали на завершающем этапе наверно. Ну или еще какие-то причины были, оставим их деликатно за кадром.
Да нет, всё просто: чем ближе «к часу Х», тем больше людей задействовано. Вендоры, крупные ISP, etc.
Так что обычно нужно быть готовым к тому, что за 5-7 дней до официального срока «оно» случится. Так почти со всеми уязвимостями было…
shinkei
04.01.2018 18:04+1То есть через эти дырки какой-то вшивый сайт с нужным js сможет private key для моего бинткойна вытащить?
I-ilya
04.01.2018 18:14+1Ну это достаточно затруднительно, но возможно, а вот на месте всевозможных бирж и обменников на VPS я бы напрягся.
dezconnect
04.01.2018 21:37биржи на VPS… вы серьезно? :)
willyd
04.01.2018 21:53А этого не может быть?
aws.amazon.com/solutions/case-studies/coinbase
docs.gdax.com
Colocation. GDAX primary data sources and servers run in the Amazon US East N. Virginia data center. To minimize latency for API access, we recommend making requests from servers located near the AWS us-east-1 data center.
yokotoka
04.01.2018 19:02+2Бенч до патча$ sysbench --test=cpu --num-threads=16 --cpu-max-prime=50000 run
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 16
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 50000
Test execution summary:
total time: 25.7222s
total number of events: 10000
total time taken by event execution: 411.0601
per-request statistics:
min: 8.71ms
avg: 41.11ms
max: 117.67ms
approx. 95 percentile: 61.87ms
Threads fairness:
events (avg/stddev): 625.0000/4.76
execution time (avg/stddev): 25.6913/0.01willyd
04.01.2018 19:35Если threads тест запустить все еще хуже.
До патча
General statistics:
total time: 10.0001s
total number of events: 54619
После патча
General statistics:
total time: 10.0003s
total number of events: 32527
Но визуально пока в пределах нормы.
Psychopompe
04.01.2018 23:51А как однопоточные тесты себя показали? Я вот свой старый лэптоп проверил, значительно просели только многопоточные.
tnsr
04.01.2018 19:27+6И вот в 2018 году, дети, вдруг стали популярны текстовые браузеры
;o)
snuk182
04.01.2018 20:16+1tnsr
04.01.2018 20:32+1Сайт по ссылке не скомпрометирован? ))
Кста, разговоры о патчах ОСей,
а патчей браузеров не достаточно?MacIn
04.01.2018 20:51Нет, патч на уровне системы виртуальной памяти.
tnsr
04.01.2018 21:32Ну тады интересно почитать про межпроцеcсное взаимодействие браузера и ОС.
В исходниках firefox'a смотреть? Или JS отдельная библиотека?MacIn
04.01.2018 22:23Дело же не в специфике взаимодействия браузера и ОС. Дело в том, как смаппирована физическая память и память ядра в виртуальное адресное пространство, и как эта область защищается.
tnsr
04.01.2018 21:40Пираты Силиконовой Долины(1999)
Наше дело выяснить насколько этот парень не знает, что ему на самом деле нужно и добиться, чтобы до него это дошло.
Чтобы он понял, что только мы можем ему это дать.
matabili1973
04.01.2018 20:01И какие же процессоры позиционируются как заведомо безопасные?
Goodkat
04.01.2018 20:06+1Pentium MMX и старше.
matabili1973
04.01.2018 20:59Это просто блистательно.
Goodkat
04.01.2018 23:24Атомы могут быть условно безопасными — я где-то читал, что они, на самом деле просто очень быстрые Пентиумы без опережающего выполнения, но это не точно.
xlenz
04.01.2018 20:03Есть возможность проверить, что секюрити патч накатился корректно? Тест на уязвимость spectre / mealtdown?
Melanxolik
04.01.2018 22:16+1Акции говорите падают?
Амазон, накатка патчей, просадка производительсти на 25 процентов оО
Закупка нового железа и стоек, кто в плюсе? Сколько надо тому же амазону железа чтобы выровнять эту просадку?
Да там такие цифры с нулями будут, что некоторые типы процессоров мы еще год можем не увидеть на наших рынках.interprise
04.01.2018 22:24и покупать они будут конечно же intel. Это же так логично, до выхода исправленных процов МИНИМУМ полгода год.
Goodkat
04.01.2018 23:27Интересно, а как исправить Meltdown? Отменить кэширование при опережающем исполнении? Добавлять случайные задержки при обращению к кэшу и памяти? Сделать таймер неточным? Можно как-то переделать весь маппинг памяти не сломав весь существующий софт?
MacIn
04.01.2018 22:26Ну, это произойдет не сразу, кмк. Сначала, на панике, откатится вниз, а уже потом, когда дойдет до тотальной замены-апгрейда и пр., попрут продажи и котировки. Нет?
willyd
04.01.2018 23:02Ну еще не известно чем все кончится. Мало ли, что можно заложить в микрокод.
И просадка на 25% для амазона через чур пессимистична. На реальных задачах в объемах ДЦ у aws будет меньше. Но для некоторых проектов, конечно, может сыграть эффект бутылочного горлышка.
Alcpp
05.01.2018 19:56Мало нам было дефицита видеокарт из-за майнеров, теперь будет дефицит процессоров.
Asparagales
04.01.2018 22:16Мне непонятны две вещи. Можно ли будет отключить этот патч и каким образом? Где хотя бы об этом можно будет узнать?
Так и не понял, касается ли эта проблема только Intel или Intel и AMD? Будут ли выпущены патчи для смартфонов/планшетов и произойдет ли падение производительности у них? В случае, если архитектура процессора не x86 / x86-64?Kotofanchik
05.01.2018 00:09To disable the mitigations and regain performance at the expense of security after applying the patch:
reg add «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management» /v FeatureSettingsOverride /t REG_DWORD /d 3 /f
reg add «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management» /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
Get-SpeculationControlSettings вроде показывает что отключилось, тесты показывают возвращение производительности, правда разница в тестах на уровне погрешности ~1.5% туда сюда и до патча и после и после отключения в пропатченной винде.
Tevssar
05.01.2018 00:09Проблемы так-то две Meltdown — Intel и Spectre — Intel и AMD, но по AMD тут менее понятно, встречается информация типа «AMD и Intel уязвимы» и информация, что AMD уязвима только при включенном ebpf.
Asparagales
05.01.2018 00:43Уязвимости Meltdown подвержены все процессоры Intel выпускаемые с 1995 года, за исключением Intel Itanium и Intel Atom, выпущенных до 2013 года и ARM64 (Cortex-A15/A57/A72/A75).
Уязвимости Spectre подвержены процессоры Intel, AMD (только при включенном eBPF в ядре) и ARM64 (Cortex-R7/R8, Cortex-A8/A9/A15/A17/A57/A72/A73/A75).
Исправление проблемы Meltdown для ядра Linux выпущено в виде набора патчей KPTI. Исправление уязвимости Spectre в общем виде пока не выработано, частично предложено обновление микрокода и усиление безопасности отдельных приложений. Обновление для блокирования Meltdown уже выпущено для RHEL, CentOS и Fedora.
www.opennet.ru/opennews/art.shtml?num=47856olartamonov
05.01.2018 01:39AMD (только при включенном eBPF в ядре)
И при выключенном тоже.
eBPF — просто удобный способ демонстрации дырки, не более.
phprus
05.01.2018 15:03за исключением Intel Itanium
Отличный повод воскресить платформу под флагом безопасности. Судя по новостям сейчас только у SPARC похоже нет этих дыр (или я не нашел упоминаний о них).
SergeyMax
04.01.2018 22:17Вот что-то есть.
Там нет вызова ядра, так что этим кодом проверить работоспособность патча скорее всего не получится.
alygin
04.01.2018 22:53+1Intel заявила (без подробностей), что нашла способ устранения обеих уязвимостей (и Meltdown и Spectre). Обновления уже, якобы, выпущены для большинства процессоров моложе пяти лет. Судя по всему, лечат комбинацией патчей ОС и прошивок процессоров.
d-stream
05.01.2018 02:16Правда фразы про то, что многие производители уже проапдейтились — скорее намекает на те самые «замедляющие» патчи (
alygin
05.01.2018 08:30Да, наверняка речь про них. Хотя все основные игроки утверждают, что влияние патчей на производительность практически не заметно для большинства пользователей, но призывают проверять это на своих нагрузках самостоятельно. Как это все сказывается на энергопотреблении, не говорят.
olartamonov
05.01.2018 12:46+1В пиар-отделах всех основных игроков сейчас за любое другое заявление просто молча выводят в коридор и расстреливают за углом.
Паника среди пользователей — последнее, что им всем нужно.khim
05.01.2018 14:31-1Ну, кроме шуток — это таки правда. Проседает (причём сильно-таки проседает, в несколько раз) операция вызова ядра системы. А дальше — зависит от нагрузки.
Если у вас счётная задача (а большинство игрушек, скажем, сюда попадает), то замедление и под микроскопом не разглядеть.
А если у вас там много-много IPC — то вполне можно и двукратное замедление получить…
zx80
05.01.2018 07:09A как посещать даже проверенные сайты, если без JavaScript не работают практически все сайты?????
Naglec
05.01.2018 10:46С копма без ценной информации, как. Или купить на авито комп на Pentium MMX :)
khim
05.01.2018 14:32-1Или купить на авито комп на Pentium MMX :)
Учтите, что Atom до 2013го года — это Pentium MMX и есть.
У нас в семье есть такой… только на него ничего кроме XP не встаёт… а там других дыр — попой жуй, она ж не поддерживается давно.
ALexhha
05.01.2018 11:15MS уже начали накатывать обновления — azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vulnerability но по ходу очень неудачно
perlestius
05.01.2018 13:09Кстати, мне в декабре и на смартфон, и на SMART TV самсунговские прилетели апдейты во второй половине декабря. Причем для ТВ предыдущий апдейт на их сайте был аж от 2015-го года. Совпадение?.. :)
Methos
05.01.2018 14:52Через пяток лет найдут дыру, которую эти 5 лет спокойно хакеры эксплуатируют уже сейчас.
Так что не расстраивайтесь.
Tarasovych
05.01.2018 19:56Есть ли изменения в производительности для Ryzen (до и после обновления, OS Win10)? Может кто тесты находил.
Haoose
06.01.2018 02:28+1Об этом баге знали еще в 2010м…
twitter.com/rootkovska/status/948997805158338560LeonidY
06.01.2018 05:40Это кранты, это ЕЩЕ ОДИН баг. Поставить внутри guest VM последовательность спекулятивной загрузки карты памяти root-а (!) + чтения слова из этой памяти ==> в TLB будет лежать доступ в память root-а из guest-а.
Если это еще работает (все-таки 7 лет прошло), то весь облачный сервис накрылся медным тазом, сбацать дырокол для тех процессоров — нефиг делать. Ох, заставят всех обновить процессоры, заставят.
Suvitruf
cro Автор
Данные разнятся от задачи к задаче.
amarao
syscall'ы выполняются примерно в полтора-два раза медленнее. Если считаешь математику — без изменений, если постоянно делаешь IO — полуторакратная деградация.
willyd
А есть результаты тестов?
Ну или какой-то тест для linux. Я бы сейчас у себя проверил.
netch80
Ну вот Phoronix померял. Думаю, завтра уже будет полдесятка таких тестов.
amarao
А у вас уже фикс приехал? Я вот в убунте/дебиане пока не вижу. А тест — просто любое интенсивное IO. Например, fio'шный бенчмарк быстрого диска (nvme/ssd), или приложение, шлющее много мелких сетевых пакетов.
Mogost
Следите за информацией по фиксу в Ubuntu тут
willyd
Да, на федоре ночью зарелизили.
sysbench провисает в одном тесте на 30%. Визуально, пока все по старому, больше на io-задачах зависаю, типа клонирования образа.
amarao
Бедные файловые сервера…
willyd
Эм… я вообще-то про свой личный ноут писал, если что. И он у меня и до патча подвисал на тяжелых io-задачах.
Рабочие сервера обновлять буду не я. Я только проверил, чтобы все работало после апдейта.
NiTr0_ua
файлсерверам (если это выделенный сервер, без стороннего кода и виртуализации) пофиг. на них просто не ставится патч.
DistortNeo
Учитывая тенденцию отказа от выделенных серверов и повального ухода в облака и повсеместной виртуализации, таки не всегда пофик.
NiTr0_ua
облачному файлохранилищу (если оно, опять-таки, на выделенном сервере) тоже пофиг.
а делать файлохранилище в виртуалке — печаль по просадкам i/o. никто вменяемый таким не занимается.
navion
Справедливо только для KVM (за вычетом AHV), так как с VMware или Hyper-V просадка на уровне погрешности.
bfuvx
И какой уровень деградации под этим понимается в абсолютной и относительной велечине? +19 us на io, например, это много? А какой уровень тогда у VMware или Hyper-V?
navion
Циферки потерялись, но разница по иопсам была в районе 20% при одинаковой latency.
Это поправимо, но неизвестно когда что-то подобное включат в обычном KVM.
johnnymmc
Вот бы было круто, если бы оставили возможность включать/выключать этот фикс когда хочешь — чтобы можно было отключиться от сети и быстренько прогнать IO-intense опеации (например переписать терабайтик данных с одного харда на другой, прогнать вычисления с мемоизацией на диск через shelve или обработать большую HDF5-таблицу через pytables), потом включить обратно и жить спокойно…
amarao
В linux это реализовано. lwn.net/Articles/741878 (статья была написана до объявления про баг).
опция
noptiв параметрах ядра при загрузке определяет будет ли использоваться изоляция или нет.Wyrd
cs8.pikabu.ru/images/previews_comm/2016-01_6/145407311713033599.png