Комментарии 524
Тесты показывают падение на 10-30%.А, к примеру, эти тесты куда более оптимистичны.
Данные разнятся от задачи к задаче.
syscall'ы выполняются примерно в полтора-два раза медленнее. Если считаешь математику — без изменений, если постоянно делаешь IO — полуторакратная деградация.
А есть результаты тестов?
Ну или какой-то тест для linux. Я бы сейчас у себя проверил.
Ну или какой-то тест для linux. Я бы сейчас у себя проверил.
Ну вот Phoronix померял. Думаю, завтра уже будет полдесятка таких тестов.
А у вас уже фикс приехал? Я вот в убунте/дебиане пока не вижу. А тест — просто любое интенсивное IO. Например, fio'шный бенчмарк быстрого диска (nvme/ssd), или приложение, шлющее много мелких сетевых пакетов.
Да, на федоре ночью зарелизили.
sysbench провисает в одном тесте на 30%. Визуально, пока все по старому, больше на io-задачах зависаю, типа клонирования образа.
sysbench провисает в одном тесте на 30%. Визуально, пока все по старому, больше на io-задачах зависаю, типа клонирования образа.
Бедные файловые сервера…
Эм… я вообще-то про свой личный ноут писал, если что. И он у меня и до патча подвисал на тяжелых io-задачах.
Рабочие сервера обновлять буду не я. Я только проверил, чтобы все работало после апдейта.
Рабочие сервера обновлять буду не я. Я только проверил, чтобы все работало после апдейта.
файлсерверам (если это выделенный сервер, без стороннего кода и виртуализации) пофиг. на них просто не ставится патч.
Учитывая тенденцию отказа от выделенных серверов и повального ухода в облака и повсеместной виртуализации, таки не всегда пофик.
облачному файлохранилищу (если оно, опять-таки, на выделенном сервере) тоже пофиг.
а делать файлохранилище в виртуалке — печаль по просадкам i/o. никто вменяемый таким не занимается.
а делать файлохранилище в виртуалке — печаль по просадкам i/o. никто вменяемый таким не занимается.
а делать файлохранилище в виртуалке — печаль по просадкам i/o. никто вменяемый таким не занимается.
Справедливо только для KVM (за вычетом AHV), так как с VMware или Hyper-V просадка на уровне погрешности.
Справедливо только для KVM
И какой уровень деградации под этим понимается в абсолютной и относительной велечине? +19 us на io, например, это много? А какой уровень тогда у VMware или Hyper-V?
Циферки потерялись, но разница по иопсам была в районе 20% при одинаковой latency.
Это поправимо, но неизвестно когда что-то подобное включат в обычном KVM.
Это поправимо, но неизвестно когда что-то подобное включат в обычном KVM.
Вот бы было круто, если бы оставили возможность включать/выключать этот фикс когда хочешь — чтобы можно было отключиться от сети и быстренько прогнать IO-intense опеации (например переписать терабайтик данных с одного харда на другой, прогнать вычисления с мемоизацией на диск через shelve или обработать большую HDF5-таблицу через pytables), потом включить обратно и жить спокойно…
В linux это реализовано. lwn.net/Articles/741878 (статья была написана до объявления про баг).
опция
опция
nopti в параметрах ядра при загрузке определяет будет ли использоваться изоляция или нет.
Как-то вообще не объясняется серьёзность проблемы. Сдампить чужую память — это одно, а вот найти в ней что-то полезное — совсем другое.
Интересно, можно ли на Windows отказаться от изменений, вызывающих замедление работы. На Linux, вроде бы, можно будет.
Интересно, можно ли на Windows отказаться от изменений, вызывающих замедление работы. На Linux, вроде бы, можно будет.
Насколько я понимаю, можно будет выключить через реестр.
Пароли и ключи шифрования в памяти найти относительно просто.
Пароль можно просто подбирать из найденного в памяти. У ключей энтропия выше чем у остальных данных обычно, если при этом мониторить трафик, то можно проверять гипотетические ключи.
С таким объяснением достаточно серьёзно проблема выглядит?
Пароль можно просто подбирать из найденного в памяти. У ключей энтропия выше чем у остальных данных обычно, если при этом мониторить трафик, то можно проверять гипотетические ключи.
С таким объяснением достаточно серьёзно проблема выглядит?
И это всё сможет делать javascript в браузере? Да, я понимаю, что если скомпрометировать популярный сайт, на который зайдёт 100 миллионов пользователей, то у кого-то что-то удастся найти, но в целом — нет, выглядит не очень серьёзно.
Из статьи про SPECTRE:
В части номер 4.3 есть больше объяснений.
Не нужно компрометировать популярный сайт, я прямо сейчас на своём сайте пишу яваскрипт (и даю на него ссылку) который из брауера будет таскать всё что может. У вас несколько вкладок открыто? Даже может быть несколько програм (одна из них — менеджер паролей?), так?
А на ссылку, которую я дал, вы нажали? :-)
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 есть больше объяснений.
Не нужно компрометировать популярный сайт, я прямо сейчас на своём сайте пишу яваскрипт (и даю на него ссылку) который из брауера будет таскать всё что может. У вас несколько вкладок открыто? Даже может быть несколько програм (одна из них — менеджер паролей?), так?
А на ссылку, которую я дал, вы нажали? :-)
Вообще в том же хроме JS вкладки крутится в её собственном процессе. Отдельном.
Дело в том, что уже не в процессах дело. Атака Meltdown позволяет добыть данные из ядра и из других процессов (с некоторыми мелкими оговорками). Без разницы где конкретно данные лежат, в отдельном процессе или в том же самом.
Meltdown и Spectre — разные уязвимости. Возможность что-то сделать из JS заявлена только для Spectre (и то, судя по всему, целенаправленно получить какие-то полезные данные именно с использованием JS там практически нереально). Для Meltdown такого не заявлено.
Она позволяет добыть данные из ядра при условии возможности дёргать нужные сисколы и выполнять нужные инструкции CPU в контролируемых условиях. Из JS этого сделать нельзя, но можно сформировать код, который будет через другую уязвимость из перечисленных читать память своего процесса. Разберитесь в механизме работы, а потом делайте заявления.
Нужно компрометировать популярный сайт, потому что у вашего сайта посещаемость будет несколько ниже. Это понятно, что можно читать память любого процесса в ОС.
TypeError
Старик Столман был всё же прав.
Напомните, в чем именно.
В том, что опенсорс безопасен. Не может в опенсорсе годами жить незакрытая критическая уязвимость.
Был прав.
Был.
Года так до 2014-го.
Был прав.
Был.
Года так до 2014-го.
Во-первых, Столман говорил о том, что проприетарщина небезопасна. Это не то же самое, что говорить, что опенсурс безопасен. А во-вторых, есть несколько примеров многолетних уязвимостей в опенсурсе
Вы о HeartBleed?
Да, как наиболее ярком примере.
Разговоры о сранвительной безопасности опенсорса и коммерческой разработки вообще бессмысленны — практика показывает, что и то, и другое может иметь дыру с амбарные ворота размером, которую могут не замечать месяцами, а то и годами. Впрочем, всёрьез слушать Столлмана, особенно когда он опять забывает таблетки принять, тоже не очень осмысленное действие.
Применительно к процессорам же опенсорс — это и вовсе смешно, будет примерно как опенсорсные ноутбуки: очень дорого, очень громоздко и по производительности способно на равных конкурировать со средним вайфай-роутером.
Разговоры о сранвительной безопасности опенсорса и коммерческой разработки вообще бессмысленны — практика показывает, что и то, и другое может иметь дыру с амбарные ворота размером, которую могут не замечать месяцами, а то и годами. Впрочем, всёрьез слушать Столлмана, особенно когда он опять забывает таблетки принять, тоже не очень осмысленное действие.
Применительно к процессорам же опенсорс — это и вовсе смешно, будет примерно как опенсорсные ноутбуки: очень дорого, очень громоздко и по производительности способно на равных конкурировать со средним вайфай-роутером.
А как же bug 12309?
Да, Столман-гений (я абсолютно серьёзно). А процессоростроители заигрались с бекдорами и неустойчивыми архитектурами. Я надеялся, что хотя бы на APM/AMD сбежать получится, но некуда бежать, Карл! Получается, даже Байкал дырявый, остался только Эльбрус? На Байкал у моей фирмы денег ещё хватит, а на Эльбрус — не наскребу :(
А Байкал почему дырявый?
Он на лицензированном ARM-е сделан. Кстати, к вопросу «зачем изобретать велосипед своей архитектуры?»
Вообще-то на MIPS P5600.
Посмотрел — действительно, рано я запаниковал, Байкалу Т1 пока можно доверять. Тяжело это, когда в ИТ не работа, а ходьба по трясине, нервы ни к чёрту становятся. Спасибо, что поправили меня.
На Байкале-Т1 все эти баги не работают с гарантией если первые 128МБ памяти (там только 128МБ из первых 512МБ распределены под память) НЕ используются для user приложений. А к user страницам доступ либо через EVA, либо через HIGHMEM. В текущем ядре используется HIGHMEM, осталось только запретить рапсределять первые 128МБ под страницы user.
Такой запрет, кстати, ускорит работу с DMA, так как не нужен будет второй cache flush.
Такой запрет, кстати, ускорит работу с DMA, так как не нужен будет второй cache flush.
Разобрался.
Есть Байкал-Т1 MIPS P5600 www.baikalelectronics.ru/products/T1
а есть Байкал-М, он на ARMv8-A www.baikalelectronics.ru/products/M
Второй для меня, естественно, теперь умер.
Есть Байкал-Т1 MIPS P5600 www.baikalelectronics.ru/products/T1
а есть Байкал-М, он на ARMv8-A www.baikalelectronics.ru/products/M
Второй для меня, естественно, теперь умер.
в тырнете есть кучи проектов процов, например, на основе ПЛИС, только кто для них будет оськи адаптировать… есть сайты, где ссылки на такие проекты собраны десятками, если не сотнями, у каждого проца своя разрядность, программная модель, аппаратная архитектура и система команд.
opencores.org и там не все так плохо. Многие ядра пытаются поддерживать wishbone и быть хоть с чем—то совместимым. Вон, OpenRISC даже в космосе побывал и для него есть полноценный тулчеин, даже сборка линукса, а он вроде как даже не самый продвинутый среди открытых архитектур. Проблема в другом — если говорить про асик— нет гарантий, что на заводе ничего в него не дошьют, да и это очень дорого. Если говорить про плис — либо чертовски медленно, либо чертовски дорого (как правило, и то, и другое, если говорить про построение архитектуры общего назначения на плис), да ещё и не на каждую плисину влезет полноценная soc. Но я давно мечтаю собрать на основе маленькой платы с плис типа такой какой-нибудь openphone с чертежами для 3D принтера
НЛО прилетело и опубликовало эту надпись здесь
Что насчёт IBM Power?
Additional 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
access.redhat.com/security/vulnerabilities/speculativeexecution
Есть такой анекдот про поручика Ржевского и оральный секс.
В общем, если у процессора кэш и предсказание ветвлений есть, то Spectre ваш.
В общем, если у процессора кэш и предсказание ветвлений есть, то Spectre ваш.
В общем, если у процессора кэш и предсказание ветвлений есть, то Spectre ваш.Спекулятивное исполнение и точный таймер нужны…
А какой таймер используется? мультимедийный? а если его отключить, вон в Win XP SP2 на него драйвера вообще нет, в SP3 драйвер есть, но он не используется.
Обычно пользуется RDTSC. Но при наличии нескольких ядер можно и просто счётчиком обойтись…
Напомните, плз)
— Господин поручик — вы, говорят, большой специалист в этих делах. Скажите, вон та дама в рот берет?
— Которая? — переспрашивает Ржевский.
— Вон та, в желтом платье.
— Ну, я со спины сказать не могу, — пожимает плечами поручик. В этот момент дама поворачивается, поручик Ржевский пристально смотрит ей в лицо и говорит:
— Эта — берет.
Корнет подходит к даме, они о чем-то беседуют и удаляются. Через некоторое время корнет возвращается, довольный:
— Действительно, берет! Но как вы определили, поручик?!
— Послушайте, корнет, — веско произносит поручик Ржевский, — Рот есть — значит берёт!
Примерно та же история с процессорами и Spectre.
— Которая? — переспрашивает Ржевский.
— Вон та, в желтом платье.
— Ну, я со спины сказать не могу, — пожимает плечами поручик. В этот момент дама поворачивается, поручик Ржевский пристально смотрит ей в лицо и говорит:
— Эта — берет.
Корнет подходит к даме, они о чем-то беседуют и удаляются. Через некоторое время корнет возвращается, довольный:
— Действительно, берет! Но как вы определили, поручик?!
— Послушайте, корнет, — веско произносит поручик Ржевский, — Рот есть — значит берёт!
Примерно та же история с процессорами и Spectre.
> Примерно та же история с процессорами и Spectre.
Если права доступа к страницам ядра проверяются ДО запуска подгрузки в кэш, то остается только eBPF, который сам по себе бяка (JIT в ядре!). К тому же он кажется требует привелегий. Гуглы вроде не нашли в текущем коде ядра Linux подходящих последовательностей помимо возможности сформировать их через eBPF.
Если права доступа к страницам ядра проверяются ДО запуска подгрузки в кэш, то остается только eBPF, который сам по себе бяка (JIT в ядре!). К тому же он кажется требует привелегий. Гуглы вроде не нашли в текущем коде ядра Linux подходящих последовательностей помимо возможности сформировать их через eBPF.
Тут два момента.
Во-первых, ядро большое, а подходящие для атаки последовательности могут быть разными, так что что там найдётся в конкретной версии ядра, собранной конкретным компилятором с конкретными настройками — это ещё бабка надвое сказала. Там не очень-то много надо.
Во-вторых, авторы второй работы, не гуглевской, вообще с ядром не заморачивались, а просто взяли DLL'ки, используемые их софтиной, и поискали нужную последовательность в них, резонно предположив, что эти же DLL'ки с большой вероятностью будут шариться с другими процессами.
Так что eBPF просто радикально облегчает задачу, но не более того.
Во-первых, ядро большое, а подходящие для атаки последовательности могут быть разными, так что что там найдётся в конкретной версии ядра, собранной конкретным компилятором с конкретными настройками — это ещё бабка надвое сказала. Там не очень-то много надо.
Во-вторых, авторы второй работы, не гуглевской, вообще с ядром не заморачивались, а просто взяли DLL'ки, используемые их софтиной, и поискали нужную последовательность в них, резонно предположив, что эти же DLL'ки с большой вероятностью будут шариться с другими процессами.
Так что eBPF просто радикально облегчает задачу, но не более того.
и вдруг в этот момент шутки про Эльбрус уже не так смешны. И получается что оборонка в РФ, где используется Эльбрус работает, а остальной мир — нет (конечно я про фантастический рассказ).
НЛО прилетело и опубликовало эту надпись здесь
А где-то есть список подверженных этому CPU?
Все интел, выпущенные за последние 10 лет :)
Кроме Атомов до 2013 и Итаниумов
Т.е. если машина старше 10 лет, то 100% проблемы нет? И если АМD до 13-го года?
На АМД нет Мелтдауна, только Спектра
Вам теперь тоже придётся реализовать защиту?
Пока в этом нет особой необходимости.
Спектра исправляется\локализуется на стороне каждой прикладной программы в отдельности. А Мелтдаун опасен в основном для многопользовательских систем с множественным доступом различных субьектов, между которыми нет доверия. У РеактОСа же в самой ближайшей перспективе наиболее реалистичные сценарии использования предполагают однопользовательский доступ в изолированных сегментах инфраструктуры.
Еще важно отметить, что в РеактОС существующие средства доставки и инжекции вредоносного ПО на данный момент не способны выполнить свою функцию.
Безусловно, в дальнейшем определенные механизмы безопасности будут внедрены, а пока мы посмотрим, как с этим справятся остальные вендоры и воспользуемся их опытом.
Спектра исправляется\локализуется на стороне каждой прикладной программы в отдельности. А Мелтдаун опасен в основном для многопользовательских систем с множественным доступом различных субьектов, между которыми нет доверия. У РеактОСа же в самой ближайшей перспективе наиболее реалистичные сценарии использования предполагают однопользовательский доступ в изолированных сегментах инфраструктуры.
Еще важно отметить, что в РеактОС существующие средства доставки и инжекции вредоносного ПО на данный момент не способны выполнить свою функцию.
Безусловно, в дальнейшем определенные механизмы безопасности будут внедрены, а пока мы посмотрим, как с этим справятся остальные вендоры и воспользуемся их опытом.
Спектра исправляется\локализуется на стороне каждой прикладной программы в отдельности.
Ну если быть честным, то спектру нельзя исправить чисто программно, можно только минимизировать возможность атаки (ну или снизить вероятность что-ли)…
Или вы действительно считаете, что уменьшением точности таймера (как превентивно сделали например в некоторых браузерах) или перекомпиляцией софта (дабы заменить уязвимые последовательности) вы исключите фактор атаки? Ну-ну...
Еще раз, — спектру практически невозможно полностью закрыть программно, от слова совсем, пока во всяком случае. Еще менее реально закрыться от возможных будущих подобных "уязвимостей". Только если есть возможность как-то отключить branch prediction (например для потока "исполняющего" javascript и/или потенциальный "чужой" код). Или выключить кэши процессора, ну или написать что-то типа "антивирус для процессора" (это сарказм если что).
Кроме того уже сейчас нужно различать те-же CVE-2017-5715 и CVE-2017-5753 (например для 5715 нужен еще и микрокод-update, т.е. чисто программно у вас шансов "защититься" просто нет).
А ящик пандоры только-только открылся — я к тому что завтрашний зоопарк возможных CVE-дериватов, эксплуатирующих такие и подобные им дыры (т.е. speculative execution и иже с ними), пока сложно себе представить.
Но то что он будет, это однозначно.
Спектр:
Интел предлагает вставлять LFENCE после условного перехода для фикса Варианта-1, и использовать команды PUSH + RET вместо перехода по регистру. Вроде LLVM/gcc уже даже патч есть.
Интел предлагает вставлять LFENCE после условного перехода для фикса Варианта-1, и использовать команды PUSH + RET вместо перехода по регистру. Вроде LLVM/gcc уже даже патч есть.
Что это значит? Изменение (хорошее замедление) всех jit-компиляторов, чтобы они случайно не сгенерили опасный код из пользовательского js. Очень интересно, как это понравится разработчикам браузеров, которые очень упорно соревнуются друг с другом за каждый процент скорости js. «Наш движок, конечно, медленный, зато он защищён от Spectre»?
Но если у атакующего — возможность выполнять свой код с минимальными привилегиями, то зачем ему в свой код вставлять LFENCE?
Но если у атакующего — возможность выполнять свой код с минимальными привилегиями, то зачем ему в свой код вставлять LFENCE?
А теперь берем и внимательно читаем "правильную литературу" про спектру, например здесь особливо пункты 7-й и 8-й.
Если коротко, про то чего вам тут Intel предлагает: а) этим всё не исправить и история далеко не окончена, и б) хочется спросить — они это вообще серьезно?! Если это правда предложение инженеров Интел (а не отмазка какого-то "продажника")… тогда все еще хуже.
Там пишут, что предположительно вообще все когда либо выпущенные 86 процессоры Интел с спекулятивным исполнением. А это с 95 года. Просто в стоей работе авторы продемонстрировали уязвимость на сравнительно новых процессорах.
Еще бы помнить когда он выпущен.
ark.intel.com поможет.
Но, на самом деле, сложно выяснить есть ли в том или ином процессоре этот баг т.к. потроха процессора закрыты и как он обрабатывает инструкции — покрыто мраком.
Единственный выход, который мне видится — запускать PoC эксплоит (найти бы его еще) на каждом из них и смотреть результат.
Но, на самом деле, сложно выяснить есть ли в том или ином процессоре этот баг т.к. потроха процессора закрыты и как он обрабатывает инструкции — покрыто мраком.
Единственный выход, который мне видится — запускать PoC эксплоит (найти бы его еще) на каждом из них и смотреть результат.
Все интел 1995 года (кроме атомов до 2013 и итаниумов). meltdownattack.com
Вот например на П4 дыру вообще видно невооруженным взглядом:
Так вот почему Интел процессоры пытался в картриджи прятать…
Это у вас бракованный, сдайте по месту покупки.
Это старая, для неё давно уже патч есть.
Для того, чтобы произвести запись в write-protected защищенную область, отверстие надо заклеить изолентой?
Red Hat пишет о существующих эксплойтах для IBM System Z, POWER8 и POWER9.
Вот единственная конкретика, которую удалось найти на сайте 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 Series
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 Series
Странно, у меня Skylake (14нм) и уязвимость есть, судя по тесту вот этой штукой: gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6
Пока из не подверженных риску я вижу только Атомы серии D (D2700, D2550, D2500), есть что-то ещё?
лучше отключите JavaScript даже при посещении безопасных сайтов
Нормально пользоваться Хаброй с отключённым JS — возможно?
(не говоря уже об обычных сайтах сплошь увешанных js)
Тут уже вы сами решайте что вам надо — рюшечки на сайтах или безопасность
Проблема в том, что js — уже давно далеко не «рюшечки на сайтах», а основной функциональный элемент, отключение которого смерти подобно (этого самого сайта).
Опять же — сами решайте что вам важнее
В нашем мире можно удалить браузер, а не выключать JS. Эффект будет примерно одинаковым. Вы даже комментарии здесь писать не сможете без JS
А чего все докопались до JS? Его то как раз таки можно быстренько изпоганитьправить :-)
Что видимо и произойдёт в ближайшие дни.
Что видимо и произойдёт в ближайшие дни.
Ох, я очень надеюсь что эта ситуация выдаст пинка проблеме с JS и его наконец выпилят и заменят на что-то современное, ах мечты-мечты…
Проблема же не в JS.
Это в данной ситуации проблема не с JS, а я говорю о JS в целом…
Так-то да, проблема в принципе в коде, который может исполняться просто от открытия веб-страницы, но JS — самое распространённое зло здесь (менее распространённые — Flash, Java, к примеру).
А без JS хабр вполне возможен, если напишут отдельную версию — сделать простую форму для написания статьи/комментариев.
А без JS хабр вполне возможен, если напишут отдельную версию — сделать простую форму для написания статьи/комментариев.
Вроде, работает.
Для хрома Google вроде как рекомендует включить chrome://flags/#enable-site-per-process если у вас версия ниже 64
И как это спасет?
Это как для защиты от ядерной бомбы используйте бронежилет.
Chrome втихаря ставит свой software reporter tool, который начинает шариться по всем дискам без всяких уязвимостей.
Интересно, что будет если отключить WebWorker-ы?
Интрига дня/недели: подвержены ли процессоры Apple?
Разве Apple вернулась на Motorolla в своих дескотпах/ноутбуках?
У Apple те же самые интеловские процессоры — поэтому да, конечно.
https://ru.wikipedia.org/wiki/Apple_Ax я про эти.
Одна из атак (Spectre) работает на ARMах тоже, но я не знаю про те конкретные которые iPhone/iPad.
Spectre с большой вероятностью работает на всех ipad/iphone. Практически все современные ARM ядра ей подвержены.
Meltdown подвержены только ядра ARM Cortex-A75 (на них еще нет выпущенных процессоров)
Однако, Apple не использует готовые ядра Cortex, а разрабатывает ядра сама. На текущий момент нет информации об атаке Meltdown на ARM ядра Apple. Вот ждемс информацию.
думается Pentium MMX и прочие древности наверное не подвержены, но что нам с того?
Apple уже выпустила заявление, отвечающее «да».
Пожалуй, самое вероятное и неприятное применение на данный момент — получение дампа системной памяти во время выполнения JavaScript.Больше похоже на заявление от представителей жёлтой прессы. Низкоуровневые операции (типа получения данных по произвольному указателю), которые скорее всего будут нужны для эксплуатации уязвимости, из JS недоступны. В общем, или покажите рабочий пруф, или не распространяйте сомнительную информацию и не нагнетайте бесполезную панику.
В первоисточнике есть JS сниппет, который читает память процесса браузера https://spectreattack.com/spectre.pdf, эта ссылка есть в статье...
Во-первых, рабочего кода там нет. Там есть только вот эти 5 строк, которые лишь маленький кусочек необходимого кода (содержимое остального кода там описано словами и очень примерно):
if (index < simpleByteArray.length) {
index = simpleByteArray[index | 0];
index = (((index * TABLE1_STRIDE)|0) & (TABLE1_BYTES-1))|0;
localJunk ^= probeTable[index|0]|0;
}Полного рабочего кода там быть и не может по определению, у white hat исследователей не принято эксплоиты такой величины публиковать чтобы каждый дурак мог копировать и использовать.
Вчитался в доку Spectre. 100% рабочего кода на JS там нет, но описания достаточно, чтобы его повторить. Тем более, что в конце дока есть рабочий код на C, демонстрирующий основную идею.
Итого у нас есть возможность узнавать содержимое байтиков за пределами выделенного JS-массива. Его физический адрес мы не знаем, но изучив как JS-движок хранит переменные в куче, возможно где-то рядом с массивом мы сможем найти какой-нибудь указатель, который подскажет где мы вообще физически находимся. С этим, возможно, дальше будет немного проще плясать.
Но вообще активная эксплуатация всё ещё выглядит сомнительной. Скорость «чтения» будет очень маленькой. Как я понимаю, даже пример на C читает где-то 1000-2000 байт в секунду. Всё адресное пространство не прочитаешь с такой скоростью за разумное время, явно нужно точно знать куда смотреть относительно того куда в памяти попал этот JS-массив.
Плюс на 64-битных системах у нас вырисовывается ограничение, что мы можем «смотреть» только в окошко размером в 4 гигабайта, поскольку инты в JS 32-битные. Таким образом, использование Meltdown из браузера также сильно осложнено — весьма вероятно, что до интересных системных структур мы просто не сможем дотянуться, даже если сможем прикинуть где они относительно нашего массива находятся.
Не в курсе как там в JS, а для выполнения WebAssembly на 64-разрядных системах слышал что намеренно резервируется адресное пространство размером в 4 гигабайта, потому что указатели внутри WebAssembly 32-разрядные, и уверенность что они не могут выйти за пределы своего окошка позволяет делать меньше проверок во время выполнения.
Итого у нас есть возможность узнавать содержимое байтиков за пределами выделенного JS-массива. Его физический адрес мы не знаем, но изучив как JS-движок хранит переменные в куче, возможно где-то рядом с массивом мы сможем найти какой-нибудь указатель, который подскажет где мы вообще физически находимся. С этим, возможно, дальше будет немного проще плясать.
Но вообще активная эксплуатация всё ещё выглядит сомнительной. Скорость «чтения» будет очень маленькой. Как я понимаю, даже пример на C читает где-то 1000-2000 байт в секунду. Всё адресное пространство не прочитаешь с такой скоростью за разумное время, явно нужно точно знать куда смотреть относительно того куда в памяти попал этот JS-массив.
Плюс на 64-битных системах у нас вырисовывается ограничение, что мы можем «смотреть» только в окошко размером в 4 гигабайта, поскольку инты в JS 32-битные. Таким образом, использование Meltdown из браузера также сильно осложнено — весьма вероятно, что до интересных системных структур мы просто не сможем дотянуться, даже если сможем прикинуть где они относительно нашего массива находятся.
Не в курсе как там в JS, а для выполнения WebAssembly на 64-разрядных системах слышал что намеренно резервируется адресное пространство размером в 4 гигабайта, потому что указатели внутри WebAssembly 32-разрядные, и уверенность что они не могут выйти за пределы своего окошка позволяет делать меньше проверок во время выполнения.
Согласен, сейчас пример кода на уровне "proof-of-concept", и читать всю системную память он не сможет by design/
Однако, в голову приходит такое практическое применение дырки — найти в памяти куки (в памяти сандбокса вполне могут остаться куки от ранее посещенных во вкладке страниц), и утащить себе валидные session_id/token-ы от чужих сервисов.
Конечно, задача не тривиальная, но увы, кажется решаемая.
Во-вторых, чтение памяти своего процесса (где живёт вкладка) и получение дампа всей системной памяти — разные вещи.После установки вот того самого патча, который обещает всё замедлить на 30% — да.
Сейчас операционки устроены так, что в них сразу вся физическая памяти размапирована в таблицах всех процессов — просто к ней нет доступа из-за соотвествующих прав на память. Но спекулятивное исполнение на это плюёт!
То есть любой процесс может потихоньку-полегоньку прочитать всю память всех процессов на всей системе.
Насколько я понимаю, единомоментно в таблицах сидит только память текущего процесса и ядра. То есть читать можно только ядро, а в чужие процессы попасть получится, только если получится поднять привелегии до рута по результатам чтения памяти из ядра.
Это актуально, только для 32 битных операционных систем. Для x64 немного сложней и как я понимаю это приводит к тому, что можно читать и соседний процесс.
В 64х битных Linux-ах, например, вся память смаплена в ядро, соотвтетсвенно имея доступ к памяти ядра, можно иметь доступ к любой странице
В 32-битных также было долгое время. Когда память перевалила за 950MB — начались пляски с бубнами и замедлением. В 64-битных системах от них отказались.
Когда память перевалила за 950MB
Что вы имеете в виду?
На «старых» операционных системах (Windows 9X, Linux 1.x, NT не помню до какой версии) адресное пространство делилось 3GB/1GB и в том 1GB, которое доставалось ядро ко всему прочему жил ещё и полный линейным маппинг физической памяти. Это никого не напрягало, так как тогда 64MB — было огромным обьёмом, а об 1GB можно было только мечтать. Реально система могла стартовать где-то с 950MB с простенькой видеокартой и с 750-800MB если использовался продвинутый ускоритель.
Потом объёмы памяти росли, 64бита всё никак не приходили и пришлось пристраивать костыли… когда 64бита, наконец, пришли, от костылей, разумеется, отказались.
Потом объёмы памяти росли, 64бита всё никак не приходили и пришлось пристраивать костыли… когда 64бита, наконец, пришли, от костылей, разумеется, отказались.
Насколько я понимаю, единомоментно в таблицах сидит только память текущего процесса и ядра.Ага. Только «память ядра» по умолчанию включает в себя, в том числе, прямой доступ ко всей физической памяти системы.
Так просто удобнее и быстрее. На 32-битных системах с более, чем гигабайтом памяти, приходится плясать. На 32-битных системах с 950MB памяти (и менее), можно «не париться»… вернее «можно было».
Это происходит только в плоской модели? В случае сегментации, насколько я понимаю, такой трюк не прокатит.
В long mode отказались же от сегментации.
Я знаю. И спрашиваю конкретно про модель с сегментацией. Ведь если для чтения ядерной памяти надо загружать ядерный же селектор из GDT с DPL=0, что выкинет исключение при RPL=3, то до спекулятивного доступа к «запрещенной» ячейки памяти черед не дойдет. Верно?
Игнорирует ли чтение при спекулятивном выполнении ограничение на размер сегмента? Вероятно, игнорирует, раз игнорирует защиту страниц.
Практическая ценность этого вопроса какая? В известных мне ОС не делают разделение kernel и user с помощью непересекающихся сегментов. Проверять не на чем.
Практическая ценность этого вопроса какая? В известных мне ОС не делают разделение kernel и user с помощью непересекающихся сегментов. Проверять не на чем.
Игнорирует ли чтение при спекулятивном выполнении ограничение на размер сегмента?
Сегмент может быть расположен «вверху», а данные ядра — внизу. Теоретически. Не все АП может быть смаппировано. Ну, допустим, не проверяет, но там сверху — просто дыра, не мапированная на физическую память.
Практическая ценность этого вопроса какая? В известных мне ОС не делают разделение kernel и user с помощью непересекающихся сегментов. Проверять не на чем.
Думаю о своей хоббийной ОС, где такое разделение есть.
Я бы проверил из любопытства, но пока еще детально не понял механизм эксплуатации, только косвенно по вашим комментариям про array1 и данные кеша, буду читать техническое описание уязвимости позже.
Сегмент может быть расположен «вверху», а данные ядра — внизу. Теоретически.
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-битная, раз можно рулить сегментами? Странно вкладываться в умирающую архитектуру, но хобби бывают всякие.
Сегмент может быть расположен «вверху», а данные ядра — внизу.
Вы правда думаете что там при наличии проверки на выход за границы сегмента отдельно проверяется переполнение?
Ведь если для чтения ядерной памяти надо загружать ядерный же селектор из GDT с DPL=0, что выкинет исключение при RPL=3, то до спекулятивного доступа к «запрещенной» ячейки памяти черед не дойдет. Верно?Неверно. Всё это проверяется уже потом, при «нормальном» исполнении (вернее при «отставке» операций). Спекулятивное же на всё это плюёт, так как если «случится бяда» — то этого же всё равно никто не увидит.
Верно, но при этом у нас будет на одну инструкцию больше — сначала загрузка селектора, что емнип достаточно долгий процесс, потому что надо подгрузить теневую часть из таблицы, и только потом сама инструкция доступа к памяти, спекулятивное выполнение которой можно использовать. Я не уверен, просто кажется, что более долгая цепочка — ве инструкции, которые должны выполнится спеклятивно вместо одной — не позволят или затруднят использование этой уязвимости. Или глубина сп. выполнения намного глубже?
Ах да, я протупил. В таком случае мы можем и локальный селектор использовать, если ничего не проверяется при сп. выполнении и можно «свернуть» память через переполнение.
Или глубина сп. выполнения намного глубже?А вы посчитайте. Длина конвеера — 12-14 тактов, одновременно современные CPU могу исполнять 3-4 инструкции за такт… так что теоретически могут исполняться спекулятивно полсотни инструкций и больше, а практически 10-20 — в лёгкую.
Логично. Ну, тогда действительно разницы нет.
Хотя, все зависит от того, на какой стадии проверяются права доступа при загрузке селектора. Его же надо загружать из памяти, и последующая инструкция чтения из запрещенной области не может быть исполнена спекулятивно в параллели, потому что надо рассчитать смещение, которое нельзя расчитать до загрузки селектора.
Но да, это неважно, если сработает трюк с переполнением адреса локального сегмента.
Но да, это неважно, если сработает трюк с переполнением адреса локального сегмента.
Ну, прочитать все же не в едином и консистентном состоянии, конечно — там порядки величин — 1000 байт в секунду, так что это все же на уровне «погрепать в надежде, что попадется что-то интересное». Но при массовой атаке оно у кого-нибудь да найдется…
Вот и пруфов подвезли
twitter.com/misc0110/status/948706387491786752/photo/1
twitter.com/misc0110/status/948706387491786752/photo/1
Ваш пруф явно выполняется не в браузере.
Сие как бы ни разу не улучшило ситуацию. Процесс-перехватчик запущен не из-под рута, а получил доступ к памяти другого процесса — замечательно.
В моём изначальном сообщении, на которое вы ответили, я указал, что JS не даёт возможности обратиться за данными по произвольному указателю. Нет такой операции как класс. Вы привели пример совершенно не в тему, поскольку у вас запускается нативный код, у которого проблем с использованием произвольных указателей нет.
blog.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.
Я бы не ждал готовых эксплоитов до релизов патчей для всех популярных ОС.
Низкоуровневые операции (типа получения данных по произвольному указателю), которые скорее всего будут нужны для эксплуатации уязвимости, из JS недоступныДля атаки нужно иметь код, работающий с массивом, данные в котором мы контролируем (что нам легко сделает jit-компилятор), нужны точные таймеры (например, на web-workers, если обычный таймер загрублён js-движком), и нужно знать адрес буфера в процессе браузера. Последнее есть проблема, хотя её решает другой эксплойт — AnC.
> Комментарии Google
ССылка битая
ССылка битая
Маки пропатчили в 10.13.2, никто даже и не заметил.
они думали что просто батарейка на маке стареет и он работает медленне, чтобы неожиданно не выключиться
НЛО прилетело и опубликовало эту надпись здесь
Meltdown может и пропатчили, а вот Spectre на 10.13.2 работает замечательно
От статьи таки ожидал хоть каких-нибудь технических подробностей: что за уязвимость, как обнаружили и т.д., а под катом всего лишь куча ссылок. Нехорошо.
Мне показалось бесполезным портить удовольствие, спойлерить и пересказывать оригинальные документы (вот же, приложены) — там все великолепно раскрыто и описано.
Ну, а мне показалось бесполезным читать статью ни о чём.
Вам нужна развернутая лекция и перевод первоисточника? Я с удовольствием дополню статью попозже, когда руки дойдут. Просто события разворачиваются довольно стремительно, на западных площадках все коллективно чешут головы и консолидируют информацию сообща.
Я написал первый быстрый пост за 10 лет на хабре в надежде, что он пригодится хотя бы паре тысяч людей и не ожидал, что приложенного подробнейшего академического документа с примерами будет мало для первичного ознакомления. Если лично вам все это не оказалось полезным, извините что не оправдал ожиданий.
Я написал первый быстрый пост за 10 лет на хабре в надежде, что он пригодится хотя бы паре тысяч людей и не ожидал, что приложенного подробнейшего академического документа с примерами будет мало для первичного ознакомления. Если лично вам все это не оказалось полезным, извините что не оправдал ожиданий.
Было бы полезно сжато, в двух словах, изложить суть уязвимости (разумеется, если вы сами ее понимаете). Так сказать, идею. Для неспециалистов.
А пока что я прочитал весь ваш текст (не ходя по ссылкам на первоисточники) и половину комментариев. И самое интересное, что увидел — это ГИФка в твите, где хоть внешне иллюстрируется, как один процесс тащит данные из другого.
А пока что я прочитал весь ваш текст (не ходя по ссылкам на первоисточники) и половину комментариев. И самое интересное, что увидел — это ГИФка в твите, где хоть внешне иллюстрируется, как один процесс тащит данные из другого.
Постарался разжевать тут: habrahabr.ru/post/346078
А я вообще только ради комментариев сюда зашёл, как и ожидал — получил информации намного больше, чем в статье.
AMD с ARM также уязвимы, но атаку реализовать сложнее.
AMD уязвим только к первому виду атаки, и закрыть уязвимость можно без потери производительности. Не надо их в одну кучу с интелом и армом смешивать.
То есть если не хотим на 10-30% замедлять работу системы, дружно топаем на AMD? Благо они в 2017 году выкатили новые приличные процессоры Zen.
Вообще как так вышло, что AMD обошла чаша сия?
Вообще как так вышло, что AMD обошла чаша сия?
Я почему-то не уверен, что найду достойную рабочую станцию типа ZBook/EliteBook на AMD. :(
От SUSE пришла рассылка с обновлением kernel-firmware и описанием:
17h — это как раз Zen. В свете такого описания мне очень интересно, во сколько раз отключение предсказания переходов уменьшит производительность этих процессоров.
— 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. В свете такого описания мне очень интересно, во сколько раз отключение предсказания переходов уменьшит производительность этих процессоров.
У AMD нету TSX-NI, и заставить через него срабатывать спекулятивную загрузку не получится. Не знаю правда что там с Advanced Synchronization Facility (ASF), может ли он быть тут использован.
Кроме того, такое впечатление, что AMD проверяет доступ до того, как запускает операцию загрузки в кэш.
То есть, остаются только JIT exploit типа eBPF.
Кроме того, такое впечатление, что AMD проверяет доступ до того, как запускает операцию загрузки в кэш.
То есть, остаются только JIT exploit типа eBPF.
Все это очень похоже на большой фейк.
Нет ссылок ни на тестеров ни на объективные результаты.
Скоро напишут, что при открытии двери в туалет замедляется работа кэша второго уровня.
Нет ссылок ни на тестеров ни на объективные результаты.
Скоро напишут, что при открытии двери в туалет замедляется работа кэша второго уровня.
А как же эта «пруф-гифка» twitter.com/misc0110/status/948706387491786752/photo/1 из комента повыше? :)
Нет, всё это похоже на Heatbleed, когда сначала утверждалось что всёвиврете, а потом вышли очень наглядные пруды и сомнений (надеюсь) не осталось.
Нет не фейк. Обе уязвимости. Почитайте на оф. сайте уязвимостей. Черным по белому, для простых смертных написанно, как эксплуатировать. Как новичок-специалист я могу сказать, что такие уязвимости имеют место быть, иногда даже в менее страшной форме и тем не менее на этот раз оно оказалось в настолько важном месте.
AMD с ARM также уязвимы, но атаку реализовать сложнее.
а можно немного подробнее? насколько сложнее? какие векторы атаки возможны?
В интернетах гуляет эта картинка
спасибо! жаль не могу поставить лайк
Из этой картинки следует, что проблем у процессоров AMD под windows нет. И под линукс тоже нет, если ты сам ядро не твикал. Это правда так?
Про Meltdown — правда (точнее, теоретическая возможность повторить его на AMD есть, но практически она не реализована и даже не показано, что она в принципе реализуема).
Про Spectre — нет.
Вот демонстратор, там в комментариях народ развлекается с самыми разнообразными процессорами, начиная аж с Pentium M, и под разными ОС. В основном интелы, но AMD тоже есть, на них тоже работает.
Кроме того, один из вариантов Spectre AMD официально признаёт как работающий с пометкой «software update to be made available».
Про Spectre — нет.
Вот демонстратор, там в комментариях народ развлекается с самыми разнообразными процессорами, начиная аж с Pentium M, и под разными ОС. В основном интелы, но AMD тоже есть, на них тоже работает.
Кроме того, один из вариантов Spectre AMD официально признаёт как работающий с пометкой «software update to be made available».
Negligible performance impact expected.
В этом вся разница. Ошибки были, есть и будут. Но если они исправляются практически без потери производительности — то это приемлемо. Наверное…
Со Spectre всё сложно, см. spectreattack.com/spectre.pdf (особенно пункт 7).
Объём трудозатрат на исправление софта исходя из имеющихся данных трудно оценить даже по порядку (точнее, попробовать можно, но эта оценка вызывает ужас).
Объём трудозатрат на исправление софта исходя из имеющихся данных трудно оценить даже по порядку (точнее, попробовать можно, но эта оценка вызывает ужас).
В документе от AMD говорится о патчах ОС / ПО, которых достаточно для нейтрализации Spectre на системах AMD. Непонятно, достаточно ли будет патча ОС и/или браузера, чтобы предотвратить воровство паролей через JS, использующий Spectre. Также непонятно, если в пропатченной ОС будет запущен вирус с правами пользователя, сможет ли он получить доступ ко всей оперативной памяти системы используя Spectre.
Это вообще не документ, а так, временная затычка.
Фразу «нам необходимо пропатчить всё существующее ПО в неизвестном количестве мест» тоже можно закончить на «и этого будет достаточно для нейтрализации Spectre».
Фразу «нам необходимо пропатчить всё существующее ПО в неизвестном количестве мест» тоже можно закончить на «и этого будет достаточно для нейтрализации Spectre».
Для Clang и GCC уже есть патчи которые защищают от SPECTRE
Где?
Вообще-то я не понимаю, почему они сосредоточились только на переходе по регистру. Простой условный переход, условие которого вычисляется в зависимости от неизвестного в данный момент значения может скорее всего вызвать выдергивание кэш строки по известному адресу в команде загрузки сразу за этим переходом.
Я не силен в x86 ассемблере (забыл его), но что-то типа
— вычисление условия А, например по слову из памяти или как последнее в цепочке вычислений
— условный переход по условию А, который всегда выполняется в нормальной ситуации
— загрузка слова по регистру, который известен задолго до и который содержит «нехороший» адрес.
В нормальном выполнении загрузка никогда не срабатывает, так как условный переход идет нафиг всегда. При спекулятивном выполнении есть большой соблазн запустить эту загрузку на всякий случай заранее, хотя в момент запуска еще не известно значение условия А. Приплыли.
Я не силен в x86 ассемблере (забыл его), но что-то типа
— вычисление условия А, например по слову из памяти или как последнее в цепочке вычислений
— условный переход по условию А, который всегда выполняется в нормальной ситуации
— загрузка слова по регистру, который известен задолго до и который содержит «нехороший» адрес.
В нормальном выполнении загрузка никогда не срабатывает, так как условный переход идет нафиг всегда. При спекулятивном выполнении есть большой соблазн запустить эту загрузку на всякий случай заранее, хотя в момент запуска еще не известно значение условия А. Приплыли.
При вашем подходе нужно, чтобы «нехороший код» не только был внутри процесса, но и исполнялся. При переходе по содержимому регистра можно заставить «спекулятивно исполнить» вообще любой код!
Так такой «нехороший код» гораздо чаще в ядре или программе случается! И защититься от него много сложнее через LLVM/gcc.
Но почитав о чем народ талдычит, складывается впечатление, что якобы Интел не делает speculative пока по коду не проползет несколько раз циклом(!) Очень странная мысль, я сидел на одном семинаре где они хвастались, что они просматривают вперед аж на 3 условных перехода длинным pipeline — нахрена тогда им это делать то?
Или это конкретный процессор такой, а народ и не знает?
Это насчет того, сработает нехороший код или нет.
Но почитав о чем народ талдычит, складывается впечатление, что якобы Интел не делает speculative пока по коду не проползет несколько раз циклом(!) Очень странная мысль, я сидел на одном семинаре где они хвастались, что они просматривают вперед аж на 3 условных перехода длинным pipeline — нахрена тогда им это делать то?
Или это конкретный процессор такой, а народ и не знает?
Это насчет того, сработает нехороший код или нет.
Это насчет того, сработает нехороший код или нет.У меня есть ощущение, что вы за деревьями лес потеряли. Intel действительно применяет массу эвристик, чтобы правильно предсказать ветвление — но нам-то нужно, чтобы произошло строго противоположное: весь профит получается на основании спекулятивного исполнения кода, который исполняться не должен.
Вот вы тут пишете:
При спекулятивном выполнении есть большой соблазн запустить эту загрузку на всякий случай заранее, хотя в момент запуска еще не известно значение условия А. Приплыли.Процессор не исполняет ничего «на всякий случай». Он не пытается «хватать» инструкции «где-то рядом» с потоком исполнения и рандомно их исполнять — это бессмысленно. На некоторых CRAY системах пытались одновременно спекулятивно исполнять команды на обоих ветвях после перехода… идея себя не оправдала. У всех же современных процессоров предсказывается один «магистральный путь движения» программы.
Если загрузка после проверки «спекулятивно сработала» (а потом не понадобилась) — то это значит, что предсказатель переходов сработал неверно. За последние четверть века Intel потратил не один миллиард долларов на то, чтобы снизить вероятность такого события.
А вы предлагаете на это событие, случающееся с ничтожной вероятностью, полагаться. Не надо так.
> Процессор не исполняет ничего «на всякий случай». Он не пытается «хватать» инструкции «где-то рядом» с потоком исполнения и рандомно их исполнять — это бессмысленно. На некоторых CRAY системах пытались одновременно спекулятивно исполнять команды на обоих ветвях после перехода… идея себя не оправдала.
На CRAY не оправдала, на MIPS например — оправдала. И вы немного не в курсе, почему часто отрабатывают тщательнЕе код, который внутри loop — просто есть такая штука как instruction parsing (особая головная боль для Интела) и branch-table — код внутри короткой петли уже разобран в процессоре на микроинструкции и все возможные операции уже сделаны. Посему можно сделать speculative операцию довольно легко. Но это для low-end процессоров, для high-end надо смотреть в обе стороны условного перехода.
Кстати, далеко вперед обычно не смотрят, просто парсят и запускают операции загрузки из памяти (ну очень уж они долгие, особенно если учесть возможность подкачки TLB из памяти), и (внимание!) — простейшие операции над адресами в случае индексирования и последующей второй загрузки над результирующим адресом. Вот мне кажется, что AMD не делает либо индексирование либо вторую загрузку, которая зависит от первой. Посему они такие гордые сегодня.
> Если загрузка после проверки «спекулятивно сработала» (а потом не понадобилась) — то это значит, что предсказатель переходов сработал неверно.
Это важно только в случае узкого канала в память. Если у вас хороший кэш, то большинство неверных предсказаний окончится в кэше и чуть потратит рессурсы LFU-или-как-его-там, которых все равно делают в расчете на speculative.
> А вы предлагаете на это событие, случающееся с ничтожной вероятностью, полагаться.
Это как в анекдоте — 50-на-50. Маленьких циклов, которые полностью оседают в процессоре — мало, большая часть циклов просто не обнаруживается процессором. Так что с этой точки зрения выгодно отрабатывать чуть-чуть вперед по обе стороны условного перехода.
На CRAY не оправдала, на MIPS например — оправдала. И вы немного не в курсе, почему часто отрабатывают тщательнЕе код, который внутри loop — просто есть такая штука как instruction parsing (особая головная боль для Интела) и branch-table — код внутри короткой петли уже разобран в процессоре на микроинструкции и все возможные операции уже сделаны. Посему можно сделать speculative операцию довольно легко. Но это для low-end процессоров, для high-end надо смотреть в обе стороны условного перехода.
Кстати, далеко вперед обычно не смотрят, просто парсят и запускают операции загрузки из памяти (ну очень уж они долгие, особенно если учесть возможность подкачки TLB из памяти), и (внимание!) — простейшие операции над адресами в случае индексирования и последующей второй загрузки над результирующим адресом. Вот мне кажется, что AMD не делает либо индексирование либо вторую загрузку, которая зависит от первой. Посему они такие гордые сегодня.
> Если загрузка после проверки «спекулятивно сработала» (а потом не понадобилась) — то это значит, что предсказатель переходов сработал неверно.
Это важно только в случае узкого канала в память. Если у вас хороший кэш, то большинство неверных предсказаний окончится в кэше и чуть потратит рессурсы LFU-или-как-его-там, которых все равно делают в расчете на speculative.
> А вы предлагаете на это событие, случающееся с ничтожной вероятностью, полагаться.
Это как в анекдоте — 50-на-50. Маленьких циклов, которые полностью оседают в процессоре — мало, большая часть циклов просто не обнаруживается процессором. Так что с этой точки зрения выгодно отрабатывать чуть-чуть вперед по обе стороны условного перехода.
Дополнительно — newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf, параграф 2.2.1 Bound Check Bypass:
"… method takes advantage of speculative execution after conditional branch instructions"
Intel рекомендует вставлять LFENCE после условного перехода. Что-то не верится в 1.5%, если после каждого перехода будет LFENCE.
Что касается Branch target injection и предлагаемого патч по имени retpoline для этого в LLVM/gcc, то он убивает execution stack protection — запрет на выполнение кода из стэка. Попросту — открывает новые горизонты для хакеров!
"… method takes advantage of speculative execution after conditional branch instructions"
Intel рекомендует вставлять LFENCE после условного перехода. Что-то не верится в 1.5%, если после каждого перехода будет LFENCE.
Что касается Branch target injection и предлагаемого патч по имени retpoline для этого в LLVM/gcc, то он убивает execution stack protection — запрет на выполнение кода из стэка. Попросту — открывает новые горизонты для хакеров!
Что касается Branch target injection и предлагаемого патч по имени retpoline для этого в LLVM/gcc, то он убивает execution stack protection — запрет на выполнение кода из стэка.Нет там никакого кода в стеке.
Честно скажу — патч не видел, просто прочитал рекомендации Интел (см выше), параграф 3.2 Branch Target Injection Mitigation. Для текущего железа они расписывают «retpoline» как
«software replaces indirect near jump and call instructions with a code sequence that includes pushing the target of the branch in question onto the stack and then executing a Return (RET) instruction to jump to that location...»
Может, конечно, интеллы чего-то не понимают в программировании, но рекомендации однозначны, и они потребуют разблокировать этот стэк для выполнения.
«software replaces indirect near jump and call instructions with a code sequence that includes pushing the target of the branch in question onto the stack and then executing a Return (RET) instruction to jump to that location...»
Может, конечно, интеллы чего-то не понимают в программировании, но рекомендации однозначны, и они потребуют разблокировать этот стэк для выполнения.
Из этой картинки следует, что проблем у процессоров AMD под windows нет. И под линукс тоже нет, если ты сам ядро не твикал. Это правда так?Нет, неправда. Просто для эксплуатации нужны определённые данные в ядре, которые пока неизвестно как занести. То есть кто-нибудь когда-нибудь, скорее всего, придумает как это сделать — но на это может потребоваться и несколько недель (тогда всем будет очень больно) и несколько лет (тогда это будет просто «сказкой на ночь»).
Ну если можно сделать это — «занести определенные данные в ядро», то никакой meltdown/spectre уже и не нужен, между прочим.
Вроде как у людей PoC работает на AMD и на линукс и на win 10, без включения модулей ядра.
gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6
gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6
Насколько я понимаю, этот код всего лишь доказывает, что можно использовать определеные последовательности для запуска misprediction load при условном переходе и размещении данных в кэше. Для реальной эксплуатации все еще нужны определённые коды в ядре (victim_function при правильной оптимизации и запуске ), которой можно разбрасывать этот mispredicted load в зависимости от значения читаемого байта по разным кэш строчкам.
Да, это все еще опасно, гарантировать сложно. Некоторый код ядра делает именно эти операции (криптографический хэш, например).
Да, это все еще опасно, гарантировать сложно. Некоторый код ядра делает именно эти операции (криптографический хэш, например).
Некоторые эксперты считают, что программным образом полностью обезопаситься нельзя и единственный способ решить проблему — сменить процессор на вариант без асбеста заведомо безопасный.
А безопасный — это какой? Я так понял вся линейка от интела болеет этим. Менять вообще всю платформу как-то не хочется. В моём случае получается только патч?
Вас мотивируют купить новый процессор. В новом же страшилки устранят?
Вот, кстати, интересный вопрос. Я вот недавно собрал товарищу комп на шестиядерным двенадцатипотоковым Coffee Lake с разблокированным множителем. Процессор явно недешевый. И тут такое дело. Гарантия на процессор — 36 месяцев. Вот если бы наличие подобной уязвимости было гарайтийным случаем… я думаю у интела была бы другая стратегия, а не выкатывание нового ядра раз в пару лет)
Я не совсем понимаю: уязвимость в CPU фиксится на уровне ОС. Может тогда это все-таки уязвимость в ОС?
На уровне ОС это "починили" следующим образом: они на выходе из сискола сбрасывают ряд кэшей процессора, через которые "утекают" данные, плюс заанмапили полностью kernel address space, а не только защитили от чтения/записи, так что надо теперь восстанавливать/убирать. Процесс этот небыстрый, что ведёт к нескольким дополнительным сотням циклов на каждый сискол. Отсюда просадка производительности на 30% в том же постгресе.
Спасибо за объяснение!
Вот с PostgreSQL сейчас обидно было. 30% это, блин, 30%.
А ты не гоняй на машине с ним сторонии приложения (включая браузер), и можешь спать спокойно. Надеюсь PostgreSQL не выполняет Java/JS?
https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.de
ну не 30, а 23, да и то в синтетическом тесте.
Но все равно обидно :(
Уязвимость на уровне CPU, но закрыть её на уровне CPU нельзя. Поэтому костыляют на уровне ОС.
Уязвимость фиксится на уровне ОС потому что как вы себе представляете пофиксить её на уровне процессора? Я не думаю, что можно накатить патч на процессор из под Windows.
Это понятно, но значит ли это, что в следующем поколении CPU уязвимость будет устранена и на уровне ОС этот замедляющий код может быть отключен (для соответствующих версий CPU конечно же) ?
Скорее всего, да.
Если речь идёт об «утечке информации через кэши», то аппаратное устранение этой проблемы будет вести к точно такому же замедлению, что и программное.
Зависит от реализации. Например, можно зарезервировать пару кеш-линий для спекулятивного выполнения, и, пока не поступит подтверждение, что переход предсказан верно, на запись работать только с этими линиями и не писать в другие.
Как только приходит подтверждение предсказания, эти выделенные линии мержаться в кеш. Если приходит неподтверждение, линии отбрасываеются, как и изменения в регистрах.
Всего-то ещё 100500 транзисторов на эту логику. Там и без того намешано чёрт знает сколько, так что чуть усложнить работу процессора не страшно.
Как только приходит подтверждение предсказания, эти выделенные линии мержаться в кеш. Если приходит неподтверждение, линии отбрасываеются, как и изменения в регистрах.
Всего-то ещё 100500 транзисторов на эту логику. Там и без того намешано чёрт знает сколько, так что чуть усложнить работу процессора не страшно.
Одно из аппаратных решений — огрубление high-resolution таймера до, скажем, 2000 тиков в секунду. Это не решит проблему, но существенно замедлит скорость чтения: до 1 бита в миллисекунду — 128 байт в секунду, что на 3 порядка ниже текущей скорости чтения.
Ну будет скорость меньше, че толку то? будут читать, только дольше.
Не замедлит.
Если есть доступ к rdtsc, хакер будет просто подгадывать момент, когда rdtsc увеличился, крутить цикл почти до следующего тика, а потом запускать процедуру чтения адреса и смотреть, успел ли счётчик скакнуть, или нет.
Если нет доступа к rdtsc (как в сценарии с web-workers), ничего не меняется. Вспомогательный поток непрерывно делает вычисления и постоянно кладёт результаты в память. Основной поток в интересующий момент просто смотрит, сколько успело навычисляться.
Если есть доступ к rdtsc, хакер будет просто подгадывать момент, когда rdtsc увеличился, крутить цикл почти до следующего тика, а потом запускать процедуру чтения адреса и смотреть, успел ли счётчик скакнуть, или нет.
Если нет доступа к rdtsc (как в сценарии с web-workers), ничего не меняется. Вспомогательный поток непрерывно делает вычисления и постоянно кладёт результаты в память. Основной поток в интересующий момент просто смотрит, сколько успело навычисляться.
> Если есть доступ к rdtsc
Вообще-то я его и имел в виду. Огрубить rdtsc до 2000 тиков в секунду.
Вообще-то я его и имел в виду. Огрубить rdtsc до 2000 тиков в секунду.
Как видите, не решает. Атакующему нужно знать: кусок кода выполнился за 10 тактов или за 200. Для этого он замеряет, сколько нужно крутить пустой цикл, чтобы rdtsc увеличился на 1, затем сразу же крутит этот цикл на 10 итераций меньше, и выполняет интересующее его чтение памяти. Затем смотрит, успело чтение до инкремента rdtsc или нет.
Таймер для эксплойта необязателен: один поток пусть в бесконечном цикле инкрементирует счётчик, другой поток пусть сравнивает значения счётчика до обращения к памяти и после.
Не совсем. Чтобы починить текущие проблемы у Интела, надо — делать проверку доступа ДО того, как запускается подкачка кэш-а; разобраться с кривым TSX-NI, или отрубить его совсем — отрубали же на определенных процессорах из-за ошибок.
Ну а eBPF — это все-таки просто что-то типа троянского коня в ядре и больше софтверная проблема.
Ну а eBPF — это все-таки просто что-то типа троянского коня в ядре и больше софтверная проблема.
Некоторые уязвимости и баги таки фиксятся на уровне процессора — фиксится микропрограмма.
И можно даже из-под Windows накатить обновление — вот пример support.microsoft.com/en-us/help/3064209/june-2015-intel-cpu-microcode-update-for-windows.
И можно даже из-под Windows накатить обновление — вот пример support.microsoft.com/en-us/help/3064209/june-2015-intel-cpu-microcode-update-for-windows.
НЛО прилетело и опубликовало эту надпись здесь
Может я плохо читал, но это точно нельзя пофиксить патчем микрокода?
Можно. Но придётся кучу самых часто используемых инструкций пустить через микрокод. С соответствующим замедлением раз этак в 5-10.
Оно вам надо? Тут уж дешевле поставить интерпретатор x86 для x86 и пускать всё в эмуляции под QEMU…
Оно вам надо? Тут уж дешевле поставить интерпретатор x86 для x86 и пускать всё в эмуляции под QEMU…
Разве QEMU не выполняет бинарную трансляцию? То есть, с большой вероятностью, он скопирует весь вычислительный код (между системными опкодами) один-в-один и запустит.
Можно это выключить. Но да, замедление будет такое, что всё это — скорее теоретические возможности…
В него можно добавить верификацию на попытки использовать эксплойт.
НЛО прилетело и опубликовало эту надпись здесь
Можно конкретные сигнатуры ловить, но в общем случае эта задача требует полноценного понимания, что делает алгоритм. В коде нет никакого криминала, особенно если обращение к таймеру заменить на взаимодействие вычислительных потоков. Ну, насчитал алгоритм что-то, а потом на основе этого сделал URL для GET-запроса. Информация утекла.
Хороший вопрос. Фиксить нужно гипервизор или виртуальные на нем? VMWare пока молчат.
VMWare выпустили бюлетень безопастности:
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 тоже можно будет обойтись обновлением гипервизора, но достоверной информации пока нет :(
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 тоже можно будет обойтись обновлением гипервизора, но достоверной информации пока нет :(
Отличные новости, ничего не скажешь. 10 лет Карл, 10 лет дырка была. И не в софте, а в железе!
Поправка небольшая — 20 лет.
Интересно, сколько раз её успели заюзать…
Да уж, лично я испытал дикий батхерт от этой новости, когда, будучи более 10 лет поклонником AMD, всего полгода назад решил проапргрейдить компьютер и перейти на Intel.
Помните, когда-то давно хакер Крис Касперски (мышихъ) обещал раскрыть уязвимость/закладку в процессорах, а потом уехал в штаты. Разные околохакерские ресурсы долго спекулировали на эту тему, мол дыра настолько фундаментальная, что достаточно зайти на сайт и вне зависимости от ОС, антивируса и браузера, можно систему поиметь. Насколько я помню он ничего такого и не рассказал так. Хотя я могу и ошибаться. Чем там дело кончилось?
вообще механизм уязвимости настолько просто, что я удивлен что его раньше не нашли
Прикольно. Интересно, как часто гебня пользовалась этой уязвимостью?
www.securitylab.ru/news/355981.php
www.securitylab.ru/news/355981.php
Может ли эта уязмимость грозить сереру, на котором нет недоверенных пользователей и виртуалок, нет браузера и присущих ему скриптов?
если нету зловредного кода который будет выполнятся тем или иным обзором, в таком случае конечно нету опасности.
эта уязвимость требует запуска кода на CPU, а значит только в случае исполнения кода = заражение вирусом\установка левого софта
Может, смотря что делает система. Насколько я понимаю, любая обработка кода может провести эту атаку. Допустим есть эксплоит выполнения кода в ОС на уровне сетевого стека. Написать PoC после этого не проблема, запускаем атаку и параллельно дергаем SSH — SSH подгружает файлы и они проходят через память. Память мы уже выискиваем данные.
Я пример привожу конечно.
сменить процессор на заведомо безопасный
И в этом проце через пару лет найдут еще одну уязвимость из-за которой надо сменить проц, вот прям сейчас, бегом, покупай, вон тот, новый, а то продажи пк комплектующих падают, заодно и мать купи, вот.
Со стороны выглядит как новая модель по стимулированию продаж.
Matrix has you.
Интересно, как долго уже всякие NSA, ФСБ и прочие негодяи пользуются этими эксплоитами…
How deep the rabbit hole goes?
Интересно, как долго уже всякие NSA, ФСБ и прочие негодяи пользуются этими эксплоитами…
How deep the rabbit hole goes?
spectreattack.com/spectre.pdf
Кажется, отключение WebWorkers должно предотвратить/усложнить использование атаки через браузер.
JavaScript 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 должно предотвратить/усложнить использование атаки через браузер.
и единственный способ решить проблему — сменить процессор на вариант заведомо безопасный.С пока еще не скомпрометированной закладкой :)
Ну и отлично! Нахрен общество!!!
и единственный способ решить проблему — сменить процессор на вариант заведомо безопасный.
а еще лучше — сделать свой процессор, о котором никто не будет знать, версию 0.1 можно сделать на лампах :)
А как там насчет Эльбрусов?
Данная новость теперь будет спекулироваться нашим государством как перевод всех гос. учреждений на процы «свои».
Данная новость теперь будет спекулироваться нашим государством как перевод всех гос. учреждений на процы «свои».
Почитал чуть-чуть статью (pdf).
Очередной прикол с асинхроным исполнением. Надо бы в таких случаях применять какие то алгоритмы чтобы формально доказывать корректность работы.
Вообще опасная фича что сначала загружается в регистр запрещенный участок памяти а потом уже идет проверка на то были ли на это разрешения. Похоже дело было так: реализация доступа к страницам памяти была еще с рождения х86, а потом поверх решили добавить out-of-order инструкции новым слоем, и вышло такое комбо.
Надо бы в таких случаях применять какие то алгоритмы чтобы формально доказывать корректность работы.Математически всё корректно, проблема с физикой. Если бы в системе не было таймера, утечки бы не было. Это примерно как недавняя «уязвимость» функции memcmp(user_input, secret_key, key_size), которая сравнивает user_input и secret_key побайтно. Замеряя время выполнения, можно узнать, на каком байте находится расхождение, и брутфосить только этот байт.
НЛО прилетело и опубликовало эту надпись здесь
То бишь, на языке математики требования к таймингам тоже можно выразить и проверить корректность соответствующих высказываний.Это значит — сразу зарезать кучу оптимизаций. Если есть возможность для некоторых данных выполнить операцию быстрее, этой возможностью категорически нельзя пользоваться, ведь это раскроет данные перед атакой по таймеру.
А если ускорение получается автоматически (как при делении на некоторых делителях), нужно добавлять искуственные задержки, сводя всё к худшему случаю. Определённо, не то, что мы хотим от процессора.
НЛО прилетело и опубликовало эту надпись здесь
Я об этом думал. Это не решение. Хотя чуть бы уменьшило последствия.
Сейчас, в зависимости от секретного байта, подчитывается какая-то кеш-линия. Если кеш-линию инвалидировать, то изменение состояния кеша при выполнении mispredicted branch — это тоже утечка информации. Просто информации утекает меньше и нужно больше раундов атаки.
Полноценное (на мой взгляд) решение я выразил здесь.
Сейчас, в зависимости от секретного байта, подчитывается какая-то кеш-линия. Если кеш-линию инвалидировать, то изменение состояния кеша при выполнении mispredicted branch — это тоже утечка информации. Просто информации утекает меньше и нужно больше раундов атаки.
Полноценное (на мой взгляд) решение я выразил здесь.
НЛО прилетело и опубликовало эту надпись здесь
Тут идея такая:
Зная адрес в памяти
Затем я читаю
Сама прочитанная линия array2 мне не нужна, я и так знаю данные array2. Важно лишь, какая линия выбита (а для этого я могу весь кеш забить каким-нибудь array3 и проверять, что вылетело).
Зная адрес в памяти
array1, я делаю чтение array1[x] так, что array1+x является адресом в недоступной области (в данном баге не проверяется мой доступ к этой области). Обозначим секретное значение k=array1[x]Затем я читаю
array2[k*256] (ко всему array2 у меня полный доступ, тут никаких ошибок не предвидится) и, в зависимости от k, это чтение загружает в кеш кусок array2 и выбивает из кеша одну из линий. Если затем эту линию инвалидировать, это несильно помешает, я всё равно замечу, какая из линий инвалидирована.Сама прочитанная линия array2 мне не нужна, я и так знаю данные array2. Важно лишь, какая линия выбита (а для этого я могу весь кеш забить каким-нибудь array3 и проверять, что вылетело).
НЛО прилетело и опубликовало эту надпись здесь
Именно, если оригинале проверяется, какая линия array2 попала в кеш, то с инвалидацией придётся проверять, что вылетело.
Атака усложняется, но остаётся возможной.
Атака усложняется, но остаётся возможной.
НЛО прилетело и опубликовало эту надпись здесь
«Отрезать от кэша кусок для особых целей, и после каждого удачного доступа к памяти перегонять кэшлайн из особого кэша в обычный» — нехило так ударит по производительности.
В чём выгода перед патчем ОС тогда?
В чём выгода перед патчем ОС тогда?
НЛО прилетело и опубликовало эту надпись здесь
В ОС, как уже написали в каментах, unmap-ят всю «запрещённую память», и принудительно сбрасывают все кэши, при каждом переключении из кернелмода в юзермод.
Теперь будут держать отдельный каталог таблиц, полностью свой CR3 с блекджеком и профурсетками, чисто для ядра, с перегрузкой оного (CR3), инвалидированием TLB при переключениях и так далее?
НЛО прилетело и опубликовало эту надпись здесь
Тест на запрос getpid в цикле показывает в районе 4-кратного торможения с анти-Meltdown патчем.
Это в Linux? А зачем syscall?
В Windows свой PID просто лежит в PEB, доступном из юзермода.
В 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Для текущего времени сделали чисто-юзерлендовое решение через механизм vDSO, а для pidʼа, видимо, не было причин — кому его надо читать таким темпом? Теперь могут и сделать, если что-то резко просядет.
Кстати, в старых FreeBSD вызов getpid() кэшировался на уровне libc; fork() просто снимал флаг «а мы знаем свой pid». vDSO тут даже не обязательно.
Кстати, в старых FreeBSD вызов getpid() кэшировался на уровне libc; fork() просто снимал флаг «а мы знаем свой pid». vDSO тут даже не обязательно.
Не после каждого удачного доступа, а только при записи в режиме спекулятивного выполнения, что такой частый сценарий.
Микрокодом это сделать наверное нельзя.
Но если сделать нативно — всего лишь 1-2 новых 512-битных регистра (а такого размера регистров и так уже 32: zmm0-zmm31), которые при коммите изменений запишутся в кеш, а не в регистровый файл (как бы это в современных процессорах не было одной и той же структурой, т.к. конструкции типа
Микрокодом это сделать наверное нельзя.
Но если сделать нативно — всего лишь 1-2 новых 512-битных регистра (а такого размера регистров и так уже 32: zmm0-zmm31), которые при коммите изменений запишутся в кеш, а не в регистровый файл (как бы это в современных процессорах не было одной и той же структурой, т.к. конструкции типа
add eax,[ebp+8] работают, как и add eax,ebx)Не перегнять, а переадресовывать. Иметь еще один кэш-маппинг, который назначает адрес в кэше и меняется при подтверждении загрузки. Ну и в этот момент и происходит вытеснение старой строки.
Да все проще же. Если мы (процессор) знаем физический адрес — значит, мы уже знаем и про ограничения доступа к странице. Достаточно лишь проверять их еще до попытки чтения.
Не может раздельно кешироваться трансляция в физический адрес и флаги доступа?
MMU нужно время на проверку адреса, поэтому по факту логичнее запускать такую проверку и спекулятивное выполнение одновременно, иначе резко упадёт эффективность.
Дальше случается гонка между MMU и конвейером, и судя по всему, в Интелах побеждает конвейер, а в АМД — MMU. Но ни там, ни там конвейер не ждёт результата из MMU.
Дальше случается гонка между MMU и конвейером, и судя по всему, в Интелах побеждает конвейер, а в АМД — MMU. Но ни там, ни там конвейер не ждёт результата из MMU.
Что есть «проверка» адреса? Логический адрес не надо проверять, его надо преобразовать в физический. Если это преобразование еще не сделано — то прочитать значение по указанному адресу невозможно!
Поэтому конвейер обязан ждать MMU.
Поэтому конвейер обязан ждать MMU.
Вообще опасная фича что сначала загружается в регистр запрещенный участок памяти а потом уже идет проверка на то были ли на это разрешенияПрямого доступа в запрещённый участок всё равно нет. После отрицательного ответа на проверку доступа загруженные данные откатываются обратно.
А вот сторонние эффекты, как то загруженная в кеш линия, зависящая от прочитанного байта (для того там и хитрая конструкция
y = array2[array1[x] * 256]), остаются. И, хотя напрямую нельзя узнать, какие адреса сейчас сидят в кеше, это можно сделать, замеряя время доступа к разным адресам.Если запретить физическое чтение данных, к которым нет доступа, много теряем в производительности — убираем параллельную загрузку и проверку доступа, придётся делать всё строго последовательно и про выполнение процессором одновременно N инструкций на одном ядре придётся забыть.
если ты понимаешь как это работает, пили статью пожалуйста
Пришлось читать 300 комментариев чтобы найти этот (и еще один выше)...
Вот мне и интересно: в процессорах AMD не используется параллельная загрузка — проверка доступа, либо они как-то по-другому оптимизируют исполнение подобного кода.
Не знаю, может, у AMD оптимизатор не такой продвинутый, чтобы заглядывать настолько вперёд в ветке, которую в конечном итоге по логике программы выполнять не надо.
Если мы про Spectre, то AMD подвержен.
Если мы про Meltdown, то у AMD немного другая внутренняя логика, в результате которой у атакующего не остаётся достаточного временного окна для собственно атаки.
Это логика, над которой раньше никто явно особо не задумывался, поэтому что у Intel сделано так, а у AMD иначе — обусловлено какими-то иными причинами, возможно, настроением разработчика процессора тем утром, когда он сел этот блок рисовать. У ARM вон вообще часть ядер Meltdown подвержена, а часть — нет.
Если мы про Meltdown, то у AMD немного другая внутренняя логика, в результате которой у атакующего не остаётся достаточного временного окна для собственно атаки.
Это логика, над которой раньше никто явно особо не задумывался, поэтому что у Intel сделано так, а у AMD иначе — обусловлено какими-то иными причинами, возможно, настроением разработчика процессора тем утром, когда он сел этот блок рисовать. У ARM вон вообще часть ядер Meltdown подвержена, а часть — нет.
Да, про Meltdown, спасибо.
Spectre, как я понял, на AMD процессорах лечится программно практически без потери производительности.
Spectre, как я понял, на AMD процессорах лечится программно практически без потери производительности.
Это AMD утверждает, что он лечится программно и без потерь.
Пруфов пока никто не видел, и из оригинальной работы по Spectre никак не следует, что мы их увидим.
Точнее, даже так: да, возможно, он лечится программно и без потерь. В каждом конкретном уязвимом месте каждой используемой на компьютере программы. Теперь умножьте количество таких мест на количество существующих в мире программ.
Пруфов пока никто не видел, и из оригинальной работы по Spectre никак не следует, что мы их увидим.
Точнее, даже так: да, возможно, он лечится программно и без потерь. В каждом конкретном уязвимом месте каждой используемой на компьютере программы. Теперь умножьте количество таких мест на количество существующих в мире программ.
Обсуждение этого бага на конференции BlackHat 2017 Asia:
www.youtube.com/watch?v=6bCdFmehMSY
www.youtube.com/watch?v=6bCdFmehMSY
На Ubuntu server 16.04 патчи уже есть? Потушил пока виртуальные машины. И, насколько я понимаю, только Meltdown закрывается, а Spectre вообще только аппаратно или на уровне микрокода можно закрыть?
микрокод не поможет (он отвечает только за декодер инструкций). Исправление только аппаратное: замена процессора на неуязвимый (на 486 или более старше, либо ждать новые процы, где это будет исправлено, через 1-2 года, думаю)
Садиться и плакать, да?) Меня жаба задавит сейчас обновлять домашний сервер на Core i5 Ivy Bridge. Увы, но он ещё и owncloud хостит для друзей и рабочих задач. Думаю, как минимизировать хотя бы риски атаки.
НЛО прилетело и опубликовало эту надпись здесь
Fedora ночью выкатили новое ядро, но у них stable сейчас 4.14.11.
У меня 4.10, кажется. Я на HWE ядра перешёл.
Я не думаю, что там будет большая проблема.
Патч сводится к нескольким строчкам. Главный вопрос, что будет с производительностью на реальных системах. Пока на десктопе мне тяжело сказать как она изменилась.
Патч сводится к нескольким строчкам. Главный вопрос, что будет с производительностью на реальных системах. Пока на десктопе мне тяжело сказать как она изменилась.
Я на Windows 7 отключу этот патч, наверное. Только для игр запускаю.
Оценка рисков ;)
Думаю, что его эксплуатация начнется с какого-то webasembly и максимум, что будет подпадать под атаку на широкую аудиторию — это пользовательские данные из браузера.
Думаю, что его эксплуатация начнется с какого-то webasembly и максимум, что будет подпадать под атаку на широкую аудиторию — это пользовательские данные из браузера.
Сейчас думаю, как максимально изолировать все на сервере. У меня почти все только через VPN доступно, но наружу торчит HTTPS с nextcloud. Сам nextcloud внутри KVM.
Я не специалист в области безопасности.
Но в моем понимании для эксплуатации нужно исполнить код на целевой системе. То есть, если у вас сейчас система в актуальном состоянии, и исполнение кода на VPS в контролируете, то нужна еще одна 0day уязвимость позволяющая запустить эксплойт. Это без того, что еще нужно знать, что искать, или дампить память целиком и потом разбираться в ней.
Но в моем понимании для эксплуатации нужно исполнить код на целевой системе. То есть, если у вас сейчас система в актуальном состоянии, и исполнение кода на VPS в контролируете, то нужна еще одна 0day уязвимость позволяющая запустить эксплойт. Это без того, что еще нужно знать, что искать, или дампить память целиком и потом разбираться в ней.
Собственно, задача в том, чтобы максимально усложнить тупую не таргетированную атаку ботами. Против целенаправленной атаки сложно устоять. Поэтому хотя бы больше слоев изоляции.
Так если вы светите наружу 80 и 443 то боты вас будут штурмовать тем же набором эксплойтов, что и позавчера. Вот, если найдут какую-то открытую уязвимость, то чтобы закрепится на втором этапе добавят этот экплойт. Но опять же, нужно знать, что и где искать. Если у вам в окружении не висит переменная типа MY_SECRET_PASS etc, к примеру, то не особо уверен, что все будет легко для бота из китая.
Поставьте какую-нибудь IDS, ну или, как минимум, fail2ban закрутите до упора.
A c VPS, я не думаю, что вы сможете сделать больше, чем накатить обновление ядра. Нужно новости почитать, но вроде как spectre пока свободно эксплуатируем.
Поставьте какую-нибудь IDS, ну или, как минимум, fail2ban закрутите до упора.
A c VPS, я не думаю, что вы сможете сделать больше, чем накатить обновление ядра. Нужно новости почитать, но вроде как spectre пока свободно эксплуатируем.
Для игр сильные просадки вряд ли будут там же direct rendering без сисколлов
Принимая во внимание «теорему Джо», вряд ли ваш домашний сервер пострадает от атаки.
Паранойя) и китайские боты, которые абсолютно автоматически ломятся по всем портам.
Если серьезно, то там достаточно нетривиальные телодвижения надо проделать, к тому же знать что искать. Не скажу про виндовс, но линукс системы все таки более-менее защищены от этого, хотя бы пароли зашифрованы и не принято тянуть из сети и запускать что попало. А поиск чего-то конкретного уже попадает под «теорему Джо». Дыра пробиваемая через javascript, если сервер используется именно как сервер тоже по идее идет мимо. Что касается серверов, то серьезная засада пожалуй ожидает в основном только хостеров виртуалок, ну и конечно тех кто пренебрегает апдейтами в целом.
Какой же это Неуловимый Джо, если каждый хакер только и мечтает первым скачать новую статью про хлебушек, или физические процессы в профитролях.
на 486 или более старше
Ну зачем вы так сразу людей пугаете, можно же Pentium MMX поставить.
на 486 или более старше
Pentium MMX и более старше. Pentium Pro и Pentium II уже уязвимы.
Также есть старые (вроде как до 2013 г) Atom'ы, которые тож не имеют этих всяких конвейеров.
косо смотрит на процессор 486DX2-66, лежащий в тумбочке.
Пришло твое время!
Пришло твое время!
Судя по тестам, патчи сильно повлияют на производительность существующих систем. Тесты показывают падение на 10-30% в некоторых задачах.
Это ж отличная новость для всех поставщиков оборудования и особенно производителей процессоров!
Производительности моего уже десятилетнего Core2Quad мне пока на всё хватает, даже прошлогодние игры упираются лишь в видеокарту. А прилетит патчик, комп начнёт наконец-то тормозить, и побегу я и миллионы таких как я в магазин за новым 6-8-ядерным процессором, который потянет за собой апгрейд всего остального компа. А уж как энтерпрайз обрадуется новые компы и сервера покупать!
Это ж отличная новость для всех поставщиков оборудования и особенно производителей процессоров!В чем она отличная?
Я думал о покупке ноутбука. Нормальной рабочей станции с расчетом года на три, на уровне EliteBook, ZBook, Precision. Но вот теперь у меня возникает вопрос, покупать ли сейчас ноутбук за 2к, если через год выйдет версия с процессором, который будет на 10-30% мощнее без учета естественного прогресса технологии. И думается мне, что не я один такой. А на AMD выбор не такой большой и выигрыш в производительности тоже не будет значительным.
И вот если этот вопрос будут задавать достаточное кол-во людей, то продажи могут просесть очень сильно.
PS только что накатил новое ядро. Визуально стал несколько медленнее, тестов почти не делал, но в одном проседание на 30%, в остальных все как-было.
Вы и так собирались покупать более новое железо на замену относительно новому — там рост производительности процента три от поколения к поколению, вам действительно лучше подождать хардварного решения проблемы.
А я и куча других людей не собирались покупать, так как нас устраивала имеющаяся производительность. После патча она просядет на 30%, что подстегнёт апгрейды. Даже с учётом штрафа в 30% новые кофе-лэйки намного быстрее старых коре2квадов, хотя бы из-за роста тактовой частоты в полтора раза, не говоря уж о двух дополнительных ядрах, гипертрединге и всех тех новых фич, которые Интел успел сделать за десять лет.
А я и куча других людей не собирались покупать, так как нас устраивала имеющаяся производительность. После патча она просядет на 30%, что подстегнёт апгрейды. Даже с учётом штрафа в 30% новые кофе-лэйки намного быстрее старых коре2квадов, хотя бы из-за роста тактовой частоты в полтора раза, не говоря уж о двух дополнительных ядрах, гипертрединге и всех тех новых фич, которые Интел успел сделать за десять лет.
Меня вполне устраивала производительность на моем далеко не новом i5-4310U. Но она была на приделе, и когда у меня запущенна IDE и пару виртуальных машин, это чувствуется. Вот сейчас буду по работе делать ручные тесты с виртуалками, тогда и посмотрим.
Не факт, я уже написал, что у меня она просела только в одном тесте. Если у вас есть какой-то нормальный тест для linux на производительность, я готов его прогнать, чтобы проверить.
После патча она просядет на 30%, что подстегнёт апгрейды.
Не факт, я уже написал, что у меня она просела только в одном тесте. Если у вас есть какой-то нормальный тест для linux на производительность, я готов его прогнать, чтобы проверить.
НЛО прилетело и опубликовало эту надпись здесь
Тоже приглядывался к 920, все бил себя по рукам. Теперь уверен, что дождусь линейки процессоров без уязвимости :)
Я тешу себя напрасными надеждами, что цены просядут.
В любом случае пару недель нужно подождать. Но сомневаюсь, что ситуация сильно исправится и, скорее всего, нужно будет собирать что-то mini-itx.
В любом случае пару недель нужно подождать. Но сомневаюсь, что ситуация сильно исправится и, скорее всего, нужно будет собирать что-то mini-itx.
Изначально не самый удачный выбор в плане security:
www.techdirt.com/articles/20150812/11395231925/lenovo-busted-stealthily-installing-crapware-via-bios-fresh-windows-installs.shtml
www.techdirt.com/articles/20150812/11395231925/lenovo-busted-stealthily-installing-crapware-via-bios-fresh-windows-installs.shtml
Я думаю, что основной объём продаж определяется людьми, которые вообще никогда не узнают об этом моменте. И для задач которых потеря 30% производительности ничего не означает, потому как всё равно процессор всё время в idle. Тех, кто реально будет парится на эту тему, хорошо, если один процент наберётся.
А кто-то зарабатывает на понижении. Не знаю как применимо в данном случае.
А я вот купил месяц назад, теперь совсем как-то грустно.
Производительности моего уже десятилетнего Core2Quad мне пока на всё хватает, даже прошлогодние игры упираются лишь в видеокарту.
Очень странно, потому что я своими глазами наблюдал обратное при переходе с Xeon E5xxx (по характеристикам идентичен топовому C2Q) на i7-6700. Допустим, Mafia III на старом процессоре не «тормозила» (визуальные подвисания) только на минимальных настройках графики, а с новым процессоров никаких проблем я не увидел даже на средних. Учитывая, что видеокарта осталась прежней, напрашивается вывод, что процессор реально был узким местом.
Security Advisory от Microsoft со ссылками на обновления — https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002
KB4056892 установился уже через Windows Update, могу сказать что мой дохленький i3 просел в играх (даже не самых свежих уже), в WOW Wotlk просадки fps до 25% :( по сравнению с до патчевыми замерами.
Наверное выбор сделаю в сторону производительности на одной машине, где мне не страшно что данные стырят. Как отрубить теперь последствия этого патча? Флаг в реестре не подскажите?
Наверное выбор сделаю в сторону производительности на одной машине, где мне не страшно что данные стырят. Как отрубить теперь последствия этого патча? Флаг в реестре не подскажите?
i7-6700 в Cinebench просел на 4-5% в многопотоке.
Это хорошие новости и для меня — у самого такой. Хороший ЦП так-то, менять его и не планировал еще года 3-4. А тут что началось… аж скис.
Мне вот не нравится, что уже дважды после этого обновления система повисала наглухо… Возможно, загвоздка в том, что у меня не серийный процессор, а инженерный экземпляр (ранний степпинг), и на серийных всё будет нормально.
Кстати, вдобавок к обновлениям операционных систем выпущен свежий микрокод для процессоров:
New upstream microcodes to partially address CVE-2017-5715
Кстати, вдобавок к обновлениям операционных систем выпущен свежий микрокод для процессоров:
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
Тут важно понимать долю IO в тестировании, что, мне кажется, должна быть так же незначительна. Насколько я помню Cinebench больше графический бенчмарк, то есть это почти как сравнивать fps в игрушке, где существенной просадки и так не прогнозируют.
И почему всё называют это дырой/уязвимостью, когда это самое натуральное «несоответствие действий процессора со своей спецификацией»? Тут надо не решать какая должна быть «заплатка» на уровне ОС или на уровне процессора. Тут надо пересматривать саму архитектуру проца как такового.
Простым юзверям на это всё равно побоку. У них 3 биткоин майнера в аппдате, 2 маил ру сервиса которые «неизвестно откуда взялись/всегда там были», 20 тулбаров в браузерах, подменёные ярлыки на рабочем столе, зато «красивые часики». Таким юзверям по барабану на эту уязвимость потому что раз в пол года они перестанавливают шиндовс xp и даже не краснеют.
Другие «супер продвинутые» юзвери никогда не сидят под админом, запускают программы только в песочници из под виртуалки. Такие обычно не могут даже распаковать игрушку не говоря уже о запуске потому что вообще у них «белый список»… Таким данная уязвимость не страшна потому что они поддерживают состояние бекапов по 3 раза в день.
Почему я не слова ни сказал о защите личной информации например «пороль от сбербанка»? Потому что всё что хранится в принципе не на вашем компе — не ваша личная собственность. Если захотят спиздить ваши фотки с облака — спиздят. Не через процессор так через терморектальный_криптоанализ всё равно найдут способ… Двух факторная аутификация для того и создавалась чтобы даже скомпрометированная машина не могла ничего получить. Но о безопасности самой машины всё равно не имеет смысла говорить пока процессы в принципе не будут разделены. Какой смысл говорить о безопасности браузера если он хранит свои данные в той же папке в которой и зловред? (я про appdata). И доступ туда имеет вообще любая программа.
На самом деле никто никогда и не был по настоящему защищён.
Простым юзверям на это всё равно побоку. У них 3 биткоин майнера в аппдате, 2 маил ру сервиса которые «неизвестно откуда взялись/всегда там были», 20 тулбаров в браузерах, подменёные ярлыки на рабочем столе, зато «красивые часики». Таким юзверям по барабану на эту уязвимость потому что раз в пол года они перестанавливают шиндовс xp и даже не краснеют.
Другие «супер продвинутые» юзвери никогда не сидят под админом, запускают программы только в песочници из под виртуалки. Такие обычно не могут даже распаковать игрушку не говоря уже о запуске потому что вообще у них «белый список»… Таким данная уязвимость не страшна потому что они поддерживают состояние бекапов по 3 раза в день.
Почему я не слова ни сказал о защите личной информации например «пороль от сбербанка»? Потому что всё что хранится в принципе не на вашем компе — не ваша личная собственность. Если захотят спиздить ваши фотки с облака — спиздят. Не через процессор так через терморектальный_криптоанализ всё равно найдут способ… Двух факторная аутификация для того и создавалась чтобы даже скомпрометированная машина не могла ничего получить. Но о безопасности самой машины всё равно не имеет смысла говорить пока процессы в принципе не будут разделены. Какой смысл говорить о безопасности браузера если он хранит свои данные в той же папке в которой и зловред? (я про appdata). И доступ туда имеет вообще любая программа.
На самом деле никто никогда и не был по настоящему защищён.
Сейчас меня совсем выпилят с хабра, но я всё же выскажусь.
Вот а что я неправильно сказал? Ни одного комментария — только тихие минусы… Между прочим тысячи юзеров скачивают и запускают неизвестные фаилы и Bad Rabbit тому пример. Вот что делает новость про него на хабре? о чём она говорит?
САМА ОС создана для того чтобы любые программы получали как можно больше прав в системе. И это пропагандируется вместо изоляции и эмуляции. И вы думаете что защищены? рано или поздно появляется приложение которое «ну вот очень нужно мне прямо сейчас» и оно не распространяется как простой портабельный екзешник с библиотеками, нет — оно распространяется как установочный файл. А значит будет требовать админ права. И без этого работать не будет. Тот же УАК в винде: «ой программа делает что-то системное но я не скажу что это и куда она лезет, более того если не разрешите я её просто кильну её на месте» и вот как быть простым юзерам? Где пользователям винды найти аналог fakeroot для windows? (я бы пересел на линукс если бы там был аналог программы sound lock из коробки и без настройки, серьёзно меня держит только эта хрень… блин я даже на тостере создал тему чтобы выяснить куда мне двигаться чтобы самому написать такое приложение. А ещё отсутствие нормальных аудио плееров, но в целом есть более менее терпимые плееры просто немного коробит от них ))
А что делают программы которые не требуют админ прав? они всё равно пишут в общие папки. У них по умолчанию достаточно прав чтобы перелопатить все фаилы пользователя. Есть ли оболочка под винду или линукс чтобы в ней по умолчанию предлагался бы запуск от фиктивного пользователя? есть ли система чтобы эти самые фиктивные пользователи были бы ещё и различными для различных программ? Я не спорю что может быть инструменты то и есть, но вот чтобы это было ЗАЛОЖЕНО в систему изначально — нет. Более того большинство даже коммерческих таких инструментов имеют серьёзнейшие проблемы.
И получается что не имея защищённости изначально мы впариваем снижающий производительность патч лишь для того чтобы получить иллюзию безопасности. Кому это надо? Разве что интелу чтобы хоть как-то снизить уровень покупок инженерных процессоров случайно забытых в китае, а то уж больно жирно получается для юзеров играть в современные игрушечки заплатив меньше 10 долларов…
Вы минусаторы! Если хоть у одного из вас есть действительно защищённая ОС то пожалуйста распишите рецепт счастья для простых смертных. Или хотябы просто аргументируйте. Может вам не понравилось что я не написал своё отношение к самой «уязвимости» — ну так конечно же плохо иметь в процессоре какой-то набор инструкции который бы выдавал бы какие нибудь неположенные данные. Я с этим согласен. Но прямо сейчас это не самая большая «дыра» в системе… И если есть возможность «залатать» дыру средствами ОС — значит что это и не «дыра» процессора в принципе. вот что я считаю.
Вот а что я неправильно сказал? Ни одного комментария — только тихие минусы… Между прочим тысячи юзеров скачивают и запускают неизвестные фаилы и Bad Rabbit тому пример. Вот что делает новость про него на хабре? о чём она говорит?
САМА ОС создана для того чтобы любые программы получали как можно больше прав в системе. И это пропагандируется вместо изоляции и эмуляции. И вы думаете что защищены? рано или поздно появляется приложение которое «ну вот очень нужно мне прямо сейчас» и оно не распространяется как простой портабельный екзешник с библиотеками, нет — оно распространяется как установочный файл. А значит будет требовать админ права. И без этого работать не будет. Тот же УАК в винде: «ой программа делает что-то системное но я не скажу что это и куда она лезет, более того если не разрешите я её просто кильну её на месте» и вот как быть простым юзерам? Где пользователям винды найти аналог fakeroot для windows? (я бы пересел на линукс если бы там был аналог программы sound lock из коробки и без настройки, серьёзно меня держит только эта хрень… блин я даже на тостере создал тему чтобы выяснить куда мне двигаться чтобы самому написать такое приложение. А ещё отсутствие нормальных аудио плееров, но в целом есть более менее терпимые плееры просто немного коробит от них ))
А что делают программы которые не требуют админ прав? они всё равно пишут в общие папки. У них по умолчанию достаточно прав чтобы перелопатить все фаилы пользователя. Есть ли оболочка под винду или линукс чтобы в ней по умолчанию предлагался бы запуск от фиктивного пользователя? есть ли система чтобы эти самые фиктивные пользователи были бы ещё и различными для различных программ? Я не спорю что может быть инструменты то и есть, но вот чтобы это было ЗАЛОЖЕНО в систему изначально — нет. Более того большинство даже коммерческих таких инструментов имеют серьёзнейшие проблемы.
И получается что не имея защищённости изначально мы впариваем снижающий производительность патч лишь для того чтобы получить иллюзию безопасности. Кому это надо? Разве что интелу чтобы хоть как-то снизить уровень покупок инженерных процессоров случайно забытых в китае, а то уж больно жирно получается для юзеров играть в современные игрушечки заплатив меньше 10 долларов…
Вы минусаторы! Если хоть у одного из вас есть действительно защищённая ОС то пожалуйста распишите рецепт счастья для простых смертных. Или хотябы просто аргументируйте. Может вам не понравилось что я не написал своё отношение к самой «уязвимости» — ну так конечно же плохо иметь в процессоре какой-то набор инструкции который бы выдавал бы какие нибудь неположенные данные. Я с этим согласен. Но прямо сейчас это не самая большая «дыра» в системе… И если есть возможность «залатать» дыру средствами ОС — значит что это и не «дыра» процессора в принципе. вот что я считаю.
Для JS можно сделать верификатор, которые проверяет, что конкретная программа не может использовать эти или другие дыры. Увеличится время загрузки, а на скорости после JIT уже не отразится.
НЛО прилетело и опубликовало эту надпись здесь
Вот ты сейчас серьёзно? Не коснётся то, что одно приложение может считывать произвольные места в памяти и полностью нарушиать изоляцию? Может и не коснётся если живешь в лесу отшельником.
НЛО прилетело и опубликовало эту надпись здесь
Скринсейвер — не страшно, его ещё нужно установить.
Ужас и кошмар — то, что прямо в данный момент хабр может читать ваши пароли посредством javascript.
Ужас и кошмар — то, что прямо в данный момент хабр может читать ваши пароли посредством javascript.
Насколько я слежу за форумами, пока Spectre никто не знает как закрыть.
>"…практически любое приложение может читать произвольные файлы пользователя…"
Что бы такое не работало можно поставить HIPS или нечто подобное. А вот что делать с текущей проблемой не ясно.
Что бы такое не работало можно поставить HIPS или нечто подобное. А вот что делать с текущей проблемой не ясно.
То есть 30% потеря производительности от этих патчей по вашему это «не коснется»?!
Эта уязвимость коснется абсолютно всех, да в разной степени, да кого-то напрямую, кого-то косвенно, но коснется.
Эта уязвимость коснется абсолютно всех, да в разной степени, да кого-то напрямую, кого-то косвенно, но коснется.
Почему все говорят о "падении производительности"? Производительность не падает — увеличивается загрузка процессора натвыполнение "лишних" операций и падает КПД! И за все это заплатим мы с вами счетами за электроэнергию и укороченным временем работы ноутбуков от батарей!
Как же не падает, если при каждом переключании режима user/kernel, надо выполнить определённые инструкции, перенастраивающие карту памяти, чтобы удалить страницы ядра из user-пространства (раньше конфигурация карты памяти была одинаковая, а критичные данные были защищены правами доступа, но этот эксплойт их обходит).
Инструкции выполняются? Скорость выполнения инструкций падает? Со стороны процессора он работает точно так же — просто ПО которое на нем выполняется начинает передавать ему больше инструкций.
Говорить "снижение производительности" неверно потому, что низкая производительность ассоциируется с низким потреблением энергии. В данном же случае происходит не только замедление выполнения пользовательского кода, но и увеличение потребления энергии.
Падает производительность не CPU, а операционной системы, а вместе с ней и всего компьютера.
ОС выполняет меньше сисколлов в секунду (т.к. больше времени тратит на каждый при том же hardware).
ОС выполняет меньше сисколлов в секунду (т.к. больше времени тратит на каждый при том же hardware).
низкая производительность ассоциируется с низким потреблением энергииo_O
У меня почему-то низкая производительность наоборот ассоциируется с излишним потреблением энергии.
Потому что речь о производительности пользовательского кода.
MS Выложило вроде как апдейты
www.catalog.update.microsoft.com/Search.aspx?q=KB4056898 Windows 8.1
www.catalog.update.microsoft.com/Search.aspx?q=KB4056897 Windows 7
www.catalog.update.microsoft.com/Search.aspx?q=KB4056898 Windows 8.1
www.catalog.update.microsoft.com/Search.aspx?q=KB4056897 Windows 7
Касательно 7ки. Если прочесть о чем оно, то не особо похоже под нашу проблему. Но кто знает, что там под капотом
Эти обновления вышли раньше времени (должны были во вторник). Это наводит на мысль, что выкатили их в срочном порядке. Других причин кроме Meltdown/Specte вроде на это не было…
Т.е. опять спасибо Гуглёвым докладам?
В том смысле, что благодаря им апдейты вышли раньше? Не знаю. Вообще я видел инфу, что производители процов еще в июне были поставлены в известность. А на «официальном» сайте уязвимостей написано, что найдены они были независимо аж тремя (!) командами сразу (касаемо Meltdown). Не думаю, что это прям так вот в один день случилось.
Кстати обновления от MS до сих пор еще не видны через обычный механизм обновления. По крайней мере в Win 7 и 8.1, в десятке — не знаю. Но вот WSUS выкачал первую партию (security only update) 4-го числа и вторую (кумулятивные) — 5-го. Может решили корпоративных клиентов обновить побыстрее, а с обычными подождать до вторника патчей.
На мой взгляд для обычной рабочей станции уязвимость не столь страшна, что бы прямо впадать в панику. Да, несомненно уязвимость очень серьёзная. Но для её успешной эксплуатации всё же надо еще немалую работу проделать. Так что пара-тройка дней просрочки с установкой патча не так страшно думаю. Вот для облачных систем очень опасно, это да.
Кстати обновления от MS до сих пор еще не видны через обычный механизм обновления. По крайней мере в Win 7 и 8.1, в десятке — не знаю. Но вот WSUS выкачал первую партию (security only update) 4-го числа и вторую (кумулятивные) — 5-го. Может решили корпоративных клиентов обновить побыстрее, а с обычными подождать до вторника патчей.
На мой взгляд для обычной рабочей станции уязвимость не столь страшна, что бы прямо впадать в панику. Да, несомненно уязвимость очень серьёзная. Но для её успешной эксплуатации всё же надо еще немалую работу проделать. Так что пара-тройка дней просрочки с установкой патча не так страшно думаю. Вот для облачных систем очень опасно, это да.
— Да, я про спешку и торопыг-публикаторов. Эти апдейты уже были в планах у MS на «вторник патчей».
Вот в каком месте у Google чесалось, чтобы опять вывалить всё раньше сроков?
PS: В SCCM всё приехало 4-го. Установку на сервера (Hyper-V и RDSH) аппрувнул руками. Остальные — не горит. Понятно, что длинные «каникулы» это специфика РФ (может и не только наша, конечно), но наверное, можно было и не выкатывать подробности явно раньше обещанных сроков?
Вот в каком месте у Google чесалось, чтобы опять вывалить всё раньше сроков?
PS: В SCCM всё приехало 4-го. Установку на сервера (Hyper-V и RDSH) аппрувнул руками. Остальные — не горит. Понятно, что длинные «каникулы» это специфика РФ (может и не только наша, конечно), но наверное, можно было и не выкатывать подробности явно раньше обещанных сроков?
А, в этом плане. Я честно говоря не интересовался кто первый разгласил. Может и не Гугл это был.
Одно ясно, что об уязвимости было известно уже несколько месяцев (вроде с июня как минимум). И подготовка к внедрению патчей (и соответственно к разглашению) велась долго и планомерно. У кого-то нервы сдали на завершающем этапе наверно. Ну или еще какие-то причины были, оставим их деликатно за кадром.
Любопытный факт: как я понял для установки патчей на Windows, в случае если установлен какой-либо антивирус, нужно что бы этот антивирус в начале проапдейтился до совместимого и выставил флаг в реестре. Т.е. производители антивирусов тоже были заранее уведомлены и готовились. Хотя патч к Kaspersky Endpoint Security вышел только 4-го числа. Не похоже как-то на «подготовились заранее». В общем не знаю.
Одно ясно, что об уязвимости было известно уже несколько месяцев (вроде с июня как минимум). И подготовка к внедрению патчей (и соответственно к разглашению) велась долго и планомерно. У кого-то нервы сдали на завершающем этапе наверно. Ну или еще какие-то причины были, оставим их деликатно за кадром.
Любопытный факт: как я понял для установки патчей на Windows, в случае если установлен какой-либо антивирус, нужно что бы этот антивирус в начале проапдейтился до совместимого и выставил флаг в реестре. Т.е. производители антивирусов тоже были заранее уведомлены и готовились. Хотя патч к Kaspersky Endpoint Security вышел только 4-го числа. Не похоже как-то на «подготовились заранее». В общем не знаю.
У кого-то нервы сдали на завершающем этапе наверно. Ну или еще какие-то причины были, оставим их деликатно за кадром.Да нет, всё просто: чем ближе «к часу Х», тем больше людей задействовано. Вендоры, крупные ISP, etc.
Так что обычно нужно быть готовым к тому, что за 5-7 дней до официального срока «оно» случится. Так почти со всеми уязвимостями было…
То есть через эти дырки какой-то вшивый сайт с нужным js сможет private key для моего бинткойна вытащить?
Если Вам не повезёт, то, получается, да.
Ну это достаточно затруднительно, но возможно, а вот на месте всевозможных бирж и обменников на VPS я бы напрягся.
биржи на VPS… вы серьезно? :)
А этого не может быть?
aws.amazon.com/solutions/case-studies/coinbase
docs.gdax.com
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.
бинткойнЕщё одна новая монета?
Погоди, у тебя установлен браузер на компе с бинткойном?
Бенч до патча
$ 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.01Бенч после патча
$ 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: 31.8731s
total number of events: 10000
total time taken by event execution: 509.4104
per-request statistics:
min: 9.10ms
avg: 50.94ms
max: 132.46ms
approx. 95 percentile: 68.48ms
Threads fairness:
events (avg/stddev): 625.0000/4.05
execution time (avg/stddev): 31.8382/0.02Замедление на четверть. Спасибо, Интел!
Если threads тест запустить все еще хуже.
До патча
General statistics:
total time: 10.0001s
total number of events: 54619
После патча
General statistics:
total time: 10.0003s
total number of events: 32527
Но визуально пока в пределах нормы.
До патча
General statistics:
total time: 10.0001s
total number of events: 54619
После патча
General statistics:
total time: 10.0003s
total number of events: 32527
Но визуально пока в пределах нормы.
А как однопоточные тесты себя показали? Я вот свой старый лэптоп проверил, значительно просели только многопоточные.
И вот в 2018 году, дети, вдруг стали популярны текстовые браузеры
;o)
;o)
Сайт по ссылке не скомпрометирован? ))
Кста, разговоры о патчах ОСей,
а патчей браузеров не достаточно?
Кста, разговоры о патчах ОСей,
а патчей браузеров не достаточно?
Нет, патч на уровне системы виртуальной памяти.
Ну тады интересно почитать про межпроцеcсное взаимодействие браузера и ОС.
В исходниках firefox'a смотреть? Или JS отдельная библиотека?
В исходниках firefox'a смотреть? Или JS отдельная библиотека?
Пираты Силиконовой Долины(1999)
Наше дело выяснить насколько этот парень не знает, что ему на самом деле нужно и добиться, чтобы до него это дошло.
Чтобы он понял, что только мы можем ему это дать.
Наше дело выяснить насколько этот парень не знает, что ему на самом деле нужно и добиться, чтобы до него это дошло.
Чтобы он понял, что только мы можем ему это дать.
И какие же процессоры позиционируются как заведомо безопасные?
НЛО прилетело и опубликовало эту надпись здесь
Вот что-то есть.
gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6
gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6
Акции говорите падают?
Амазон, накатка патчей, просадка производительсти на 25 процентов оО
Закупка нового железа и стоек, кто в плюсе? Сколько надо тому же амазону железа чтобы выровнять эту просадку?
Да там такие цифры с нулями будут, что некоторые типы процессоров мы еще год можем не увидеть на наших рынках.
Амазон, накатка патчей, просадка производительсти на 25 процентов оО
Закупка нового железа и стоек, кто в плюсе? Сколько надо тому же амазону железа чтобы выровнять эту просадку?
Да там такие цифры с нулями будут, что некоторые типы процессоров мы еще год можем не увидеть на наших рынках.
и покупать они будут конечно же intel. Это же так логично, до выхода исправленных процов МИНИМУМ полгода год.
Ну, это произойдет не сразу, кмк. Сначала, на панике, откатится вниз, а уже потом, когда дойдет до тотальной замены-апгрейда и пр., попрут продажи и котировки. Нет?
Ну еще не известно чем все кончится. Мало ли, что можно заложить в микрокод.
И просадка на 25% для амазона через чур пессимистична. На реальных задачах в объемах ДЦ у aws будет меньше. Но для некоторых проектов, конечно, может сыграть эффект бутылочного горлышка.
И просадка на 25% для амазона через чур пессимистична. На реальных задачах в объемах ДЦ у aws будет меньше. Но для некоторых проектов, конечно, может сыграть эффект бутылочного горлышка.
Мало нам было дефицита видеокарт из-за майнеров, теперь будет дефицит процессоров.
Мне непонятны две вещи. Можно ли будет отключить этот патч и каким образом? Где хотя бы об этом можно будет узнать?
Так и не понял, касается ли эта проблема только Intel или Intel и AMD? Будут ли выпущены патчи для смартфонов/планшетов и произойдет ли падение производительности у них? В случае, если архитектура процессора не x86 / x86-64?
Так и не понял, касается ли эта проблема только Intel или Intel и AMD? Будут ли выпущены патчи для смартфонов/планшетов и произойдет ли падение производительности у них? В случае, если архитектура процессора не x86 / x86-64?
spectreattack.com
В линуксе отключить можно ключом nopti при загрузке.
В линуксе отключить можно ключом nopti при загрузке.
To 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% туда сюда и до патча и после и после отключения в пропатченной винде.
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% туда сюда и до патча и после и после отключения в пропатченной винде.
Проблемы так-то две Meltdown — Intel и Spectre — Intel и AMD, но по AMD тут менее понятно, встречается информация типа «AMD и Intel уязвимы» и информация, что AMD уязвима только при включенном ebpf.
Уязвимости 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=47856
Уязвимости 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=47856
AMD (только при включенном eBPF в ядре)
И при выключенном тоже.
eBPF — просто удобный способ демонстрации дырки, не более.
за исключением Intel Itanium
Отличный повод воскресить платформу под флагом безопасности. Судя по новостям сейчас только у SPARC похоже нет этих дыр (или я не нашел упоминаний о них).
ARM64 (Cortex-R7/R8, ...)Вроде как R7/R8 таки 32-битные, но умеют в out-of-order pipeline и поэтому уязвимы.
Вот что-то есть.
Там нет вызова ядра, так что этим кодом проверить работоспособность патча скорее всего не получится.
Intel заявила (без подробностей), что нашла способ устранения обеих уязвимостей (и Meltdown и Spectre). Обновления уже, якобы, выпущены для большинства процессоров моложе пяти лет. Судя по всему, лечат комбинацией патчей ОС и прошивок процессоров.
Правда фразы про то, что многие производители уже проапдейтились — скорее намекает на те самые «замедляющие» патчи (
Да, наверняка речь про них. Хотя все основные игроки утверждают, что влияние патчей на производительность практически не заметно для большинства пользователей, но призывают проверять это на своих нагрузках самостоятельно. Как это все сказывается на энергопотреблении, не говорят.
В пиар-отделах всех основных игроков сейчас за любое другое заявление просто молча выводят в коридор и расстреливают за углом.
Паника среди пользователей — последнее, что им всем нужно.
Паника среди пользователей — последнее, что им всем нужно.
Ну, кроме шуток — это таки правда. Проседает (причём сильно-таки проседает, в несколько раз) операция вызова ядра системы. А дальше — зависит от нагрузки.
Если у вас счётная задача (а большинство игрушек, скажем, сюда попадает), то замедление и под микроскопом не разглядеть.
А если у вас там много-много IPC — то вполне можно и двукратное замедление получить…
Если у вас счётная задача (а большинство игрушек, скажем, сюда попадает), то замедление и под микроскопом не разглядеть.
А если у вас там много-много IPC — то вполне можно и двукратное замедление получить…
Покупайте i13, там такой фигни не будет(плюс защита от майнинга в подарок)…
Господа, не понимаю, в обсуждении не затрагивалось, не повлекут ли данные проблемы принудительного отключения Hyper-threading?
Мне ещё в советские времена дед говорил, что спекуляция — это плохо.
Че пацаны, PS4 с XboxOne уже ломанули? Раз такое дело :)
Ждите новые процессоры с улучшенной производительностю аж на 25%!!!
A как посещать даже проверенные сайты, если без JavaScript не работают практически все сайты?????
MS уже начали накатывать обновления — azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vulnerability но по ходу очень неудачно
Кстати, мне в декабре и на смартфон, и на SMART TV самсунговские прилетели апдейты во второй половине декабря. Причем для ТВ предыдущий апдейт на их сайте был аж от 2015-го года. Совпадение?.. :)
Через пяток лет найдут дыру, которую эти 5 лет спокойно хакеры эксплуатируют уже сейчас.
Так что не расстраивайтесь.
Так что не расстраивайтесь.
ББ не дремлет…
Есть ли изменения в производительности для Ryzen (до и после обновления, OS Win10)? Может кто тесты находил.
Об этом баге знали еще в 2010м…
twitter.com/rootkovska/status/948997805158338560
twitter.com/rootkovska/status/948997805158338560
Это кранты, это ЕЩЕ ОДИН баг. Поставить внутри guest VM последовательность спекулятивной загрузки карты памяти root-а (!) + чтения слова из этой памяти ==> в TLB будет лежать доступ в память root-а из guest-а.
Если это еще работает (все-таки 7 лет прошло), то весь облачный сервис накрылся медным тазом, сбацать дырокол для тех процессоров — нефиг делать. Ох, заставят всех обновить процессоры, заставят.
Если это еще работает (все-таки 7 лет прошло), то весь облачный сервис накрылся медным тазом, сбацать дырокол для тех процессоров — нефиг делать. Ох, заставят всех обновить процессоры, заставят.
Ну ладно все понятно с корпоратами, но насколько мала вероятность что домашние компы попадут под атаку. Представим вариант что написан софт который парсит и вытягивает инфу из дампов юзверей. Какие мощности нужны что бы распарсить миллионы дампов и вытянуть хоть что либо полезное кроме паролей от вк и одноглазников.
Какие мощности нужны что бы распарсить миллионы дампов и вытянуть хоть что либо полезное кроме паролей от вк и одноглазников.Ровно такие, какие есть. Hint: для автоматического анализа дамп не нужно никуда отсылать, можно его с тем же успехом «исследовать на месте». Даже не снимая его до конца. Какой процент компьютеров сейчас постоянно подключён к сети?
Да все еще проще. Типичный пользователь домашнего компьютера либо сидит под админом, либо при необходимости запускает из-под админа любые программы которые хорошо попросили об этом. А с правами администратора можно читать память любого процесса при помощи официального WINAPI.
В контексте типичных домашних компьютеров эта атака попросту не имеет ни малейшего смысла.
В контексте типичных домашних компьютеров эта атака попросту не имеет ни малейшего смысла.
CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?